CVC CAs

Features

Using EJBCA you can set up a complete infrastructure for CVC CAs with:

• Country CVCCA
• Domestic DVs (document verifier)
• Foreign DVs
• Inspection systems (IS)

EJBCA supports RSA and ECC keys in CV certificates with the following algorithms:

• SHA1WithRSA - id-TA-RSA-v1-5-SHA-1
• SHA256WithRSA - id-TA-RSA-v1-5-SHA-256
• SHA1WithRSAAndMGF1 - id-TA-RSA-PSS-SHA-1
• SHA256WithRSAAndMGF1 - id-TA-RSA-PSS-SHA-256
• SHA1WithECDSA - id-TA-ECDSA_SHA_1
• SHA224WithECDSA - id-TA-ECDSA_SHA_224
• SHA256WithECDSA - id-TA-ECDSA_SHA_256

Using the complimentary project SignServer you can set up a clustered Document Signer.

Creating CVCAs and DVs

When creating a CVC CA there are three CA Reference fields in the standard. In EJBCA these are mapped to a DN structure to have common handling in EJBCA. The mapping is:

• Country = C
• Mnemonic = CN

To create a DV you select 'Signed by=Name of CVCCA' and 'Certificate Profile=SUBCA'.

You can import a CVCA certificate from another country as an 'External CA' using 'Edit Certificate Authorities->Import CA certificate'. When a CA has been imported, this CA certificate can authenticate CVC requests from foreign DVs.

CVC Sequence

The sequence in the holder reference of EAC CVC certificates should identify a public key. For CAs created and managed by EJBCA this sequence is normally an automatic property in the CA token. It starts with 00001 and is increased when new keys are generated (renew CA with checkbox to renew keys checked).
You can also set a specific value for the initial sequence, which will then be increased when renewing keys, or you can change the sequence at any time. See section about Key sequence in User guide for more information.

For entity (IS and DV) requests that are received, the sequence in the issued certificates are taken from the request. The entity knows best how to index it's keys.

EAC roles

• When issuing a CV certificate using a Root CA profile the EAC role will be CVCA.
• When issuing a CV certificate using a Sub CA profile the EAC role will be DV-D if the country is the same as the country of the CVCA and DV-F if the country is not the same as the CVCA.
• When issuing a CV certificate using an End Entity profile the EAC role will be IS.

EAC access rights

You can configure in the certificate profile which EAC access rights will be used for issued certificates. None, read access DG3, read access DG4 or read access DG3 and DG4.

Document verifiers (DV)

You create domestic DVs as simply as creating a SubCA to your CVCA, using a SubCA certificate profile.

You can sign foreign DVs by receiving and processing a CV certificate request. In the 'Edit Certificate Authorities' page enter a name for the foreign DV and click 'Process Certificate Request'.
You can also treat your DVs as regular End Entities by simply creating and choosing a SubCA certificate profiles when adding the End Entities. A benefit of handling foreign DVs as end entities is that you can process and renew them using the same WS-API as you can use for inspection systems.

You can create a DV to be signed by a foreign CVCA by creating a new CA and selecting 'Signed By=External CA'. You need the CVCA certificate of the foreign CVCA to create the request to be sent. When creating this CA a self-signed CV certificate request is created.

You can at any time create a CV certificate request from a DV by going into 'Edit Certificate Authorities' and click 'Make Certificate Request'. This generates a CSR created by the CAs keystore. When receiving the signed certificate back, you can feed that to your IS-system. There is no need (or way) to import it into EJBCA.

You can renew a DV by going into 'Edit Certificate Authorities' and click 'Renew CA'. By uploading the CA certificate supposed to sign the certificate, you can get a new CSR created. You can import the received certificate by clicking 'Renew CA' again and choosing the function to 'Receive Certificate Response' instead of 'Make Certificate Request'. You only have to (or can) import one issued certificate to make your DV operational.
By filling in the CA tokens password and checking the box 'Renew Keys' the DV will generate new keys. This is working for soft CA tokens and PKCS#11 CA tokens. The renewal CRS is not signed with the old keys.

DVs have short validity periods, and it may be good to have them automatically renewed. There is a service 'Renew CA Service' to automatically renew CAs. The User's Guide contain more information about this service.

Creating authenticated requests and link certificates

You can sign CV certificate requests by your CVCA or DV by going to 'Edit Certificate Authorities', typing the name of your CA in the text field (same name as appears in the list above the text field) and then clicking on 'Sign Certificate Request'. You will be a chance to upload the CV certificate request to the CVCA, and you will get an Authenticated request back. This is required when sending certificate requests from your DVs to other member states and when creating CVCA link certificates.

The renewing a DV and sending a request to another member state you can get the request automatically authenticated by signing the request with the DVs old keys. You can do this by first renewing the DV to create a new certificate request. Then you go into 'Sign Certificate Request' for the same DV and sign the request checking the checkbox 'Use previous key'. An authenticated request, authenticated with the DVs previous key will be returned.

to create CVCA link certificates the same approach is done. First renew the CVCA (generating new keys), which creates a new self-signed CVCA certificate internally. Download the new self-signed CVCA certificate (for example from Basic Functions). After this you can create a link certificate by typing the CVCAs name in the text field in 'Edit Certificate Authorities' and clicking 'Sign Certificate Request'. Upload the new CVCA certificate and select 'Use previous key' and 'Create link certificate'.

The reason for this cumbersome and a bit clumsy way to create link certificates is that issuing a link certificate can actually be made to switch CA completely, new keys, new algorithms and new Country/Mnemonic. Therefore you can use this approach to create a link certificate from you old CVCA to a completely new one.

Inspection Systems

The best interface for enrolling IS's is the Web service API. There is a method cvcRequest that implements initial issuance and automatic renewal of IS cvc requests.

Enrollment processing logic using WS API is:

• A new IS with no old certificate issued must be pre-registered, be in status NEW and use a password.
• An IS with status REVOKED or HISTORICAL can not be enrolled.
• If the request is an authenticated request and the IS have an old valid (in time) certificate (in the EJBCA database) that can verify the outer signature, a new IS certificate is automatically allowed to be enrolled.
• If the authenticated request can not be verified because the outer signature can not be verified at all (invalid signature or no verifying certificate in the EJBCA database), the request is rejected.
• If the authenticated request can not be verified because the outer signature can be verified but the verifying certificate is not valid, the user must be in status NEW and use a password.

Revocation of an IS prohibits further issuance of certificates to that IS using the WS API.

There is a simple command line client for testing which is under dist/ejbcawscli/cvcwscli.sh. This can be used to make requests and to parse, print and verify requests and certificates.

Web Service API

In the regular EJBCA WS-API there is a method for enrolling and renewing DVs and ISs.

  	/** Generate a CV certificate for a user, uses the same authorizations as editUser and pkcs10Request
	 * responseType is always CertificateHelper.RESPONSETYPE_CERTIFICATE.
	 * 
	 * @see #editUser
	 * @see #pkcs10Request
	 * @param userdata the user data for editing/adding a user
	 * @param cvcreq Base64 encoded CVC request message
	 * @return the full certificate chain for the IS, with IS certificate in pos 0, DV in 1, CVCA in 2.
	 */
	public List<Certificate> cvcRequest(String username, String password, String cvcreq)
	throws AuthorizationDeniedException, UserDoesntFullfillEndEntityProfile, NotFoundException,
	EjbcaException, ApprovalException, WaitingForApprovalException;
  

The process when a CVC request is received through the WS-API call is:

• Look up if there exists a user with the specified username.
• If the user exists:
• If the user's status is revoked, the request is denied (AuthorizationDeniedException).
• See if the user have old certificates.
• If there are old certificates and the request is an authenticated request (with outer signature):
• If the request uses the same public key as the old certificate the request is denied (AuthorizationDeniedException).
• If the old certificate can verify the request but the certificate is not valid we throw a CertificateExpiredException (in EJBCA 3.7.4 and earlier we tried to process the request as a non-authenticated request instead).
• If the request can be verified using one of the old valid certificates the request is automatically granted and users status is set to new and the password set to the given password.
• If the request can not be verified at all the request is denied (AuthorizationDeniedException).
• If there are no old certificates we try to process the request as a non-authenticated request.
• If the user does not exist we try to process the request as a non-authenticated request.
• Processing the request as a non-authenticated request means that we try to authenticate using the password given, and that only works if the users status is NEW.

Command line client

there is a command line client using the WS-API. You can use this for reference and sample how to use the WS-API.

The command line client have two functions:

• cvcrequest - adds a new user and requests a CV Certificate.
• cvcgetchain - retrieves the last certificate chain for a user.
• cvcprint - used to parse and print CV Certificate and requests.

  ejbca> cd dist/ejbcawscli
  ejbca/dist/ejbcawscli> ./cvcwscli.sh
  Usage: cvcrequest cvcprint
  
  ejbca/dist/ejbcawscli> ./cvcwscli.sh cvcrequest
  Usage : cvcrequest <username> <password> <subjectdn> <sequence> <caname> <signatureAlg> ...
  ...
  
  ejbca/dist/ejbcawscli> ./cvcwscli.sh cvcprint
  Usage : cvcprint <filename> [verifycert]
  ...
  

./ejbcawsracli.sh edituser dv-de foo123 false "CN=dvca,C=DE" NULL NULL CVCAPK 1 USERGENERATED NEW DV DV  
  

./cvcwscli.sh cvcrequest dv-de foo123 "CN=dvca,C=DE" SE001 SHA256WithRSA 2048 false dedv
  

./ejbcawsracli.sh edituser isbrainpool47 foo123 false "CN=ISBPOOL47,C=SE" NULL NULL DV-BrainPool 1 USERGENERATED NEW IS IS
  

./cvcwscli.sh cvcrequest isbrainpool foo123 "C=SE,CN=ISBPOOL47" 00005 SHA224WithECDSA brainpoolp224r1 true isbrainpool
  

./cvcwscli.sh cvcrequest isbrainpool foo123 "C=SE,CN=ISBPOOL47" 00005 SHA224WithECDSA brainpoolp224r1 true isbrainpoolnew isbrainpool.pkcs8 isbrainpool.cvcert
  

Importing CAs

For test purposes you may receive a private key and a CV certificate for the CVCA trust point used by the passport manufacturer when creating specimen passports. To test your process and inspection systems you can import a CVCA (with soft keystore) in EJBCA if you have a PKCS#8 private key and a CV certificate with the public key.

bin/ejbca.sh ca importcvca

Example import command using the given CV Certificate:

bin/ejbca.sh ca importcvca importcvca1 GO_CVCA_RSA2008.pkcs8 GO_CVCA_RSA2008.cvcert C=SE,CN=IMPCA1
  

Example import command using the same private/public keys but generating a new certificate:

bin/ejbca.sh ca importcvca importcvca1 GO_CVCA_RSA2008.pkcs8 GO_CVCA_RSA2008.cvcert C=SE,CN=IMPCA1 SHA1WithRSA 365
  

Using HSMs

The EU policy surely requires that you use an HSM to protect the CAs signature keys. Depending on the algorithms you choose you have different options and difficulties. Using PKCS#11 the Sun PKCS#11 provider only supports RSA with PKCS1 padding (SHA256WithRSA), and not PSS (SHA256WIthRSAAndMGF1). If you want to use the PSS algorithms you need to use the IAIK PKCS#11 provider. See the User's Guide for instructions how to use the IAIK PKCS#11 provider.
The same goes for ECC, check with your HSM vendor about support for ECC.

Currently tested HSMs are:

• Utimaco
• SafeNet
• nCipher

There are two additional key properties (filled in the CAs token properties) when using a HSM controlling the use of the previous keys.

• previousCertSignKey - this is the alias of the previous signature key, as opposed to 'certSignKey' which is the current signature key.
• previousSequence - this is the sequence identifying the previous signature key, as opposed to the current sequence that is held in the CA token. This sequence will replace the current sequence in the caRef field when signing a request with the CAs previous key.

bin/pkcs11HSM.sh generate /etc/utimaco/libcs2_pkcs11.so secp160r1 signKey 1  
  

PEM requests

Processing certificate requests in the Admin-GUI of EJBCA can use wither binary or PEM format certificate requests. If you receive a binary request and want to convert it to PEM it is easy:

1. Base64 encode the request, for example with openssl base64 -in MY.cvrqst -a -out MY.cvrqst.pem.
2. Add -----BEGIN CERTIFICATE REQUEST----- in the beginning of the file.
3. Add -----END CERTIFICATE REQUEST----- in the end of the file.

-----BEGIN CERTIFICATE REQUEST-----
fyGCAkd/ToIBPV8pAQBCDVNFQ1ZDQVBLMDAwMDF/SYIBFQYKBAB/AAcCAgIBAoGC
AQDJuBLa1iFXD7WWK6614RvtmiZpgFXiTWkznp5MfusJuNqBuz46zeFAIJcerEtK
xcHtbOppA5U2FwOtqit0yhkg2XLTEf9zh5ewchSGWujG9yY77BPXfLg3a3iwVyBW
sED4z4L71hfvByTtkBpz90BFjwMUsiSzkuRwM/2PeThJNm5yDZVjLNFfN7Vdibi6
7PRh77oQkofk/FvMNVa60u6RsT1urJdM7+5mCvGOs0KoWzFMCdm3rZrIIvWmQBSx
MPRL42AVDgY/G7df27YMHJZ6psnEYC6n30yw91BFnzhqmDem4xugRnpzq1z0RqFM
YabWe8NsIBk/k6bFXcheCiqDggMBAAFfIA1DWkRWVEVTVFNFMDAwXzeCAQBqi1o4
HexB3Mfx5cnjCaRw8qPsC3zxw+bRXB3t1Y1pzA/Ely0HL8/y/SYpXKIs4DtZpCDI
R4zKDSK3jkv914oVMpM3DqlFdLqY4aAHV4FN5+6BKvbGYZEfips1ba8rPZETLzci
vKljIrXbf0fVSNhhnCAfM9DxKrlxZP10mLb0cWs5JSGjA2i0DlH18zKKteAOd8gy
htgSjlz2FnisHnIUlHS1dlLIFABDfbvNS9+WTzNN8JlFi37QpSC+C5Xt8Y4NnGiX
dMDaR1l15Vn6mNsw9lYaAcIj/EOlZcGocnVXAlhy3MkWk0ue85VbvwgPAfDP1AEF
8JcqQ6xN7ULMh8xW
-----END CERTIFICATE REQUEST-----