ECDSA Keys and Signatures

EJBCA supports ECDSA signature keys in addition to RSA. You can create a CA using ECDSA keys both using the CA GUI and the CLI (bin/ejbca.sh ca init).

This section provides information on ECDSA Keys and Signatures in the following sections:

For long term stability we recommend to use the most commonly used EC curves, if no other requirements apply choose P-256/P-384/P-521.

Generated Keys and Certificates

When generating a CA in EJBCA, up to three keys and certificates are generated:

• A CA signing keypair and certificate
• An encryption keypair, used for encrypting key recovery information
• An OCSP signer keypair and certificate

When selecting ECDSA for the encryption key, the keys will be encrypted using ECCDH. 

Using ECDSA with an HSM

Using named Brainpool curves in Java PKCS#11

Brainpool should work on all HSMs that have named curve support for Brainpool.

You can create and use CAs with brainpool curves in the HSM. Example clientToolBox commands to generate a key:

./ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /usr/lunasa/lib/libCryptoki2_64.so brainpoolP160r1 keyAliasBp160 1
./ejbcaClientToolBox.sh PKCS11HSMKeyTool test /usr/lunasa/lib/libCryptoki2_64.so 1 
./ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /etc/utimaco/libcs2_pkcs11.so brainpoolP160r1 keyAliasBp160 1
./ejbcaClientToolBox.sh PKCS11HSMKeyTool test /etc/utimaco/libcs2_pkcs11.so 1 

Or with P11NG:

./p11ng-cli.sh generatekeypair --lib-file /usr/safenet/lunaclient/lib/libCryptoki2_64.so --slot-ref SLOT_NUMBER --slot 0 --alias brainpoolP160r1 --key-spec brainpoolP160r1 --password 'mypassword'
./p11ng-cli.sh signperformancetest --lib-file /usr/safenet/lunaclient/lib/libCryptoki2_64.so --slot 0 --alias brainpoolP160r1 --time-limit 5000 --signature-algorithm SHA256WithECDSA --password 'mypassword'

ECC named curves vs explicit parameters

Normally, you want to generate requests and certificates using named curves encoded in certificates and requests, this is what IETF recommends. In some cases you need to generate the request and certificate with explicit parameters instead, this is for instance mandated by ICAO for usage in CSCA's and DS's for ePassports.

• When generating requests with clientToolBox PKCS11HSMKeyTool certreq you can specify a flag to use explicit parameters instead of named curves. Named curves is the default.
• When creating CAs with ejbca.sh ca init you can specify a flag to use explicit parameters instead of named curves. Named curves is the default.
• When EJBCA issues certificate with public keys from certificate requests (csr's) the key in the certificate will be the same as in the csr. If the csr uses explicit parameters, so will the issued certificate.

To create a CA with explicit EC parameters in the certificate you should check the checkbox Use explicit ECC parameters in the Crypto Token used for the CA.

Do not enable use of explicit ECC parameters unless you know it is really needed. This will create certificates that violate RFC5280.

Uncompressed and compressed format

EC Public Keys, with named curves, can be encoded in two different ways in the SubjectPublicKeyInfo structure that carries the public key in X.509 certificates and PKCS#10 or CRMF CSRs. These are compressed or uncompressed form. While they are equivalent when using the public key, the byte encoding differ. As stated in RFC3279 section 2.3.5 the uncompressed format is the commonly used. CAs will be created using the uncompressed format, while issued certificates can use either. If the CSR contains a SubjectPublicKeyInfo using named curve in uncompressed format, issued certificate will use named curve with uncompressed format.

• If the CSR contains a SubjectPublicKeyInfo using named curve in compressed format, issued certificate will use named curve with compressed format.
• If the CSR contains a SubjectPublicKeyInfo using explicit parameters in uncompressed format, issued certificate will use explicit parameters with uncompressed format.

Named curves

EJBCA supports the curves that BouncyCastle supports, including named curves from Nist, SEC and X9.62. New curves may be supported without this list being updated, give it a try.

Note that EJBCA does not support/allow EC keys less than 224 bits long. Shorter curves are noted below for reference only.