This section focuses on the communication of an EE with the PKI management entity it directly talks to. Depending on the network and PKI solution, this can be an RA or directly a CA. Handling of a message by a PKI management entity is described in
Section 5.
The PKI management operations specified in this section cover the following:
-
requesting a certificate with variations like initial enrollment, certificate updates, central key generation, and MAC-based protection
-
revoking a certificate
-
support messages
-
polling for delayed response messages
These operations mainly specify the message body of the CMP messages and utilize the specification of the message header, protection, and extraCerts, as specified in
Section 3. The messages are named by the respective field names in PKIBody, like ir, ip, cr, cp, etc.; see
Section 5.1.2 of
RFC 4210.
The following diagram shows the EE state machine covering all PKI management operations described in this section, including negative responses, error messages described in
Section 3.6.4, ip/cp/kup/error messages with status "waiting", and pollReq and pollRep messages as described in
Section 4.4.
On receiving messages from upstream, the EE
MUST perform the general validation checks described in
Section 3.5. In case an error occurs, the behavior is described in
Section 3.6.
End Entity State Machine:
start
|
| send ir/cr/kur/p10cr/rr/genm
v
waiting for response
v
+--------------------------+--------------------------+
| | |
| receives ip/cp/kup with | received ip/cp/kup/error | received
| status "accepted" or | with status "waiting" | rp/genp or
| "grantedWithMods" | | ip/cp/kup/
| v | error
| +-------> polling | with status
| | | | "rejection"
| | received | send |
| | pollRep | pollReq |
| | v |
| | waiting for response |
| | v |
| +------------+--------+ |
| | | |
| received ip/cp/kup | | received |
| with status "accepted" | | rp/genp or |
| or "grantedWithMods" | | ip/cp/kup/error |
| | | with status |
+---------->+<-------------+ | "rejection" |
v | |
+-----------+-----+ | |
| | | |
| implicitConfirm | implicitConfirm | |
| granted | not granted | |
| | | |
| | send certConf | |
| v | |
| waiting for pkiConf*) | |
| | | |
| | received | |
| v pkiConf v |
+---------------->+------->+<-------+<----------------+
|
v
end
-
*)
-
In case of a delayed delivery of pkiConf responses, the same polling mechanism is initiated as for rp or genp messages by sending an error message with status "waiting".
Note: All CMP messages belonging to the same PKI management operation
MUST have the same transactionID because the message receiver identifies the elements of the operation in this way.
This section is aligned with [
RFC 4210], [
RFC 9480], and [
RFC 9481].
Guidelines as well as an algorithm use profile for this document are available in [
RFC 9481].
There are various approaches for requesting a certificate from a PKI.
These approaches differ in the way the EE authenticates itself to the PKI, in the form of the request being used, and how the key pair to be certified is generated. The authentication mechanisms may be as follows:
-
using a certificate from an external PKI, e.g., a manufacturer-issued device certificate, and the corresponding private key
-
using a private key and certificate issued from the same PKI that is addressed for requesting a certificate
-
using the certificate to be updated and the corresponding private key
-
using shared secret information known to the EE and the PKI management entity
An EE requests a certificate indirectly or directly from a CA. When the PKI management entity handles the request as described in
Section 5.1.1 and responds with a message containing the requested certificate, the EE
MUST reply with a confirmation message unless implicitConfirm was granted. The PKI management entity
MUST then handle it as described in
Section 5.1.2 and respond with a confirmation, closing the PKI management operation.
The message sequences described in this section allow the EE to request certification of a locally or centrally generated public-private key pair. The public key and the subject name identifying the EE
MUST be present in the certTemplate of the certificate request message.
Note: If the EE does not know for which subject name to request the certificate, it can use the subject name from the CMP protection certificate in case of signature-based protection or the identifier of the shared secret in case of MAC-based protection.
Typically, the EE provides a signature-based proof-of-possession of the private key associated with the public key contained in the certificate request, as defined by
RFC 4211,
Section 4.1, clause 3. To this end, it is assumed that the private key can technically be used for signing. This is the case for the most common algorithms RSA, ECDSA, and EdDSA, regardless of potentially intended restrictions of the key usage.
Note:
Section 4 of
RFC 4211 allows for providing proof-of-possession using any method that a key can be used for. In conformance with Section 8.1.5.1.1.2 of [
NIST.SP.800-57p1r5], the newly generated private key may be used for self-signature, if technically possible, even if the keyUsage extension requested in the certificate request prohibits generation of digital signatures.
The requesting EE provides the binding of the proof-of-possession to its identity by signature-based or MAC-based protection of the CMP request message containing that POP. An upstream PKI management entity should verify whether this EE is authorized to obtain a certificate with the requested subject and other fields and extensions.
The proof-of-possession is provided by signing the certReq containing the certTemplate with the subject name and public key. To bind this proof-of-possession to the proof-of-identity of the requesting EE, the subject name in the certTemplate needs to identify the same entity as the subject name in the CMP protection certificate or match the identifier used with MAC-based protection.
Note: This binding may be lost if a PKI management entity reprotects this request message.
The EE
MAY indicate the certificate profile to use in the certProfile extension of the generalInfo field in the PKIHeader of the certificate request message as described in
Section 3.1.
In case the EE receives a CA certificate in the caPubs field for installation as a new trust anchor, it
MUST properly authenticate the message and authorize the sender as a trusted source of the new trust anchor. This authorization is typically indicated using shared secret information for protecting an Initialization Response (ip) message. Authorization can also be signature-based, using a certificate issued by another PKI that is explicitly authorized for this purpose. A certificate received in caPubs
MUST NOT be accepted as a trust anchor if it is the root CA certificate of the certificate used for protecting the message.
This PKI management operation should be used by an EE to request a certificate from a new PKI using an existing certificate from an external PKI, e.g., a manufacturer-issued IDevID certificate [
IEEE.802.1AR_2018], to authenticate itself to the new PKI.
Note: In [
RFC 8995] environments, [
BRSKI-AE] describes a generalization regarding enrollment protocols alternative to [
RFC 7030]. As replacement of EST simpleenroll, BRSKI-AE uses this PKI management operation for bootstrapping LDevID certificates.
Specific prerequisites augmenting the prerequisites in
Section 3.4 are as follows:
-
The certificate of the EE MUST have been enrolled by an external PKI, e.g., a manufacturer-issued device certificate.
-
The PKI management entity MUST have the trust anchor of the external PKI.
-
When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
Message Flow:
Step# EE PKI management entity
1 format ir
2 -> ir ->
3 handle or
forward ir
4 format or receive ip
5 possibly grant
implicitConfirm
6 <- ip <-
7 handle ip
----------------- if implicitConfirm not granted -----------------
8 format certConf
9 -> certConf ->
10 handle or
forward certConf
11 format or receive pkiConf
12 <- pkiConf <-
13 handle pkiConf
For this PKI management operation, the EE
MUST include a sequence of one CertReqMsg in the ir. If more certificates are required, further requests
MUST be sent using separate PKI management operations.
The EE
MUST include the generalInfo field implicitConfirm in the header of the ir message as described in
Section 3.1, unless it requires certificate confirmation. This leaves the PKI management entities the choice of whether or not the EE must send a certConf message upon receiving a new certificate. Depending on the PKI policy and requirements for managing EE certificates, it can be important for PKI management entities to learn if the EE accepted the new certificate. In such cases, when responding with an ip message, the PKI management entity
MUST NOT include the implicitConfirm extension. In case the EE included the generalInfo field implicitConfirm in the request message and the PKI management entity does not need any explicit confirmation from the EE, the PKI management entity
MUST include the generalInfo field implicitConfirm in the response message. This prevents explicit certificate confirmation and saves the overhead of a further message round trip. Otherwise, the PKI management entity
SHOULD include confirmWaitTime as described in
Section 3.1.
If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation
MUST be performed as follows. If the EE successfully received the certificate, it
MUST send a certConf message in due time. On receiving a valid certConf message, the PKI management entity
MUST respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time, it
MUST handle this like a rejection by the EE. In case of rejection, depending on its policy, the PKI management entity
MAY revoke the newly issued certificate, notify a monitoring system, or log the event internally.
Note: Depending on PKI policy, a new certificate may be published by a PKI management entity, and explicit confirmation may be required. In this case, it is advisable not to do the publication until a positive certificate confirmation has been received. This way, the need to revoke the certificate on negative confirmation can be avoided.
If the certificate request was rejected by the CA, the PKI management entity
MUST return an ip message containing the status code "rejection" as described in
Section 3.6, and the certifiedKeyPair field
SHALL be omitted. The EE
MUST NOT react to such an ip message with a certConf message, and the PKI management operation
MUST be terminated.
Detailed Message Description:
Initialization Request -- ir
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE for a new certificate
ir REQUIRED
-- MUST contain a sequence of one CertReqMsg
-- If more certificates are required, further PKI management
-- operations needs to be initiated
certReq REQUIRED
certReqId REQUIRED
-- MUST be 0
certTemplate REQUIRED
version OPTIONAL
-- MUST be 2 if supplied
subject REQUIRED
-- The EE's identity MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
publicKey OPTIONAL
-- MUST be present if local key generation is used
-- MAY be absent if central key generation is requested
algorithm OPTIONAL
-- MUST be present if local key generation is used and MUST
-- include the subject public key algorithm identifier
-- MAY be present if central key generation is requested and,
-- if present, informs the KGA of algorithm and parameter
-- preferences regarding the to-be-generated key pair
subjectPublicKey REQUIRED
-- MUST contain the public key to be certified in case of local
-- key generation
-- MUST be a zero-length BIT STRING if central key generation
-- is requested
extensions OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate, like subject alternative name, key
-- usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE subject
-- name includes a subject alternative name.
popo OPTIONAL
-- MUST be present if local key generation is used
-- MUST be absent if central key generation is requested
signature OPTIONAL
-- MUST be used by an EE if the key can be used for signing, and
-- if used, it MUST have the type POPOSigningKey
poposkInput PROHIBITED
-- MUST NOT be used; it is not needed because subject and
-- publicKey are both present in the certTemplate
algorithmIdentifier REQUIRED
-- The signature algorithm MUST be consistent with the publicKey
-- algorithm field of the certTemplate
signature REQUIRED
-- MUST contain the signature value computed over the DER-encoded
-- certReq
raVerified OPTIONAL
-- MAY be used by an RA after verifying the proof-of-possession
-- provided by the EE
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
Initialization Response -- ip
Field Value
header
-- As described in Section 3.1
body
-- The response of the CA to the request as appropriate
ip REQUIRED
caPubs OPTIONAL
-- MAY be used if the certifiedKeyPair field is present
-- If used, it MUST contain only a trust anchor, e.g., root
-- certificate, of the certificate contained in certOrEncCert
response REQUIRED
-- MUST contain a sequence of one CertResponse
certReqId REQUIRED
-- MUST be 0
status REQUIRED
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- positive values allowed: "accepted", "grantedWithMods"
-- negative values allowed: "rejection"
-- "waiting" only allowed with a polling use case as described
-- in Section 4.4
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted" or "grantedWithMods"
certifiedKeyPair OPTIONAL
-- MUST be present if status is "accepted" or "grantedWithMods"
-- MUST be absent if status is "rejection"
certOrEncCert REQUIRED
-- MUST be present if status is "accepted" or "grantedWithMods"
certificate REQUIRED
-- MUST be present when certifiedKeyPair is present
-- MUST contain the newly enrolled X.509 certificate
privateKey OPTIONAL
-- MUST be absent in case of local key generation or "rejection"
-- MUST contain the encrypted private key in an EnvelopedData
-- structure as specified in Section 4.1.6 in case the
-- private key was generated centrally
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
-- MUST contain the chain of the certificate present in
-- certOrEncCert
-- Duplicate certificates MAY be omitted
Certificate Confirmation -- certConf
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE sends a confirmation to the PKI
-- management entity to accept or reject the issued
-- certificates
certConf REQUIRED
-- MUST contain a sequence of one CertStatus
CertStatus REQUIRED
certHash REQUIRED
-- The hash algorithm to use MUST be the hash algorithm indicated
-- in the below hashAlg field. If the hashAlg field is not
-- set, it MUST be the hash algorithm defined by the algorithm
-- identifier of the certificate signature or the dedicated
-- hash algorithm defined in [RFC9481] for the used certificate
-- signature algorithm.
certReqId REQUIRED
-- MUST be 0
statusInfo OPTIONAL
-- PKIStatusInfo structure should be present
-- Omission indicates acceptance of the indicated certificate
status REQUIRED
-- positive values allowed: "accepted"
-- negative values allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if status is "rejection"
-- MUST be absent if status is "accepted"
hashAlg OPTIONAL
-- The hash algorithm to use for calculating the above certHash
-- If used, the pvno field in the header MUST be cmp2021 (3).
-- For backward compatibility, use of this field is
-- NOT RECOMMENDED if the hash algorithm to use can be
-- identified by other means; see above.
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of this PKI management operation
PKI Confirmation -- pkiConf
Field Value
header
-- As described in Section 3.1
body
pkiconf REQUIRED
-- The content of this field MUST be NULL
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of this PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of this PKI management operation
This PKI management operation should be used by an EE to request an additional certificate of the same PKI it already has certificates from. The EE uses one of these existing certificates to authenticate itself by signing its request messages using the respective private key.
Specific prerequisites augmenting the prerequisites in
Section 3.4 are as follows:
-
The certificate used by the EE MUST have been enrolled by the PKI it requests another certificate from.
-
When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical to that given in
Section 4.1.1, with the following changes:
-
The body of the first request and response SHOULD be cr and cp. Otherwise, ir and ip MUST be used.
Note: Since the difference between ir/ip and cr/cp is syntactically not essential, an ir/ip may be used in this PKI management operation.
-
The caPubs field in the certificate response message MUST be absent.
This PKI management operation should be used by an EE to request an update for one of its certificates that is still valid. The EE uses the certificate it wishes to update as the CMP protection certificate. Both for authenticating itself and for proving ownership of the certificate to be updated, it signs the request messages with the corresponding private key.
Specific prerequisites augmenting the prerequisites in
Section 3.4 are as follows:
-
The certificate the EE wishes to update MUST NOT be expired or revoked and MUST have been issued by the addressed CA.
-
A new public-private key pair should be used.
-
When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical to that given in
Section 4.1.1, with the following changes:
-
The body of the first request and response MUST be kur and kup, respectively.
-
Protection of the kur MUST be performed using the certificate to be updated.
-
The subject field and/or the subjectAltName extension of the certTemplate MUST contain the EE subject name of the existing certificate to be updated, without modifications.
-
The certTemplate SHOULD contain the subject and/or subjectAltName extension and publicKey of the EE only.
-
The oldCertId control MAY be used to make clear which certificate is to be updated.
-
The caPubs field in the kup message MUST be absent.
As part of the certReq structure of the kur, the oldCertId control is added after the certTemplate field.
controls
type RECOMMENDED
-- MUST be the value id-regCtrl-oldCertID, if present
value
issuer REQUIRED
serialNumber REQUIRED
-- MUST contain the issuer and serialNumber of the certificate
-- to be updated
This PKI management operation can be used by an EE to request a certificate using the [
RFC 2986] format to interoperate with CAs not supporting [
RFC 4211]. This offers a variation of the PKI management operations specified in Sections [
4.1.1] to [
4.1.3].
In this PKI management operation, the public key and all further certificate template data
MUST be contained in the subjectPKInfo and other certificationRequestInfo fields of the PKCS #10 structure.
The prerequisites are the same as given in
Section 4.1.2.
The message sequence for this PKI management operation is identical to that given in Sections [
4.1.1] to [
4.1.3], with the following changes:
-
The body of the first request and response MUST be p10cr and cp, respectively.
-
The certReqId in the cp message MUST be -1.
Detailed Message Description:
Certification Request -- p10cr
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE for a new certificate using a PKCS #10
-- certificate request
p10cr REQUIRED
certificationRequestInfo REQUIRED
version REQUIRED
-- MUST be 0 to indicate PKCS #10 v1.7
subject REQUIRED
-- The EE subject name MUST be carried in the subject field
-- and/or the subjectAltName extension.
-- If subject name is present only in the subjectAltName
-- extension, then the subject field MUST be NULL-DN
subjectPKInfo REQUIRED
algorithm REQUIRED
-- MUST include the subject public key algorithm identifier
subjectPublicKey REQUIRED
-- MUST include the public key to be certified
attributes OPTIONAL
-- MAY include end-entity-specific X.509 extensions of the
-- requested certificate like subject alternative name,
-- key usage, and extended key usage
-- The subjectAltName extension MUST be present if the EE
-- subject name includes a subject alternative name.
signatureAlgorithm REQUIRED
-- The signature algorithm MUST be consistent with the
-- subjectPKInfo field.
signature REQUIRED
-- MUST contain the self-signature for proof-of-possession
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described for the underlying PKI management operation
This is a variant of the PKI management operations described in Sections [
4.1.1], [
4.1.2], and [
4.1.4]. It should be used by an EE to request a certificate of a new PKI in case it does not have a certificate to prove its identity to the target PKI but has some secret information shared with the PKI management entity. Therefore, the request and response messages are MAC-protected using this shared secret information. The distribution of this shared secret is out of scope for this document. The PKI management entity checking the MAC-based protection
MUST replace this protection according to
Section 5.2.3, as the next hop may not know the shared secret information.
Note: The entropy of the shared secret information is crucial for the level of protection when using MAC-based protection. Further guidance is available in the security considerations updated by [
RFC 9480].
Specific prerequisites augmenting the prerequisites in
Section 3.4 are as follows:
-
Rather than using private keys, certificates, and trust anchors, the EE and the PKI management entity MUST share secret information.
Note: The shared secret information MUST be established out of band, e.g., by a service technician during initial local configuration.
-
When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is identical to that given in Sections [
4.1.1], [
4.1.2], and [
4.1.4], with the following changes:
-
The protection of all messages MUST be MAC-based. Therefore, extraCerts fields of all messages do not contain CMP protection certificates and associated chains.
-
The sender field MUST contain a name the PKI management entity can use to identify the shared secret information used for message protection. This name MUST be placed in the commonName field of the directoryName choice. The senderKID MUST contain the same name as in the commonName field of the sender field. In case the sending entity does not yet know for which name to request the certificate, it can use this commonName in the subject field of the certTemplate.
See
Section 6 of
RFC 9481 for details on message authentication code algorithms (MSG_MAC_ALG) to use. Typically, parameters are part of the protectionAlg field, e.g., used for key derivation, like a salt and an iteration count. Such parameters should remain constant for message protection throughout this PKI management operation to reduce the computational overhead.
This is a variant of the PKI management operations described in Sections [
4.1.1] to [
4.1.4] and the variant described in
Section 4.1.5. It needs to be used in case an EE is not able to generate its new public-private key pair itself or central generation of the EE key material is preferred. Which PKI management entity will act as Key Generation Authority (KGA) and perform the key generation is a matter of the local implementation. This PKI management entity
MUST use a certificate containing the additional extended key usage extension id-kp-cmKGA in order to be accepted by the EE as a legitimate key generation authority.
Note: As described in
Section 5.3.1, the KGA can use the PKI management operation described in
Section 4.1.2 to request the certificate for this key pair on behalf of the EE.
When an EE requests central key generation for a certificate update using a kur message, the KGA cannot use a kur message to request the certificate on behalf of the EE, as the old EE credential is not available to the KGA for protecting this message. Therefore, if the EE uses the PKI management operation described in
Section 4.1.3, the KGA
MUST act as described in
Section 4.1.2 to request the certificate for the newly generated key pair on behalf of the EE from the CA.
Generally speaking, it is strongly preferable to generate public-private key pairs locally at the EE. This is advisable to make sure that the entity identified in the newly issued certificate is the only entity that knows the private key.
Reasons for central key generation may include the following:
-
lack of sufficient initial entropy
Note: Good random numbers are not only needed for key generation but also for session keys and nonces in any security protocol. Therefore, a decent security architecture should anyways support good random number generation on the EE side or provide enough initial entropy for the random number generator seed to guarantee good pseudorandom number generation. Yet maybe this is not the case at the time of requesting an initial certificate during manufacturing.
-
lack of computational resources, in particular, for RSA key generation
Note: Since key generation could be performed in advance to the certificate enrollment communication, it is often not time critical.
Note: As mentioned in
Section 2, central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without a previous request message.
The EE requesting central key generation
MUST omit the publicKey field from the certTemplate or, in case it has a preference on the key type to be generated, provide this preference in the algorithm sub-field and fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both variants indicate to the PKI management entity that a new key pair shall be generated centrally on behalf of the EE.
Note: As the protection of centrally generated keys in the response message has been extended to EncryptedKey by
Section 2.7 of
RFC 9480, EnvelopedData is the preferred alternative to EncryptedValue. In
RFC 4211,
Section 2.1, point 9, the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile requires using EnvelopedData, as specified in
Section 6 of
RFC 5652. When EnvelopedData is to be used in a PKI management operation, CMP v3
MUST be indicated in the message header already for the initial request message; see
Section 2.20 of
RFC 9480.
+----------------------------------+
| EnvelopedData |
| [RFC5652], Section 6 |
| +------------------------------+ |
| | SignedData | |
| | [RFC5652], Section 5 | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage | | |
| | | [RFC5958] | | |
| | | +----------------------+ | | |
| | | | private key | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+
The PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message also containing the newly issued certificate.
The private key
MUST be provided as an AsymmetricKeyPackage structure as defined in [
RFC 5958].
This AsymmetricKeyPackage structure
MUST be wrapped in a SignedData structure, as specified in
Section 5 of
RFC 5652 and [
RFC 8933], and signed by the KGA generating the key pair. The signature
MUST be performed using a private key related to a certificate asserting the extended key usage id-kp-cmKGA, as described in
Section 2.2 of
RFC 9480, to demonstrate authorization to generate key pairs on behalf of an EE. For response messages using signature-based protection, the EE
MUST validate the signer certificate contained in the SignedData structure and
SHOULD authorize the KGA considering any given id-kp-cmKGA extended key usage in the signer certificate. For response messages using MAC-based protection, the EE
MAY omit the validation as it may not be possible or meaningful to the EE. In this case, the EE authorizes the KGA using the shard secret information.
The SignedData structure
MUST be wrapped in an EnvelopedData structure, as specified in
Section 6 of
RFC 5652, encrypting it using a newly generated symmetric content-encryption key.
This content-encryption key
MUST be securely provided as part of the EnvelopedData structure to the EE using one of three key management techniques. The choice of the key management technique to be used by the PKI management entity depends on the authentication mechanism the EE chose to protect the request message. See
Section 2.7 of
RFC 9480 for details on which key management technique to use.
-
Signature-based protection of the request message:
In this case, the choice depends on the type of public key in the CMP protection certificate used by the EE in its request.
-
The content-encryption key SHALL be protected using the key transport key management technique (see Section 4.1.6.1) if the key type supports this.
-
The content-encryption key SHALL be protected using the key agreement key management technique (see Section 4.1.6.2) if the key type supports this.
-
MAC-based protection of the request message:
-
The content-encryption key SHALL be protected using the password-based key management technique (see Section 4.1.6.3) if and only if the EE used MAC-based protection for the request message.
Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations are as follows:
-
If signature-based protection is used, the EE MUST be able to authenticate and authorize the KGA using suitable information, which includes a trust anchor.
-
If MAC-based protection is used, the KGA MUST also know the shared secret information to protect the encrypted transport of the newly generated key pair. Consequently, the EE can also authorize the KGA.
-
The PKI management entity MUST have a certificate containing the additional extended key usage extension id-kp-cmKGA for signing the SignedData structure containing the private key package.
-
For encrypting the SignedData structure, a fresh content-encryption key to be used by the symmetric encryption algorithm MUST be generated with sufficient entropy.
Note: The security strength of the protection of the generated private key should be similar or higher than the security strength of the generated private key.
Detailed Description of the privateKey Field:
privateKey REQUIRED
-- MUST be an EnvelopedData structure, as specified in
-- Section 6 of CMS [RFC5652]
version REQUIRED
-- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
-- KeyTransRecipientInfo
-- MUST be 0 for recipientInfo type PasswordRecipientInfo
recipientInfos REQUIRED
-- MUST contain a sequence of one RecipientInfo, which MUST be
-- ktri of type KeyTransRecipientInfo (see Section 4.1.6.1),
-- kari of type KeyAgreeRecipientInfo (see Section 4.1.6.2), or
-- pwri of type PasswordRecipientInfo (see Section 4.1.6.3)
encryptedContentInfo
REQUIRED
contentType REQUIRED
-- MUST be id-signedData
contentEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the algorithm used for
-- content encryption
-- The algorithm type MUST be PROT_SYM_ALG as specified in
-- [RFC9481], Section 5
encryptedContent REQUIRED
-- MUST be the SignedData structure, as specified in Section 5
-- of CMS [RFC5652] and [RFC8933], in encrypted form
version REQUIRED
-- MUST be 3
digestAlgorithms
REQUIRED
-- MUST contain a sequence of one AlgorithmIdentifier element
-- MUST be the algorithm identifier of the digest algorithm
-- used for generating the signature and match the signature
-- algorithm specified in signatureAlgorithm; see [RFC8933]
encapContentInfo
REQUIRED
-- MUST contain the content that is to be signed
eContentType REQUIRED
-- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958]
eContent REQUIRED
-- MUST be of type AsymmetricKeyPackage and
-- MUST contain a sequence of one OneAsymmetricKey element
version REQUIRED
-- MUST be 1 (indicating v2)
privateKeyAlgorithm
REQUIRED
-- The privateKeyAlgorithm field MUST contain the algorithm
-- identifier of the asymmetric key pair algorithm
privateKey REQUIRED
publicKey REQUIRED
-- MUST contain the public key corresponding to the private key
-- for simplicity and consistency with v2 of OneAsymmetricKey
certificates REQUIRED
-- MUST contain the certificate for the private key used to sign
-- the signedData content, together with its chain
-- The first certificate in this field MUST be the KGA
-- certificate used for protecting this content
-- Self-signed certificates should not be included and MUST NOT
-- be trusted based on their inclusion in any case
signerInfos REQUIRED
-- MUST contain a sequence of one SignerInfo element
version REQUIRED
-- MUST be 3
sid REQUIRED
subjectKeyIdentifier
REQUIRED
-- MUST be the subjectKeyIdentifier of the KGA certificate
digestAlgorithm
REQUIRED
-- MUST be the same as in the digestAlgorithms field of
-- encryptedContent
signedAttrs REQUIRED
-- MUST contain an id-contentType attribute containing the value
-- id-ct-KP-aKeyPackage
-- MUST contain an id-messageDigest attribute containing the
-- message digest of eContent
-- MAY contain an id-signingTime attribute containing the time
-- of a signature. It SHOULD be omitted if the transactionTime
-- field is not present in the PKIHeader.
-- For details on the signed attributes, see Sections 5.3 and
-- 11 of CMS [RFC5652] and [RFC8933]
signatureAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the signature algorithm
-- used for calculation of the signature bits
-- The signature algorithm type MUST be MSG_SIG_ALG, as
-- specified in [RFC9481], Section 3, and MUST be consistent
-- with the subjectPublicKeyInfo field of the KGA certificate
signature REQUIRED
-- MUST be the digital signature of the encapContentInfo
As stated in
Section 1.8, all fields of the ASN.1 syntax that are defined in [
RFC 5652] but are not explicitly specified here
SHOULD NOT be used.
This variant can be applied in combination with the PKI management operations specified in Sections [
4.1.1] to [
4.1.3] using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message
MUST contain a public key supporting key transport and allow for the key usage "keyEncipherment". The related key pair
MUST be used for encipherment of the content-encryption key. For this key management technique, the KeyTransRecipientInfo structure
MUST be used in the contentInfo field.
The KeyTransRecipientInfo structure included into the EnvelopedData structure is specified in
Section 6.2.1 of
RFC 5652.
Detailed Description of the KeyTransRecipientInfo Structure:
ktri REQUIRED
-- MUST be KeyTransRecipientInfo as specified in Section 6.2.1
-- of CMS [RFC5652]
version REQUIRED
-- MUST be 2
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key transport
-- algorithm. The algorithm type MUST be KM_KT_ALG as
-- specified in [RFC9481], Section 4.2
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
This variant can be applied in combination with the PKI management operations specified in Sections [
4.1.1] to [
4.1.3], using signature-based protection of CMP messages. The EE certificate used for the signature-based protection of the request message
MUST contain a public key supporting key agreement and allow for the key usage "keyAgreement". The related key pair
MUST be used for establishment of the content-encryption key. For this key management technique, the KeyAgreeRecipientInfo structure
MUST be used in the contentInfo field.
The KeyAgreeRecipientInfo structure included into the EnvelopedData structure is specified in
Section 6.2.2 of
RFC 5652.
Detailed Description of the KeyAgreeRecipientInfo Structure:
kari REQUIRED
-- MUST be KeyAgreeRecipientInfo as specified in Section
-- 6.2.2 of CMS [RFC5652]
version REQUIRED
-- MUST be 3
originator REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the subjectKeyIdentifier
-- choice, and the subjectKeyIdentifier MUST equal the
-- senderKID in the PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used.
ukm RECOMMENDED
-- MUST be used when 1-Pass Elliptic Curve Menezes-Qu-Vanstone
-- (ECMQV) is used; see [RFC5753]
-- SHOULD be present to ensure uniqueness of the key
-- encryption key
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key agreement
-- algorithm
-- The algorithm type MUST be KM_KA_ALG as specified in
-- [RFC9481], Section 4.1
-- The parameters field of the key agreement algorithm MUST
-- contain the key wrap algorithm. The algorithm type
-- MUST be KM_KW_ALG as specified in [RFC9481], Section 4.3
recipientEncryptedKeys
REQUIRED
-- MUST contain a sequence of one RecipientEncryptedKey
rid REQUIRED
-- MUST contain the subjectKeyIdentifier of the CMP protection
-- certificate, if available, in the rKeyId choice, and the
-- subjectKeyIdentifier MUST equal the senderKID in the
-- PKIHeader.
-- If the CMP protection certificate does not contain a
-- subjectKeyIdentifier, the issuerAndSerialNumber choice MUST
-- be used
encryptedKey
REQUIRED
-- MUST be the encrypted content-encryption key
This variant can be applied in combination with the PKI management operation specified in
Section 4.1.5, using MAC-based protection of CMP messages. The shared secret information used for the MAC-based protection
MUST also be used for the encryption of the content-encryption key but with a different salt value applied in the key derivation algorithm. For this key management technique, the PasswordRecipientInfo structure
MUST be used in the contentInfo field.
Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the shared secret information
SHALL NOT be less than the security strength of the centrally generated key pair. Further guidance is available in
Section 9.
The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in
Section 6.2.4 of
RFC 5652.
Detailed Description of the PasswordRecipientInfo Structure:
pwri REQUIRED
-- MUST be PasswordRecipientInfo as specified in
-- Section 6.2.4 of CMS [RFC5652]
version REQUIRED
-- MUST be 0
keyDerivationAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key derivation
-- algorithm
-- The algorithm type MUST be KM_KD_ALG as specified in
-- [RFC9481], Section 4.4
keyEncryptionAlgorithm
REQUIRED
-- MUST be the algorithm identifier of the key wrap algorithm
-- The algorithm type MUST be KM_KW_ALG as specified in
-- [RFC9481], Section 4.3
encryptedKey REQUIRED
-- MUST be the encrypted content-encryption key
This PKI management operation should be used by an entity to request revocation of a certificate. Here, the revocation request is used by an EE to revoke one of its own certificates.
The revocation request message
MUST be signed using the certificate that is to be revoked to prove the authorization to revoke. The revocation request message is signature-protected using this certificate. This requires that the EE still possesses the private key. If this is not the case, the revocation has to be initiated by other means, e.g., revocation by the RA, as specified in
Section 5.3.2.
An EE requests revoking a certificate of its own at the CA that issued this certificate. The PKI management entity handles the request as described in
Section 5.1.3, and responds with a message that contains the status of the revocation from the CA.
The specific prerequisite augmenting the prerequisites in
Section 3.4 is as follows:
-
The certificate the EE wishes to revoke is not yet expired or revoked.
Message Flow:
Step# EE PKI management entity
1 format rr
2 -> rr ->
3 handle or forward rr
4 format or receive rp
5 <- rp <-
6 handle rp
For this PKI management operation, the EE
MUST include a sequence of one RevDetails structure in the rr message body. In the case no generic error occurred, the response to the rr
MUST be an rp message containing a single status field.
Detailed Message Description:
Revocation Request -- rr
Field Value
header
-- As described in Section 3.1
body
-- The request of the EE to revoke its certificate
rr REQUIRED
-- MUST contain a sequence of one element of type RevDetails
-- If more revocations are desired, further PKI management
-- operations need to be initiated
certDetails REQUIRED
-- MUST be present and is of type CertTemplate
serialNumber REQUIRED
-- MUST contain the certificate serialNumber attribute of the
-- certificate to be revoked
issuer REQUIRED
-- MUST contain the issuer attribute of the certificate to be
-- revoked
crlEntryDetails REQUIRED
-- MUST contain a sequence of one reasonCode of type CRLReason
-- (see [RFC5280], Section 5.3.1)
-- If the reason for this revocation is not known or shall not
-- be published, the reasonCode MUST be 0 (unspecified)
protection REQUIRED
-- As described in Section 3.2 and using the private key related
-- to the certificate to be revoked
extraCerts REQUIRED
-- As described in Section 3.3
Revocation Response -- rp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity to the request as
-- appropriate
rp REQUIRED
status REQUIRED
-- MUST contain a sequence of one element of type PKIStatusInfo
status REQUIRED
-- positive value allowed: "accepted"
-- negative value allowed: "rejection"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo OPTIONAL
-- MAY be present if the status is "rejection"
-- MUST be absent if the status is "accepted"
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
The following support messages offer on-demand, in-band delivery of content relevant to the EE provided by a PKI management entity. CMP general messages and general response are used for this purpose. Depending on the environment, these requests may be answered by an RA or CA (see also
Section 5.1.4).
The general messages and general response messages contain InfoTypeAndValue structures. In addition to those infoType values defined in [
RFC 4210] and [
RFC 9480], further OIDs
MAY be used to define new PKI management operations or new general-purpose support messages as needed in specific environments.
The following contents are specified in this document:
-
Get CA certificates.
-
Get root CA certificate update.
-
Get certificate request template.
-
Get new Certificate Revocation Lists (CRLs).
The following message flow and contents are common to all general message (genm) and general response (genp) messages.
Message Flow:
Step# EE PKI management entity
1 format genm
2 -> genm ->
3 handle or forward genm
4 format or receive genp
5 <- genp <-
6 handle genp
Detailed Message Description:
General Message -- genm
Field Value
header
-- As described in Section 3.1
body
-- A request by the EE for information
genm REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying one of the specific PKI
-- management operations described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
General Response -- genp
Field Value
header
-- As described in Section 3.1
body
-- The response of the PKI management entity providing
-- information
genp REQUIRED
-- MUST contain a sequence of one element of type
-- InfoTypeAndValue
infoType REQUIRED
-- MUST be the OID identifying the specific PKI management
-- operation described below
infoValue OPTIONAL
-- MUST be as specified for the specific PKI management operation
protection REQUIRED
-- As described in Section 3.2
extraCerts REQUIRED
-- As described in Section 3.3
This PKI management operation can be used by an EE to request CA certificates from the PKI management entity.
An EE requests CA certificates, e.g., for chain construction, from a PKI management entity by sending a general message with OID id-it-caCerts, as specified in
Section 2.14 of
RFC 9480. The PKI management entity responds with a general response with the same OID that either contains a SEQUENCE of certificates populated with the available intermediate and issuing CA certificates or no content in case no CA certificate is available.
No specific prerequisites apply in addition to those specified in
Section 3.4.
The message sequence for this PKI management operation is as given above, with the following specific content:
-
the infoType OID to use is id-it-caCerts
-
the infoValue of the request MUST be absent
-
if present, the infoValue of the response MUST contain a sequence of certificates
Detailed Description of the infoValue Field of genp:
infoValue OPTIONAL
-- MUST be absent if no CA certificate is available
-- MUST be present if CA certificates are available
-- if present, MUST be a sequence of CMPCertificate
This PKI management operation can be used by an EE to request an updated root CA certificate as described in
Section 4.4 of
RFC 4210.
An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it-rootCaCert. If needed for unique identification, the EE
MUST include the old root CA certificate in the message body as specified in
Section 2.15 of
RFC 9480. The PKI management entity responds with a general response with OID id-it-rootCaKeyUpdate that either contains the update of the root CA certificate consisting of up to three certificates or no content in case no update is available.
Note: This mechanism may also be used to update trusted non-root certificates, e.g., directly trusted intermediate or issuing CA certificates.
The newWithNew certificate is the new root CA certificate and is
REQUIRED to be present if available. The newWithOld certificate is
REQUIRED to be present in the response message because it is needed for the receiving entity trusting the old root CA certificate to gain trust in the new root CA certificate. The oldWithNew certificate is
OPTIONAL because it is only needed in rare scenarios where other entities may not already trust the old root CA.
No specific prerequisites apply in addition to those specified in
Section 3.4.
The message sequence for this PKI management operation is as given above, with the following specific content:
-
the infoType OID to use is id-it-rootCaCert in the request and id-it-rootCaKeyUpdate in the response
-
the infoValue of the request SHOULD contain the root CA certificate the update is requested for
-
if present, the infoValue of the response MUST be a RootCaKeyUpdateContent structure
Detailed Description of the infoValue Field of genm:
infoValue RECOMMENDED
-- MUST contain the root CA certificate to be updated if needed
-- for unique identification
Detailed Description of the infoValue Field of genp:
infoValue OPTIONAL
-- MUST be absent if no update of the root CA certificate is
-- available
-- MUST be present if an update of the root CA certificate
-- is available and MUST be of type RootCaKeyUpdateContent
newWithNew REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the new root CA certificate
newWithOld REQUIRED
-- MUST be present if infoValue is present
-- MUST contain a certificate containing the new public
-- root CA key signed with the old private root CA key
oldWithNew OPTIONAL
-- MAY be present if infoValue is present
-- MUST contain a certificate containing the old public
-- root CA key signed with the new private root CA key
This PKI management operation can be used by an EE to request a template with parameters for future certificate requests.
An EE requests certificate request parameters from the PKI management entity by sending a general message with OID id-it-certReqTemplate as specified in
Section 2.16 of
RFC 9480. The EE
MAY indicate the certificate profile to use in the id-it-certProfile extension of the generalInfo field in the PKIHeader of the general message as described in
Section 3.1. The PKI management entity responds with a general response with the same OID that either contains requirements on the certificate request template or no content in case no specific requirements are imposed by the PKI. The CertReqTemplateValue contains requirements on certificate fields and extensions in a certTemplate. Optionally, it contains a keySpec field containing requirements on algorithms acceptable for key pair generation.
The EE
SHOULD follow the requirements from the received CertTemplate by including in the certificate requests all the fields requested, taking over all the field values provided and filling in any remaining fields values. The EE
SHOULD NOT add further fields, name components, and extensions or their (sub)components. If deviating from the recommendations of the template, the certificate request might be rejected.
Note: We deliberately do not use "
MUST" or "
MUST NOT" here in order to allow more flexibility in case the rules given here are not sufficient for specific scenarios. The EE can populate the certificate request as wanted and ignore any of the requirements contained in the CertReqTemplateValue. On the other hand, a PKI management entity is free to ignore or replace any parts of the content of the certificate request provided by the EE. The CertReqTemplate PKI management operation offers means to ease a joint understanding of which fields and/or which field values should be used. An example is provided in
Appendix A.
In case a field of type Name, e.g., subject, is present in the CertTemplate but has the value NULL-DN (i.e., has an empty list of relative distinguished name (RDN) components), the field
SHOULD be included in the certificate request and filled with content provided by the EE. Similarly, in case an X.509v3 extension is present but its extnValue is empty, this means that the extension
SHOULD be included and filled with content provided by the EE. In case a Name component, for instance, a common name or serial number, is given but has an empty string value, the EE
SHOULD fill in a value. Similarly, in case an extension has subcomponents (e.g., an IP address in a SubjectAltName field) with empty values, the EE
SHOULD fill in a value.
The EE
MUST ignore (i.e., not include) empty fields, extensions, and subcomponents that it does not understand or does not know suitable values to fill in.
The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue
MUST be omitted. In case the PKI management entity wishes to make a stipulation on algorithms the EE may use for key generation, this
MUST be specified using the keySpec field as specified in
Section 2.16 of
RFC 9480.
The keySpec field, if present, specifies the public key types optionally with parameters and/or RSA key lengths for which a certificate may be requested.
The value of a keySpec element with the OID id-regCtrl-algId, as specified in
Section 2.16 of
RFC 9480,
MUST be of type AlgorithmIdentifier and give an algorithm other than RSA. For Elliptic Curve (EC) keys, the curve information
MUST be specified as described in the respective standard documents.
The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as specified in
Section 2.16 of
RFC 9480,
MUST be a positive integer value and give an RSA key length.
In the CertTemplate of the CertReqTemplateValue, the serialNumber, signingAlg, issuerUID, and subjectUID fields
MUST be omitted.
The specific prerequisites augmenting the prerequisites in
Section 3.4 is as follows:
-
When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile.
The message sequence for this PKI management operation is as given above, with the following specific content:
-
the infoType OID to use is id-it-certReqTemplate
-
the id-it-certProfile generalInfo field in the header of the request MAY contain the name of the requested certificate request template
-
the infoValue of the request MUST be absent
-
if present, the infoValue of the response MUST be a CertReqTemplateValue containing a CertTemplate structure and an optional keySpec field
Detailed Description of the infoValue Field of genp:
InfoValue OPTIONAL
-- MUST be absent if no requirements are available
-- MUST be present if the PKI management entity has any
-- requirements on the contents of the certificate template
certTemplate REQUIRED
-- MUST be present if infoValue is present
-- MUST contain the required CertTemplate structure elements
-- The SubjectPublicKeyInfo field MUST be absent
keySpec OPTIONAL
-- MUST be absent if no requirements on the public key are
-- available
-- MUST be present if the PKI management entity has any
-- requirements on the keys generated
-- MUST contain a sequence of one AttributeTypeAndValue per
-- supported algorithm with attribute id-regCtrl-algId or
-- id-regCtrl-rsaKeyLen
This PKI management operation can be used by an EE to request a new CRL. If a CA offers methods to access a CRL, it may include CRL distribution points or authority information access extensions into the issued certificates as specified in [
RFC 5280]. In addition, CMP offers CRL provisioning functionality as part of the PKI management operation.
An EE requests a CRL update from the PKI management entity by sending a general message with OID id-it-crlStatusList. The EE
MUST include the CRL source identifying the requested CRL and, if available, the thisUpdate time of the most current CRL instance it already has, as specified in
Section 2.17 of
RFC 9480. The PKI management entity
MUST respond with a general response with OID id-it-crls.
The EE
MUST identify the requested CRL either by a CRL distribution point name or issuer name.
Note: CRL distribution point names can be obtained from a cRLDistributionPoints extension of a certificate to be validated or from an issuingDistributionPoint extension of the CRL to be updated. CRL issuer names can be obtained from the cRLDistributionPoints extension of a certificate, from the issuer field of the authority key identifier extension of a certificate or CRL, and from the issuer field of a certificate or CRL.
If a thisUpdate value was given, the PKI management entity
MUST return the latest CRL available from the referenced source if this CRL is more recent than the given thisUpdate time. If no thisUpdate value was given, it
MUST return the latest CRL available from the referenced source. In all other cases, the infoValue in the response message
MUST be absent.
The PKI management entity should treat a CRL distribution point name as an internal pointer to identify a CRL that is directly available at the PKI management entity. It is not intended as a way to fetch an arbitrary CRL from an external location, as this location may be unavailable to that PKI management entity.
In addition to the prerequisites specified in
Section 3.4, the EE
MUST know which CRL to request.
Note: If the EE does not want to request a specific CRL, it
MAY instead use a general message with OID id-it-currentCrl as specified in
Section 5.3.19.6 of
RFC 4210.
The message sequence for this PKI management operation is as given above, with the following specific content:
-
the infoType OID to use is id-it-crlStatusList in the request and id-it-crls in the response
-
the infoValue of the request MUST be present and contain a sequence of one CRLStatus structure
-
if present, the infoValue of the response MUST contain a sequence of one CRL
Detailed Description of the infoValue Field of genm:
infoValue REQUIRED
-- MUST contain a sequence of one CRLStatus element
source REQUIRED
-- MUST contain the dpn choice of type DistributionPointName if
-- the CRL distribution point name is available
-- Otherwise, MUST contain the issuer choice identifying the CA
-- that issues the CRL. It MUST contain the issuer DN in the
-- directoryName field of a GeneralName element.
thisUpdate OPTIONAL
-- MUST contain the thisUpdate field of the latest CRL the EE
-- has gotten from the issuer specified in the given dpn or
-- issuer field
-- MUST be omitted if the EE does not have any instance of the
-- requested CRL
Detailed Description of the infoValue Field of genp:
infoValue OPTIONAL
-- MUST be absent if no CRL to be returned is available
-- MUST contain a sequence of one CRL update from the referenced
-- source if a thisUpdate value was not given or a more recent
-- CRL is available
This is a variant of all PKI management operations described in this document. It is initiated in case a PKI management entity cannot respond to a request message in a timely manner, typically due to offline or asynchronous upstream communication or due to delays in handling the request. The polling mechanism has been specified in
Section 5.3.22 of
RFC 4210 and updated by [
RFC 9480].
Depending on the PKI architecture, the entity initiating delayed delivery is not necessarily the PKI management entity directly addressed by the EE.
When initiating delayed delivery of a message received from an EE, the PKI management entity
MUST respond with a message including the status "waiting". In response to an ir/cr/kur/p10cr message, it must place the status "waiting" in an ip/cp/kup message and for responses to other request message types in an error message. On receiving this response, the EE
MUST store in its transaction context the senderNonce of the preceding request message because this value will be needed for checking the recipNonce of the final response to be received after polling. It sends a poll request with certReqId 0 if referring to the CertResponse element contained in the ip/cp/kup message, else -1 to refer to the whole message. In case the final response is not yet available, the PKI management entity that initiated the delayed delivery
MUST answer with a poll response with the same certReqId. The included checkAfter time value indicates the minimum number of seconds that should elapse before the EE sends a new pollReq message to the PKI management entity. Polling earlier than indicated by the checkAfter value may increase the number of message round trips. This is repeated until a final response is available or any party involved gives up on the current PKI management operation, i.e., a timeout occurs.
When the PKI management entity that initiated delayed delivery can provide the final response for the original request message of the EE, it
MUST send this response to the EE. Using this response, the EE can continue the current PKI management operation as usual.
No specific prerequisites apply in addition to those of the respective PKI management operation.
Message Flow:
Step# EE PKI management entity
1 format request
message
2 -> request ->
3 handle or forward
request
4 format ip/cp/kup/error
with status "waiting"
response in case no
immediate final response
is available
5 <- ip/cp/kup/error <-
6 handle
ip/cp/kup/error
with status
"waiting"
-------------------------- start polling --------------------------
7 format pollReq
8 -> pollReq ->
9 handle or forward pollReq
10 in case the final response
for the original request
is available, continue
with step 14
otherwise, format or
receive pollRep with
checkAfter value
11 <- pollRep <-
12 handle pollRep
13 let checkAfter
time elapse and
continue with
step 7
----------------- end polling, continue as usual ------------------
14 format or receive
final response on
the original request
15 <- response <-
16 handle final
response
Detailed Message Description:
Response with Status "waiting" -- ip/cp/kup/error
Field Value
header
-- As described in Section 3.1
body
-- As described for the respective PKI management operation, with
-- the following adaptations:
status REQUIRED -- in case of ip/cp/kup
pKIStatusInfo REQUIRED -- in case of error response
-- PKIStatusInfo structure MUST be present
status REQUIRED
-- MUST be status "waiting"
statusString OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
failInfo PROHIBITED
protection REQUIRED
-- As described in Section 3.2
extraCerts OPTIONAL
-- As described in Section 3.3
Polling Request -- pollReq
Field Value
header
-- As described in Section 3.1
body
-- The message of the EE asking for the final response or for a
-- time to check again
pollReq REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first request message
-- of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the PKI
-- management entity caches the CMP protection certificate from
-- the first request message of the PKI management operation
Polling Response -- pollRep
Field Value
header
-- As described in Section 3.1
body
-- The message indicates the delay after which the EE SHOULD
-- send another pollReq message for this transaction
pollRep REQUIRED
certReqId REQUIRED
-- MUST be 0 if referring to a CertResponse element, else -1
checkAfter REQUIRED
-- MUST be the time in seconds to elapse before a new pollReq
-- should be sent
reason OPTIONAL
-- MAY be any human-readable text for debugging, for logging, or
-- to display in a GUI
protection REQUIRED
-- As described in Section 3.2
-- MUST use the same credentials as in the first response
-- message of the PKI management operation
extraCerts RECOMMENDED
-- As described in Section 3.3
-- MAY be omitted if the message size is critical and the EE has
-- cached the CMP protection certificate from the first
-- response message of the PKI management operation
Final Response - Any Type of Response Message
Field Value
header
-- MUST be the header, as described for the response message
-- of the respective PKI management operation
body
-- The response of the PKI management entity to the initial
-- request, as described in the respective PKI management
-- operation
protection REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation
extraCerts REQUIRED
-- MUST be as described for the response message of the
-- respective PKI management operation