The part of code that are specific to OpenSSL are now included only if
the openssl feature is activated. The generic parts of code included in
OpenSSL specific files has been moved out.
The previous system used a duplicated enum
(`acmed::certificate::Algorithm`) and an imprecise identifier name
(algorithm) for both the certificate configuration and post operation
hook variable. The first one has been replaced by the
`acme_common::crypto::KeyType` enum and the second renames `key_type`.
Being tied with the key type, the signature algorithm should therefore
be at the same place than the key type, hence `acme_common::crypto`.
This reorganization will allow to specify the account key type as well
as the signature algorithm in the configuration.
Since there is currently no possibility to chose a different account key
type, the current implementation only supports the ES256 algorithm. With
the upcoming support of different key types, it had to be changed. This
commit add support for ES384 although there is no configuration option
that can activate the actual use of it through account keys using the
NIST P-384 curve.
As discussed in #2, ring is not mature enough to replace OpenSSL. Hence,
the standalone mode which has been made to implement such a replacement
has to be removed until ring becomes usable.
Until now, the crypto key abstraction used two different type: PublicKey
and PrivateKey. Unfortunately, it does not work with ring and should
therefore be rewrote with a single type: KeyPair.
Because ring does not currently support RSA keys generation, the default
algo must be adapted depending on whether or not the standalone feature
is activated.
Since it is planned to add a "standalone" feature that will replace
OpenSSL by crates not linking to any external library, it is required to
abstract all the OpenSSL specific types. This is a huge work and
therefore is divided in several steps. This first one is dedicated to
public and private keys.
rel #2