Lightweight Certificate Management Protocol (CMP) Profile

2.2.1. Mandatory PKI management operations

The set of mandatory PKI management operations in this document is intentionally lean to help for keeping development effort low and to enable use in memory-constrained devices.¶

2.2.2. Recommended PKI management operations

Additional recommended PKI management operations support some more complex scenarios, that are considered beneficial for environments with more specific demand or boundary conditions.¶

2.2.3. Optional PKI management operations

The optional PKI management operations support specific scenarios seen only in some environments with special requirements.¶

3.6.1. Reporting error conditions upstream

An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in upstream direction, either.¶

In case an EE rejects a newly issued certificate contained in an ip, cp, or kup message and implicit confirmation has not been granted, the EE MUST report this using a certConf message with "rejection" status and await the pkiConf response as described in Section 4.1.1.¶

On all other error conditions regarding response messages, the EE or PKI management entity MUST regard the current PKI management operation as terminated with failure. The error conditions include¶

• invalid response message header, body type, protection, or extraCerts according to the checks described in Section 3.5,¶
• any issue detected with response message contents,¶
• receipt of an error message from upstream,¶
• timeout occurred while waiting for a response,¶
• rejection of a newly issued certificate while implicit confirmation has been granted.¶

Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. Then they also MUST regard the current PKI management operation as terminated with failure and MUST not attempt to send an error message downstream.¶

3.6.2. Reporting error conditions downstream

In case the PKI management entity detects an error condition, e.g., rejecting the request due to policy decision, in the body of an ir, cr, p10cr, kur, or rr message received from downstream, it SHOULD report the error in the specific response message, i.e., an ip, cp, kup, or rp with "rejection" status, as described in Section 4.1.1 and Section 4.2. This can also happen in case of polling.¶

In case the PKI management entity detects any other error condition on requests, including pollReq, certConf, genm, and nested messages, received from downstream and on responses received from upstream, such as invalid message header, body type, protection, or extraCerts according to the checks described in Section 3.5 it MUST report them downstream in the form of an error message as described in Section 3.6.4.¶

3.6.3. Handling error conditions on nested messages used for batching

Batching of messages using nested messages as described in Section 5.2.2.2 requires special error handling.¶

If the error condition is on an upstream nested message containing batched requests, it MUST not attempt to respond to the individual requests included in it.¶

In case a PKI management entity receives an error message in response to a nested message, it must propagate the error by responding with an error message to each of the request messages contained in the nested message.¶

In case a PKI management entity detects an error condition on the downstream nested message received in response to a nested message sent before, it MAY ignore this error condition and handle the response as described in Section 5.2.2.2. Otherwise, it MUST propagate the error by responding with an error message to each of the requests contained in the nested message it sent originally.¶

3.6.4. Reporting error conditions

When sending any kind of negative response, including error messages, a PKI entity MUST indicate the error condition in the PKIStatusInfo structure of the respective message as described below. It then MUST regard the current PKI management operation as terminated with failure.¶

The PKIStatusInfo structure is used to report errors. It may be part of various message types, in particular: certConf, ip, cp, kup, and error. The PKIStatusInfo structure consists of the following fields:¶

• status: Here the PKIStatus value "rejection" MUST be used.¶
• statusString: Here any human-readable valid value for logging or to display via a user interface SHOULD be added.¶

• failInfo: Here the PKIFailureInfo bits MAY be used in the way explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo bits regarding the validation described in Section 3.5 are referenced there. The PKIFailureInfo bits referenced in Section 5.1 and Section 6 are described here:¶

  • badCertId: A kur, certConf, or rr message references an unknown certificate¶
  • badPOP: An ir/cr/p10cr/kur contains an invalid proof-of-possession¶
  • certRevoked: Revocation requested for a certificate already revoked¶
  • badCertTemplate: The contents of a certificate request are not accepted, e.g., a field is missing or has a non-acceptable value or the given public key is already in use in some other certificate (depending on policy).¶
  • transactionIdInUse: This is sent by a PKI management entity in case the received request contains a transaction ID that has already been used for another transaction. An EE receiving such error message SHOULD resend the request in a new transaction using a different transaction ID.¶
  • notAuthorized: The sender of a request message is not authorized for requesting the operation.¶
  • systemUnavail: This is sent by a PKI management entity in case a back-end system is not available.¶
  • systemFailure: This is sent by a PKI management entity in case a back-end system is currently not functioning correctly.¶

An EE receiving a systemUnavail or systemFailure failInfo SHOULD resend the request in a new transaction after some time.¶

Detailed error message description:¶

Error Message -- error

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message sent by an PKI management entity error that
    -- occurred
  error                       REQUIRED
    pKIStatusInfo             REQUIRED
      status                  REQUIRED
    -- MUST have the value "rejection"
      statusString            RECOMMENDED
    -- SHOULD be any human-readable text for debugging, logging
    -- or to display in a GUI
      failInfo                OPTIONAL
    -- MAY be present and contain the relevant PKIFailureInfo bits

protection                    REQUIRED
    -- As described in Section 3.2

extraCerts                    OPTIONAL
    -- As described in Section 3.3

4.1.1. Requesting a certificate from a new PKI with signature-based protection

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.¶

Specific prerequisites augmenting the prerequisites in Section 3.4:¶

• 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 exactly one CertReqMsg in the ir. If more certificates are required, further requests MUST be sent using separate PKI management operation. If the EE wants to omit sending a certificate confirmation message after receiving the ip, e.g., to reduce the number of protocol messages exchanged in this PKI management operation, it MUST request this by including the implicitConfirm extension in the header of the ir message, see Section 3.1.¶

If the EE did not request implicit confirmation or the request 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 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 the PKI management entity SHALL terminate the PKI management operation, and the PKI MAY revoke the newly issued certificate.¶

If the EE did not request implicit confirmation or the request was not granted by the PKI management entity, certificate confirmation MUST be performed as follows. If the EE successfully received the certificate and accepts it, the EE MUST send a certConf message, which the PKI management entity must respond using 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 this case the PKI management entity SHALL terminate the PKI management operation. The PKI MAY revoke the newly issued certificates depending on the local policy.¶

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 no certifiedKeyPair field. 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 exactly one CertReqMsg
    -- If more certificates are required, further PKI management
    -- operations MUST be initiated
    certReq                   REQUIRED
      certReqId               REQUIRED
    -- MUST be 0
      certTemplate            REQUIRED
        version               OPTIONAL
    -- MUST be 2 if supplied
        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 a NULL-DN
        publicKey             REQUIRED
          algorithm           REQUIRED
    -- MUST include the subject public key algorithm identifier
          subjectPublicKey    REQUIRED
    -- MUST contain the public key to be certified in case of local
    -- key generation
        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               RECOMMENDED
    -- MUST be used by an EE if the key can be used for signing and
    -- has 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
    -- certTemplate
      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 exactly 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"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, 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
    -- Self-signed certificates SHOULD be omitted
    -- Duplicate certificates MAY be omitted


Certificate Confirmation -- certConf

Field                         Value

header
    -- As described in Section 3.1

body
    -- The message of the EE sends confirmation to the PKI
    -- management entity to accept or reject the issued certificates
  certConf                    REQUIRED
    -- MUST contain exactly one CertStatus
    CertStatus                REQUIRED
      hashAlg                 OPTIONAL
    -- The hash algorithm to use for calculating certHash
    -- SHOULD NOT be used in all cases where the AlgorithmIdentifier
    -- of the certificate signature specifies a hash algorithm
    -- If used, the pvno field in the header MUST be cmp2021 (3)
      certHash                REQUIRED
    -- MUST be the hash of the certificate, using the hash algorithm
    -- indicated in hashAlg or the same one as used to create the
    -- certificate signature
      certReqId               REQUIRED
    -- MUST be 0
      statusInfo              RECOMMENDED
    -- 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, logging, or to
    -- display in a GUI
        failInfo              OPTIONAL
    -- MAY be present if status is "rejection"
    -- MUST be absent if status is "accepted"

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 extraCerts 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 extraCerts from the first response message of
    -- this PKI management operation

4.1.2. Requesting an additional certificate with signature-based protection

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:¶

• 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:¶

1

The body of the first request and response SHOULD be cr and cp, respectively.¶

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.¶

2

The caPubs field in the certificate response message SHOULD be absent.¶

4.1.3. Updating an existing certificate with signature protection

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 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:¶

• 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:¶

1

The body of the first request and response MUST be kur and kup, respectively.¶

2

Protection of the kur MUST be performed using the certificate to be updated.¶

3

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.¶

4

The certTemplate SHOULD contain the subject and/or subjectAltName extension and publicKey of the EE only.¶

5

The oldCertId control MAY be used to make clear which certificate is to be updated.¶

6

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

4.1.4. Requesting a certificate from a PKI with MAC-based protection

This PKI management operation 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 PKI management entity checking the MAC-based protection SHOULD replace this protection according to Section 5.2.3 in case the next hop does 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 Section 8.¶

Specific prerequisites augmenting the prerequisites in Section 3.4:¶

• 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 Section 4.1.1, with the following changes:¶

1

The protection of all messages MUST be MAC-based.¶

2

The senderKID MUST contain a reference the recipient can use to identify the shared secret information used for the protection, e.g., the username of the EE.¶

3

The extraCerts of all messages does not contain CMP protection certs and associated chains.¶

See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] 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 fields SHOULD remain constant for message protection throughout this PKI management operation to reduce the computational overhead.¶

4.1.5. Requesting a certificate from a legacy PKI using a PKCS#10 request

This PKI management operation can be used by an EE to request a certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF [RFC4211]. This offers a variation of the PKI management operations specified in Section 4.1.1 to Section 4.1.4.¶

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.1, Section 4.1.2, Section 4.1.3, or Section 4.1.4.¶

The message sequence for this PKI management operation is identical to that given in Section 4.1.1 to Section 4.1.4, with the following changes:¶

1

The body of the first request and response MUST be p10cr and cp, respectively.¶

2

The certReqId in the cp message MUST be 0.¶

3

The caPubs field in the cp message SHOULD be absent.¶

Detailed description of the p10cr message:¶

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 a 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 for the underlying PKI management operation

extraCerts                    REQUIRED
    -- As described for the underlying PKI management operation

4.1.6. Adding central key pair generation to a certificate request

This functional extension can combined with certificate enrollment as described in Section 4.1.1 to Section 4.1.4. 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. It is a matter of the local implementation which PKI management entity will act as Key Generation Authority (KGA) and perform the key generation. 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.¶

As described in Section 5.3.1, the KGA can use one of the PKI management operations described in the sections above to request the certificate for this key pair on behalf of the EE.¶

Generally speaking, in machine-to-machine scenarios it is strongly preferable to generate public-private key pairs locally at the EE. Together with proof-of-possession of the private key in the certificate request, 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 needed not only 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 RNG seed to guarantee good pseudo-random 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.1, 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 it 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 CMP Updates [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile requires using EnvelopedData as specified in CMS Section 6 [RFC5652]. 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 7 of CMP Updates [I-D.ietf-lamps-cmp-updates].¶

+----------------------------------+
| EnvelopedData                    |
| [RFC5652] section 6              |
| +------------------------------+ |
| | SignedData                   | |
| | [RFC5652] section 5          | |
| | +--------------------------+ | |
| | | AsymmetricKeyPackage     | | |
| | | [RFC5958]                | | |
| | | +----------------------+ | | |
| | | | privateKey           | | | |
| | | | OCTET STRING         | | | |
| | | +----------------------+ | | |
| | +--------------------------+ | |
| +------------------------------+ |
+----------------------------------+

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 [RFC5958].¶

This AsymmetricKeyPackage structure MUST be wrapped in a SignedData structure, as specified in CMS Section 5 [RFC5652], 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 CMP Updates [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate key pairs on behalf of an EE. The EE SHOULD verify the presence of this extended key usage in the SignedData structure.¶

Note: When using password-based key management technique as described in Section 4.1.6.3 it may not be possible or meaningful to the EE to validate the KGA signature in the SignedData structure since shared secret information is used for initial authentication. In this case the EE MAY omit this signature validation.¶

The SignedData structure MUST be wrapped in an EnvelopedData structure, as specified in CMS Section 6 [RFC5652], 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 CMP Updates section 2.8 [I-D.ietf-lamps-cmp-updates] for more details on which key management technique to use.¶

• Signature-based protection of the request message:¶

  • The content-encryption key SHALL be protected using the key agreement key management technique, see Section 4.1.6.1, if the certificate used by the EE for protecting the request message allows the key usage keyAgreement. If the certificate also allows the key usage keyEncipherment, the key transport key management technique SHALL NOT be used.¶
  • The content-encryption key SHALL be protected using the key transport key management technique, see Section 4.1.6.2, if the certificate used by the EE for protecting the respective request message allows the key usage keyEncipherment but not keyAgreement.¶

• MAC-based protected 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.¶

If central key generation is supported, support of the key agreement key management technique is REQUIRED and support of key transport and password-based key management techniques are OPTION, for two reasons: The key agreement key management technique is supported by most asymmetric algorithms, while the key transport key management technique is supported only by a very few of them. The password-based key management technique shall only be used in combination with MAC-based protection, which is a sideline in this document.¶

Specific prerequisites augmenting those of the respective certificate enrollment PKI management operations:¶

• 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.¶

The detailed description of the privateKey field as follows:¶

        privateKey            OPTIONAL
    -- MUST be an EnvelopedData structure as specified in CMS
    -- Section 6 [RFC5652]
          version             REQUIRED
    -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and
    -- KeyTransRecipientInfo
    -- MUST be 0 for recipientInfo type PasswordRecipientInfo
          recipientInfos      REQUIRED
    -- MUST contain exactly one RecipientInfo, which MUST be
    -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1),
    -- ktri of type KeyTransRecipientInfo (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 a PROT_SYM_ALG as specified in
    -- RFC-CMP-Alg Section 5
            encryptedContent  REQUIRED
    -- MUST be the SignedData structure as specified in CMS
    -- Section 5 [RFC5652] in encrypted form
              version         REQUIRED
    -- MUST be 3
              digestAlgorithms
                              REQUIRED
    -- MUST contain exactly 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
              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 exactly 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 exactly 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 digestAlgorithmIdentifier
                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 signature
    -- For details on the signed attributes see CMS Section 5.3 and
    -- Section 11 [RFC5652]
                signatureAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the signature algorithm
    -- used for calculation of the signature bits
    -- The signature algorithm type MUST be a MSG_SIG_ALG as
    -- specified in RFC-CMP-Alg Section 3 and MUST be consistent
    -- with the subjectPublicKeyInfo field of the KGA certificate
                signature     REQUIRED
    -- MUST be the digital signature of the encapContentInfo

NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that are defined in RFC 5652 [RFC5652] but are not explicitly specified here SHOULD NOT be used.¶

            kari              REQUIRED
    -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section
    -- 6.2.2 [RFC5652]
              version         REQUIRED
    -- MUST be 3
              originator      REQUIRED
    -- MUST contain the originatorKey choice
                algorithm     REQUIRED
    -- MUST be the algorithm identifier of the key agreement
    -- algorithm
    -- The algorithm type MUST be a KM_KA_ALG as specified in
    -- RFC-CMP-Alg Section 4.1
                publicKey     REQUIRED
    -- MUST be the ephemeral public key of the sending party
              ukm             RECOMMENDED
    -- MUST be used when 1-pass ECMQV is used
    -- SHOULD be present to ensure uniqueness of the key
    -- encryption key, see [RFC8419]
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key wrap algorithm
    -- The algorithm type MUST be a KM_KW_ALG as specified in
    -- RFC-CMP-Alg Section 4.3
              recipientEncryptedKeys
                              REQUIRED
    -- MUST contain exactly one RecipientEncryptedKey element
                rid           REQUIRED
    -- MUST contain the rKeyId choice
                  rKeyId      REQUIRED
                    subjectKeyIdentifier
                              REQUIRED
    -- MUST contain the same value as the senderKID in the
    -- respective request message header
                  encryptedKey
                              REQUIRED
    -- MUST be the encrypted content-encryption key

            ktri              REQUIRED
    -- MUST be a KeyTransRecipientInfo as specified in CMS
    -- Section 6.2.1 [RFC5652]
              version         REQUIRED
    -- MUST be 2
              rid             REQUIRED
    -- MUST contain the subjectKeyIdentifier choice
                subjectKeyIdentifier
                              REQUIRED
    -- MUST contain the same value as the senderKID in the
    -- respective request message header
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key transport
    -- algorithm
    -- The algorithm type MUST be a KM_KT_ALG as specified in
    -- RFC-CMP-Alg Section 4.2
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

            pwri              REQUIRED
    -- MUST be a PasswordRecipientInfo as specified in CMS
    -- Section 6.2.4 [RFC5652]
              version         REQUIRED
    -- MUST be 0
              keyDerivationAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key derivation
    -- algorithm
    -- The algorithm type MUST be a KM_KD_ALG as specified in
    -- RFC-CMP-Alg Section 4.4
              keyEncryptionAlgorithm
                              REQUIRED
    -- MUST be the algorithm identifier of the key wrap algorithm
    -- The algorithm type MUST be a KM_KW_ALG as specified in
    -- RFC-CMP-Alg Section 4.3
              encryptedKey    REQUIRED
    -- MUST be the encrypted content-encryption key

4.1.7. Handling delayed enrollment

This functional extension can be applied in combination with certificate enrollment as described in Section 4.1.1 to Section 4.1.5, optionally including central key generation. The functional extension can be used in case a PKI management entity cannot respond to the certificate request in a timely manner, e.g., due to offline upstream communication or required human interaction. Depending on the PKI architecture, the entity initiating delayed enrollment (see also Section 5.1.2) is not necessarily the PKI management entity addressed by the EE.¶

Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] delayed enrollment is also possible for PKI management operations starting with a p10cr request message.¶

The PKI management entity initiating the delayed enrollment MUST respond with an ip/cp/kup message including the status "waiting". When receiving a response with status "waiting" the EE MUST send a poll request. The PKI management entity that initiated the delayed enrollment MUST answer with a poll response containing a checkAfter time. This value indicates the minimum number of seconds that SHOULD elapse before the EE sends another poll request. This is repeated as long as no final response is available or any party involved gives up on the current PKI management operation. When the PKI management entity that initiated delayed enrollment can provide the final ip/cp/kup message for the initial request of the EE, it MUST provide this message in response to a poll request. After receiving this response, the EE can continue the original PKI management operation as described in the respective section of this document, i.e., sending a certConf message if required.¶

No specific prerequisites apply in addition to those of the respective certificate enrollment.¶

Message flow:¶

Step# EE                                   PKI management entity
 1   format ir/cr/p10cr/kur
 2                    ->ir/cr/p10cr/kur->
 3                                        handle or forward request
 4                                        in case no immediate final
                                            response is possible,
                                            format or receive ip/cp/
                                            kup with status "waiting"
 5                      <-  ip/cp/kup  <-
 6   handle ip/cp/kup with status "waiting"

--------------------------  start polling  -------------------------

 7   format pollReq
 8                      ->   pollReq   ->
 9                                        handle or forward pollReq
10                                        in case the requested
                                            certificate or a
                                            corresponding response
                                            message 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
                                            ip/cp/kup
15                                        possibly grant implicit
                                            confirm
16                      <-  ip/cp/kup  <-
17   handle ip/cp/kup

-----------------  if implicitConfirm not granted  -----------------

18   format certConf
19                      ->   certConf ->
20                                        handle or forward certConf
21                                        format or receive pkiConf
22                      <-   pkiConf  <-
23   handle pkiConf

Detailed description of the first ip/cp/kup:¶

Response with status "waiting"  -- ip/cp/kup

Field                         Value

header
    -- MUST be as described for the first response message of the
    -- respective PKI management operation

body
    -- The response of the PKI management entity to the request in
    -- case no immediate final response can be sent
  ip/cp/kup                   REQUIRED
    response                  REQUIRED
    -- MUST contain exactly one CertResponse
      certReqId               REQUIRED
    -- MUST be 0
      status                  REQUIRED
    -- PKIStatusInfo structure MUST be present
        status                REQUIRED
    -- MUST be "waiting"
        statusString          OPTIONAL
    -- MAY be any human-readable text for debugging, logging or to
    -- display in a GUI
        failInfo              PROHIBITED
      certifiedKeyPair        PROHIBITED

protection                    REQUIRED
    -- MUST be as described for the first response message of the
    -- respective PKI management operation, except that the PKI
    -- management entity that initiated the delayed enrollment and
    -- created this response MUST apply its own protection

extraCerts                    REQUIRED
    -- MUST be as described for the first response message of the
    -- respective PKI management operation. Yet since no newly
    -- enrolled certificate is available yet, no respective
    -- certificate chain is included


Polling Request -- pollReq

Field                         Value

header
    -- MUST contain a header as described for the certConf message
    -- of the respective PKI management operation

body
    -- The message of the EE asks for the final response or for a
    -- time to check again
  pollReq                     REQUIRED
    -- MUST contain exactly one PollReqContent element
    certReqId                 REQUIRED
    -- MUST be 0

protection                    REQUIRED
    -- MUST be as described for the certConf message of the
    -- respective PKI management operation

extraCerts                    OPTIONAL
    -- MUST be as described for the certConf message of the
    -- respective PKI management operation


Polling Response -- pollRep

Field                         Value

header
    -- MUST contain a header as described for the pkiConf message
    -- of the respective PKI management operation

body
    -- The message indicates the delay after which the EE SHOULD
    -- send another pollReq message for this transaction
  pollRep                     REQUIRED
    -- MUST contain exactly one PollRepContent entry
    certReqId                 REQUIRED
    -- MUST be 0
    checkAfter                REQUIRED
    -- time in seconds to elapse before a new pollReq SHOULD be sent
    reason                    OPTIONAL
    -- MAY be any human-readable text for debugging, logging or to
    -- display in a GUI

protection                    REQUIRED
    -- MUST be as described for the pkiConf message of the
    -- respectiveprofile, except that the PKI management entity that
    -- initiated the delayed enrollment and created this response
    -- MUST apply its own protection

extraCerts                    OPTIONAL
    -- If present, it MUST be as described for the pkiConf message
    -- of the respective PKI management operation.


Final response -- ip/cp/kup

Field                         Value

header
    -- MUST be as described for the first response except that the
    -- PKI management entity that initiated the delayed enrollment
    -- MUST use as recipNonce the senderNonce of the last pollReq
    -- message

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 first response message of this
    -- PKI management operation, except that the PKI management
    -- entity that initiated the delayed enrollment MUST re-protect
    -- the response message

extraCerts                    REQUIRED
    -- MUST be as described for the first response message of the
    -- respective PKI management operation

4.3.1. Get CA certificates

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 an PKI management entity by sending a general message with OID id-it-caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 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 with 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:¶

1

the infoType OID to use is id-it-caCerts¶

2

the infoValue of the request MUST be absent¶

3

if present, the infoValue of the response MUST contain a sequence of certificates¶

The infoValue field of the general response containing the id-it-caCerts OID looks like this:¶

      infoValue               OPTIONAL
    -- MUST be absent if no CA certificate is available
    -- MUST be present if CA certificates are available
    -- MUST be a sequence of CMPCertificate

4.3.2. Get root CA certificate update

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 [RFC4210].¶

An EE requests a root CA certificate update from the PKI management entity by sending a general message with OID id-it-rootCaKeyUpdate, optionally including the certificate to be updated in the rootCaCert generalInfo field, as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds with a general response with the same OID that either contains the update of the root CA certificate consisting of up to three certificates, or with no content in case no update is available.¶

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 entities do 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:¶

1

the infoType OID to use is id-it-rootCaKeyUpdate¶

2

the rootCaCert general info field in the header of the request MAY contain the root CA certificate the update is requested for¶

3

the infoValue of the request MUST be absent¶

4

if present, the infoValue of the response MUST be a RootCaKeyUpdateContent structure¶

The infoValue field of the general response containing the id-it-rootCaKeyUpdate extension looks like this:¶

      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 RootCaKeyUpdate
        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

4.3.3. Get certificate request template

This PKI management operation can be used by an EE to request a template with parameters for a 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 CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY indicate the certificate profile to use in the 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 with 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.¶

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 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 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 sub-components (e.g., an IP address in a SubjectAltName field) with empty value, the EE SHOULD fill in a value.¶

The EE MUST ignore (i.e., not include and fill in) empty fields, extensions, and sub-components that it does not understand or does not know suitable values to be filled 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 stipulation on algorithms the EE may use for key generation, this MUST be specified using the keySpec field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates].¶

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 CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of type AlgorithmIdentifier and give an algorithm other than RSA. For 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 CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of type Integer and give an RSA key length.¶

In the CertTemplate of the CertReqTemplateValue the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST be omitted.¶

Specific prerequisites augmenting the prerequisites in Section 3.4:¶

• 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:¶

1

the infoType OID to use is id-it-certReqTemplate¶

2

the certProfile generalInfo field in the header of the request MAY contain the name of the requested certificate request template¶

3

the infoValue of the request MUST be absent¶

4

if present, the infoValue of the response MUST be a CertReqTemplateValue containing a CertTemplate structure and an optional keySpec field¶

The infoValue field of the general response containing the id-it-certReqTemplate OID looks like this:¶

      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 one AttributeTypeAndValue per supported
    -- algorithm with attribute id-regCtrl-algId or
    -- id-regCtrl-rsaKeyLen

5.1.1. Responding to a certificate request

An ir/cr/p10cr/kur message is used to request a certificate as described in Section 4.1. The responding PKI management entity MUST proceed as follows unless it initiates delayed enrollment as described in Section 5.1.2.¶

The PKI management entity SHOULD check the message body according to the applicable requirements from Section 4.1. Possible failInfo bit values used for error reporting in case a check failed include badCertId and badCertTemplate. It MUST verify the presence and value of the proof-of-possession (failInfo bit: badPOP), unless central key generation is requested. In case the special POP value "raVerified" is given, it SHOULD check that the request message was signed using a certificate containing the cmcRA extended key usage (failInfo bit: notAuthorized). The PKI management entity SHOULD perform also any further checks on the certTemplate contents (failInfo: badCertTemplate) according to any applicable PKI policy and certificate profile.¶

If the requested certificate is available, the PKI management entity MUST respond with a positive ip/cp/kup message as described in Section 4.1.¶

Note: If central key generation is performed by the responding PKI management entity, the responding PKI management entity MUST include in the response the privateKey field as specified in Section 4.1.6. It may have issued the certificate for the newly generated key pair itself if it is a CA, or have requested the certificate on behalf of the EE as described in Section 5.3.1, or have received it by other means from a CA.¶

The prerequisites of the respective PKI management operation as specified in Section 4.1 apply.¶

Note: If the EE requested omission of the certConf message, the PKI management entity SHOULD handle it as described in Section 4.1.1 and therfore MAY grant this by including the implicitConfirm extension in the response header.¶

5.1.2. Initiating delayed enrollment

This functional extension can be used by a PKI management entity to initiate delayed enrollment. In this case a PKI management entity MUST use the status "waiting" in the response message as described in Section 4.1.7 and then MUST reply to pollReq messages as described there.¶

Typically, as stated in Section 5.2.3, an intermediate PKI management entity SHOULD NOT change the sender and recipient nonces even in case it modifies a request or a response message. In the special case of delayed enrollment initiated by an intermediate PKI management entity, for example by an LRA with offline transport to an upstream RA, there is an exception. Between the EE and this PKI management entity, pollReq and pollRep messages are exchanged handling the nonces as usual. Yet when, after some pollRep, the final response from upstream arrives at the PKI management entity, this response contains the recipNonce copied (as usual) from the senderNonce in the original request message. The PKI management entity that initiated the delayed enrollment MUST replace the recipNonce in the response message with the senderNonce of the last received pollReq because the downstream entities, including the EE, will expect it in this way.¶

The prerequisites of the respective PKI management operation as specified in Section 4.1.7 apply.¶

5.1.3. Responding to a confirmation message

A PKI management entity MUST handle a certConf message if it has responded before with a positive ip/cp/kup message not granting implicit confirmation. It SHOULD check the message body according to the requirements given in Section 4.1.1 (failInfo bit: badCertId) and react as described there.¶

The prerequisites of the respective PKI management operation as specified in Section 4.1 apply.¶

5.1.4. Responding to a revocation request

An rr message is used to request revocation of a certificate. The responding PKI management entity SHOULD check the message body according to the requirements in Section 4.2. It MUST make sure that the referenced certificate exists (failInfo bit: badCertId), has been issued by the addressed CA, and is not already expired or revoked (failInfo bit: certRevoked). On success it MUST respond with a positive rp message as described in Section 4.2.¶

No specific prerequisites apply in addition to those specified in Section 3.4.¶

5.1.5. Responding to a support message

A genm message is used to retrieve extra content. The responding PKI management entity SHOULD check the message body according to the applicable requirements in Section 4.3 and perform any further checks depending on the PKI policy. On success it MUST respond with a genp message as described there.¶

No specific prerequisites apply in addition to those specified in Section 3.4.¶

5.2.1. Not changing protection

This variant means that a PKI management entity forwards a CMP message without changing the header, body, or protection. In this case the PKI management entity acts more like a proxy, e.g., on a network boundary, implementing no specific RA-like security functionality that requires an authentic indication to the PKI. Still the PKI management entity might implement checks that result in refusing to forward the request message and instead responding as specified in Section 3.6.¶

This variant of forwarding a message or the one described in Section 5.2.2.1 SHOULD be used for kur messages and for central key generation.¶

No specific prerequisites apply in addition to those specified in Section 3.4.¶

5.2.2. Adding protection and batching of messages

This variant of forwarding a message means that a PKI management entity adds another protection to PKI management messages before forwarding them.¶

The nested message is a PKI management message containing a PKIMessages sequence as its body containing one or more CMP messages.¶

As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases for adding another protection by a PKI management entity. Specific procedures are described in more detail in the following sections.¶

Detailed message description:¶

Nested Message - nested

Field                         Value

header
    -- As described in Section 3.1

body
    -- Container to provide additional protection to original
    -- messages and to bundle request messages or alternatively
    -- response messages
  PKIMessages                 REQUIRED
    -- MUST be a sequence of one or more CMP messages

protection                    REQUIRED
    -- As described in Section 3.2 using the CMP protection key of
    -- the PKI management entity

extraCerts                    REQUIRED
    -- As described in Section 3.3

Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive response
 5                      <-  response <-
 6   forward response

Step# PKI management entity               PKI management entity
 1   format nested
 2                      ->  nested   ->
 3                                        handle or forward nested
 4                                        format or receive nested
 5                      <-  nested   <-
 6   handle nested

5.2.3. Replacing protection

The following two alternatives can be used by any PKI management entity forwarding a CMP message with or without changes while providing its own protection and in this way asserting approval of the message.¶

By replacing the existing protection using its own CMP protecting key the PKI management entity provides a proof of verifying and approving the message as described above. Thus, the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI.¶

Before replacing the existing protection by a new protection, the PKI management entity MUST verify the protection provided and approve its content, including any modifications that it may perform. It MUST also check that the sender, as authenticated by the message protection, is authorized for the given operation.¶

These message adaptations MUST NOT be applied to kur messages described in Section 4.1.3 since their original protection using the key and certificate to be updated needs to be preserved, unless the regCtrl OldCertId is used to strongly identify the certificate to be updated.¶

These message adaptations MUST NOT be applied to certificate request messages described in for central key generation Section 4.1.6 since their original protection needs to be preserved up to the Key Generation Authority, which needs to use it for encrypting the new private key for the EE.¶

In both the kur and central key generation cases, if a PKI management entity needs to state its approval of the original request message it MUST provide this using a nested message as specified in Section 5.2.2.1.¶

When an intermediate PKI management entity modifies a message, it SHOULD NOT change the transactionID nor the sender and recipient nonces except as stated for delayed enrollment in Section 4.1.7 and Section 5.1.2.¶

    popo
      raVerified              REQUIRED
    -- MUST have the value NULL and indicates that the PKI
    -- management entity verified the popo of the original message

5.3.1. Requesting certificates

A PKI management entity may use on of the PKI management operations described in Section 4.1 to request a certificate on behalf of another PKI entity. It either generates the key pair itself and inserts the new public key in the subjectPublicKey field of the request certTemplate, or it uses a certificate request received from downstream, e.g., by means of a different protocol. In the latter case it SHOULD verify the received proof-of-possession.¶

No specific prerequisites apply in addition to those specified in Section 4.1.¶

Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the one described in Section 5.2.3.¶

The message sequence for this PKI management operation is identical to the respective PKI management operation given in Section 4.1, with the following changes:¶

1

The request messages MUST be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation.¶

2

If inclusion of a proper proof-of-possession is not possible the PKI management entity MUST verify the POP provided from downstream and use "raVerified" in its upstream request.¶

5.3.2. Revoking a certificate

A PKI management entity may use the PKI management operation described in Section 4.2 to revoke a certificate of another PKI entity. This revocation request message MUST be signed by the PKI management entity using its own CMP protection key to prove to the PKI authorization to revoke the certificate on behalf of that PKI entity.¶

No specific prerequisites apply in addition to those specified in Section 4.2.¶

Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the ones described in Section 5.2.3.¶

The message sequence for this PKI management operation is identical to that given in Section 4.2, with the following changes:¶

1

The rr message MUST be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation.¶

6.4.1. File-based transport

CMP messages MAY be transferred between PKI entities using file-based mechanisms, for instance when an offline EE or a PKI management entity performs delayed enrollment. Each file MUST contain the ASN.1 DER encoding of one CMP message only, where the message may be nested. There MUST be no extraneous header or trailer information in the file. The file name extension ".PKI" MUST be used.¶

6.4.2. Other asynchronous transport protocols

Other asynchronous transport protocols, e.g., email or website up-/download, MAY transfer CMP messages between PKI entities. A MIME wrapping is defined for those environments that are MIME-native. The MIME wrapping in this section is specified in [RFC8551], section 3.1.¶

The ASN.1 DER encoding of the CMP messages MUST be transferred using the "application/pkixcmp" content type and base64-encoded content transfer encoding as specified in [RFC2510], section 5.3. A filename MUST be included either in a "content-type" or a "content-disposition" statement. The file name extension ".PKI" MUST be used.¶