The following sections answer questions regarding usage according to the 3GPP 33.310 technical specification by the 3rd Generation Partnership Project (3GPP).

PrimeKey uses the latest version of the 3GPP technical specification for reference and the questions and answers below apply for version 3GPP TS 33.310 V16.5.0 (2020-09) and EJBCA Enterprise 7.4.3. Since EJBCA is continuously used in the 3GPP environment, we are sometimes required to go beyond the specification to allow incompatible equipment to operate in mobile network operator (MNO) networks.

For more information about CMP and CMP in 3GPP Mode (Vendor Mode), see the following EJBCA documentation sections:

Profiling - Certificate profiles

Common rules to all certificates (section 6.1.1)

The technical specification states:

Hash algorithm for use before signing certificate: SHA-256 shall be supported, SHA-384 should be supported, MD5, MD2, and SHA-1 shall not be supported. 

Question: Does EJBCA use the algorithms MD5, MD2, and SHA-1, and is it possible to limit/select which hash algorithms to use?

Answer: Section 6.1.1 relates to issued certificates. In EJBCA this is a configuration issue. If you configure your CAs correctly they are compliant with all of 6.1.1. MD2 and MD5 are not supported for issuing certificates in EJBCA. SHA-1 is supported for legacy reasons, but only if the CA is configured to use SHA-1. A default configuration of a CA will not use SHA-1.

Certificate enrollment for base stations - CMPv2 Profiling

General Requirements (section 9.5.1)

The technical specification states:

The hash algorithms used before generating signatures in the protection field of PKIMessage and for proof-of-possession shall be the same as the hash algorithms specified in sub-clause 6.1.1.

Question: Is it possible to select which hash algorithms to allow for proof-of-possession? Will EJBCA allow any of the non-allowed algorithms from 33.310 to be used? I.e. MD5, MD2, and SHA-1.

Answer: Related to the response message sent by EJBCA as a response to a request the default algorithm is SHA256. SHA1 is supported if requested by the client sending the request. MD2 and MD5 are not supported. As EJBCA strictly enforces one-time vendor certificate enrollment for initial requests from new clients (base stations), it is not possible for a compromised base station to weaken the overall security of the system.

Profile for the PKIMessage (section 9.5.2)

The technical specification states:

The support and usage of the optional protection field of type PKIProtection is required by this profile.

Question: Does EJBCA already require this field? Since it is an optional field in CMP, is there a setting to make this field required so that certain CMP profiles can be satisfied, such as 3GPP?

Answer: Yes when using CMP in Vendor certificate mode the usage of PKIProtection and extraCerts as defined in 9.5.2 are required in CMP request sent by the client.

The technical specification states:

All CMPv2 messages used within this profile shall consist of exactly one PKIMessage.

Question: Is there a way in EJBCA to specify that a message can only contain one PKIMessage? Will EJBCA allow multiple PKIMessage objects in one message?

Answer: EJBCA will not allow multiple PKIMessage objects, by default. A sequence of PKIMessages is possible when using the specific message type NestedMessageContent (RFC4210 section 5.1.3.4). EJBCA does support NestedMessageContent but requires specific configuration to support this, without this (non-default) configuration, NestedMessageContent verification will always fail.

The technical specification states:

The support of the optional extraCerts field is required by this profile. The certificates within this field may be ordered in any order.

Question: Will EJBCA allow certificates in the extra field to be in any order? For example, if it is a chain of certs, do they need to be added in a specific order? Or does EJBCA support that they may be ordered in any order?

Answer: EJBCA accepts extraCerts in any order.

Profile for the PKIHeader Field (section 9.5.3)

The technical specification states:

The sender and recipient fields shall contain the identities of the base station and the RA/CA. These identities shall be identical to the subject name present in the certificate.

Question: Does EJBCA either a) already require this, or b) can require that the PKIMessage.header.sender matches the subject name of the certificate for the key used to sign the PKIMessage, and that PKIMessage.header.recipient matches the subject name of the CA’s certificate?

Answer: Yes, this is required. The subject is matched against the pre-registered end entity in EJBCA, based on the subject name field. If the DN pre-registered (which will be included in the issued certificate) does not match the end entity will not be found and not certificate can be issued. The recipient field is used to select the CA used, so if this does not match the CAs certificate, the CA to sign the certificate will not be found. 

The technical specification states:

The field “protectionAlg” of PKIHeader is mandatory.

Question: Does EJBCA either require this field already or can make it mandatory in a configuration? Is it possible to limit the algorithm type allowed to put in this field?

Answer: Yes, protectionAlg is required to verify the protection, which is required. It is not possible to limit the algorithm allowed in this field (outside what is available or not). It is up to the client to determine the algorithm to use.

The technical specification states:

The signature algorithm shall be based upon the algorithm contained in the algorithm field of the SubjectPublicKeyInfo field of the signer’s certificate

Question: Does EJBCA already require this? If not, is it possible to enforce through a configuration that the signature algorithm used in computing PKIMessage.protection matches the SubjectPublicKeyInfo.algorithm field in the signing key’s certificate?

Answer: Yes, the algorithm and key must match, as the signature is verified, verification will fail if it does not match. The base station would also not be able to create the signature if the algorithm does not match the key.

The technical specification states:

The usage of the transactionID field is mandatory

Question: Does EJBCA enforce this? If not, can it be enforced through a configuration?

Answer: As of RFC 4210 a client MAY populate the transactionID field of the request". EJBCA supports it and will handle it properly if sent by the client. However, it is not enforced to be used.

The technical specification states:

The usage of the senderNonce and the recipNonce fields is mandatory

Question: Does EJBCA populate senderNonce and require/validate recipNonce? If using HSM, can the senderNonce be generated in the HSM, or the random number be seeded by the HSM? And if seeded, can it get a new seed after X amount of usage?

Answer: senderNonce is populated by the client, i.e. the base station. EJBCA supports senderNonce, and populates recipNonce with the same value as senderNonce (RFC4210 section 5.1.1). As senderNonce is created by the sender (client/base station) the HSM used by EJBCA is not relevant.

The technical specification states:

The recipNonce in the very first message in the transaction should be set to 0 by the sender and shall be disregarded by the recipient of the message.

Question: Will EJBCA ignore the recipNonce in the first message?

Answer: Yes it is ignored

Profile for the PKIBody Field - Initialization Request (section 9.5.4.2)

The technical specification states:

The Initialization Request as specified in IETF RFC 4210 [4] shall contain exactly one CertReqMessages

Question: Does EJBCA enforce this requirement?

Answer: EJBCA only supports one request message. If a PKIBody contains multiple CertReqMsg, only the first one is used.

The technical specification states:

The publicKey field of the CertTemplate shall be mandatory and shall contain the public key of the base station to be certified by the RA/CA

Does EJBCA require PKIMessage.body.ir[0].certReq.certTemplate.publicKey to be present and that it contains a value of type SubjectPublicKeyInfo (as defined in RFC 5280)?

Answer: Yes.

The technical specification states:

The CertReqMessage shall contain a POP field of type ProofOfPossession

Question: Does EJBCA enforce that PKIMessage.body.ir[0].popo is present and contains a signature element?

Answer: Yes it is enforced. Unless "RA Verify Proof-of-Possession" is configured in the CMP Alias in EJBCA, which is not possible to have configured when using 3GPP (Vendor/Client) Mode.

The technical specification states:

If the poposkInput field of type POPOSigningKeyInput within POPOSigningKey field is used, the sender field within POPOSigningKeyInput shall be mandatory and shall contain the identity of the base station

Question: Does EJBCA comply with this requirement?

Answer: Yes, if POPOSigningKeyInput the sender must be the same as the sender in the request, which must be the same as the identity of the base station.

The technical specification states:

The extraCerts field of the PKIMessage carrying the initialization request shall be mandatory and shall contain the base station certificate provided by the vendor. If the base station certificate is not signed by the vendor root CA, also the intermediate certificates for the chain up to the vendor root certificate shall be included in the extraCerts field.

Question: It does not seem to require that the vendor root CA be included, will EJBCA accept requests that do not have the root CA included in the extra certs?

Answer: Yes, EJBCA accepts requests both with and without the Root CA certificate included in extraCerts. Our interpretation is that the Root CA certificate should not be included in extraCerts, since it must be trusted out-of-band, but we accept, and verify either way.

Profile for the PKIBody Field - Initialization Response (section 9.5.4.3)

The technical specification states:

The Initialization Response as specified in [4] shall contain exactly one generated base station certificate

Question: Will EJBCA ever send more than one CertResponse structure?

Answer: Only one CertResponse structure can be sent by EJBCA.

The technical specification states:

The generated certificate shall be transferred to the base station in the certifiedKeyPair field of the CertResponse field

Question: Does EJBCA place the generated certificate in the certifiedKeyPair field?

Answer: Yes.

The technical specification states:

The transfer shall not be encrypted (i.e. the certificate field in CertorEncCert shall be mandatory).

Question: Will EJBCA ever encrypt the certificate/transfer? Does EJBCA have the capability of supporting encryption?

Answer: EJBCA will not encrypt the CertifiedKeyPair when using in 3GPP configuration. CertifiedKeyPair is only encrypted when server-generated keys are requested and the private key returned in the message. Server-generated keys are only generated as a response to such requests as of RFC4210 Appendix D.4, and only when "Allow server generated keys" is enabled in the CMP Alias configuration, which is not the default configuration.

Profile for the PKIBody Field - Key Update Request and Key Update Response (section 9.5.4.4)

The technical specification states:

The extraCertsField shall be mandatory and shall contain the base station certificate related to the private key used for signing the PKIMessage. Any intermediate CA certificates shall also be included if the base station certificate is not signed directly by a root CA.

Question: Does EJBCA enforce this already?

Answer: Yes. EJBCA does support for the intermediate CA certificate to not be included in the request, as we have seen this (non-compliant) behavior by production equipment from some vendors, this, however, requires that the intermediate CA certificate is enabled as a trusted "Vendor CA" in the CMP Alias configuration.


Question: RFC 4210 states that a newly issued certificate whose receipt is not confirmed shall be revoked. It says on the EJBCA documentation page that EJBCA does not adhere to this requirement of RFC 4210. Is it planned to at least make this a configuration in future releases? EJBCA should not make the decision for the user whether this is a good feature of the standard or not. This is a concern to me as revoking certs that are not confirmed is a requirement.

Answer: We have no such plans at the moment. It is becoming more common to instead use the ImplicitConfirm feature in RFC4210 section 5.3.19.10.

Profile for the PKIBody Field - Certificate Confirm Request and Confirmation Response (section 9.5.4.5)

The technical specification states:

The extraCerts field of the PKIMessage carrying the Certificate Confirm request and Confirmation response shall be omitted.

Question: Does EJBCA adhere to this?

Answer: Yes, no extraCerts field is included in the Confirmation response message.