Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)

3.1.1. Definitions of PKI Entities

The entities involved in PKI management include the end entity (i.e., the entity to whom the certificate is issued) and the certification authority (i.e., the entity that issues the certificate). A registration authority MAY also be involved in PKI management.¶

3.1.2. PKI Management Requirements

The protocols given here meet the following requirements on PKI management¶

1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 standards.¶

2. It must be possible to regularly update any key pair without affecting any other key pair.¶

3. The use of confidentiality in PKI management protocols must be kept to a minimum in order to ease acceptance in environments where strong confidentiality might cause regulatory problems.¶

4. PKI management protocols must allow the use of different industry-standard cryptographic algorithms, see CMP Algorithms [RFC9481]. This means that any given CA, RA, or end entity may, in principle, use whichever algorithms suit it for its own key pair(s).¶

5. PKI management protocols must not preclude the generation of key pairs by the end entity concerned, by a KGA or by a CA. Key generation may also occur elsewhere, but for the purposes of PKI management we can regard key generation as occurring wherever the key is first present at an end entity, KGA, or CA.¶

6. PKI management protocols must support the publication of certificates by the end entity concerned, by an RA, or by a CA. Different implementations and different environments may choose any of the above approaches.¶

7. PKI management protocols must support the production of Certificate Revocation Lists (CRLs) by allowing certified end entities to make requests for the revocation of certificates. This must be done in such a way that the denial-of-service attacks, which are possible, are not made simpler.¶

8. PKI management protocols must be usable over a variety of "transport" mechanisms, specifically including mail, HTTP, MQTT, CoAP, and off-line file-based.¶

9. Final authority for certification creation rests with the CA. No RA or end entity equipment can assume that any certificate issued by a CA will contain what was requested; a CA may alter certificate field values or may add, delete, or alter extensions according to its operating policy. In other words, all PKI entities (end-entities, RAs, KGAs, and CAs) must be capable of handling responses to requests for certificates in which the actual certificate issued is different from that requested (for example, a CA may shorten the validity period requested). Note that policy may dictate that the CA must not publish or otherwise distribute the certificate until the requesting entity has reviewed and accepted the newly-created certificate or the POP is completed. In case of publication of the certificate (when using indirect POP, see Section 8.11) or a precertificate in a Certificate Transparency log [RFC9162], the certificate must be revoked if it was not accepted by the EE or the POP could not be completed.¶

10. A graceful, scheduled change-over from one non-compromised CA key pair to the next (CA key update) must be supported (note that if the CA key is compromised, re-initialization must be performed for all entities in the domain of that CA). An end entity whose PSE contains the new CA public key (following a CA key update) may also need to be able to verify certificates verifiable using the old public key. End entities who directly trust the old CA key pair may also need to be able to verify certificates signed using the new CA private key (required for situations where the old CA public key is "hardwired" into the end entity's cryptographic equipment).¶

11. The functions of an RA may, in some implementations or environments, be carried out by the CA itself. The protocols must be designed so that end entities will use the same protocol regardless of whether the communication is with an RA or CA. Naturally, the end entity must use the correct RA or CA public key to verify the protection of the communication.¶

12. Where an end entity requests a certificate containing a given public key value, the end entity must be ready to demonstrate possession of the corresponding private key value. This may be accomplished in various ways, depending on the type of certification request. See Section 4.3 for details of the in-band methods defined for the PKIX-CMP (i.e., Certificate Management Protocol) messages.¶

3.1.3. PKI Management Operations

The following diagram shows the relationship between the entities defined above in terms of the PKI management operations. The letters in the diagram indicate "protocols" in the sense that a defined set of PKI management messages can be sent along each of the lettered lines.¶

  +---+     cert. publish        +------------+      j
  |   |  <---------------------  | End Entity | <-------
  | C |             g            +------------+      "out-of-band"
  | e |                            | ^                loading
  | r |                            | |      initial
  | t |                          a | | b     registration/
  |   |                            | |       certification
  | / |                            | |      key pair recovery
  |   |                            | |      key pair update
  | C |                            | |      certificate update
  | R |  PKI "USERS"               V |      revocation request
  | L | -------------------+-+-----+-+------+-+-------------------
  |   |  PKI MANAGEMENT    | ^              | ^
  |   |    ENTITIES      a | | b          a | | b
  | R |                    V |              | |
  | e |             g   +------+    d       | |
  | p |   <------------ | RA   | <-----+    | |
  | o |      cert.      |      | ----+ |    | |
  | s |       publish   +------+   c | |    | |
  | i |                              | |    | |
  | t |                              V |    V |
  | o |          g                 +------------+   i
  | r |   <------------------------|     CA     |------->
  | y |          h                 +------------+  "out-of-band"
  |   |      cert. publish              | ^         publication
  |   |      CRL publish                | |
  +---+                                 | |    cross-certification
                                      e | | f  cross-certificate
                                        | |       update
                                        | |
                                        V |
                                      +------+
                                      | CA-2 |
                                      +------+

At a high level, the set of operations for which management messages are defined can be grouped as follows.¶

1. CA establishment: When establishing a new CA, certain steps are required (e.g., production of initial CRLs, export of CA public key).¶

2. End entity initialization: This includes importing a root CA public key and requesting information about the options supported by a PKI management entity.¶

3. Certification: Various operations result in the creation of new certificates:¶

   1. initial registration/certification: This is the process whereby an end entity first makes itself known to a CA or RA, prior to the CA issuing a certificate or certificates for that end entity. The end result of this process (when it is successful) is that a CA issues a certificate for an end entity's public key, and returns that certificate to the end entity and/or posts that certificate in a repository. This process may, and typically will, involve multiple "steps", possibly including an initialization of the end entity's equipment. For example, the end entity's equipment must be securely initialized with the public key of a CA, e.g., using zero-touch methods like BRSKI [RFC8995] or SZTP [RFC8572], to be used in validating certificate paths. Furthermore, an end entity typically needs to be initialized with its own key pair(s).¶

   2. key pair update: Every key pair needs to be updated regularly (i.e., replaced with a new key pair), and a new certificate needs to be issued.¶

   3. certificate update: As certificates expire, they may be "refreshed" if nothing relevant in the environment has changed.¶

   4. CA key pair update: As with end entities, CA key pairs need to be updated regularly; however, different mechanisms are required.¶

   5. cross-certification request: One CA requests issuance of a cross-certificate from another CA. For the purposes of this standard, the following terms are defined. A "cross-certificate" is a certificate in which the subject CA and the issuer CA are distinct and SubjectPublicKeyInfo contains a verification key (i.e., the certificate has been issued for the subject CA's signing key pair). When it is necessary to distinguish more finely, the following terms may be used: a cross-certificate is called an "inter-domain cross-certificate" if the subject and issuer CAs belong to different administrative domains; it is called an "intra-domain cross-certificate" otherwise.¶

   • Note 1: The above definition of "cross-certificate" aligns with the defined term "CA-certificate" in X.509. Note that this term is not to be confused with the X.500 "cACertificate" attribute type, which is unrelated.¶

   • Note 2: In many environments, the term "cross-certificate", unless further qualified, will be understood to be synonymous with "inter-domain cross-certificate" as defined above.¶

   • Note 3: Issuance of cross-certificates may be, but is not necessarily, mutual; that is, two CAs may issue cross-certificates for each other.¶

   1. [RFC-Editor: Please fix the enumeration and continue with '6'.] cross-certificate update: Similar to a normal certificate update, but involving a cross-certificate.¶

4. Certificate/CRL discovery operations: Some PKI management operations result in the publication of certificates or CRLs:¶

   1. certificate publication: Having gone to the trouble of producing a certificate, some means for publishing may be needed. The "means" defined in PKIX MAY involve the messages specified in Sections 5.3.13 to 5.3.16, or MAY involve other methods (LDAP, for example) as described in [RFC4511] or [RFC2585] (the "Operational Protocols" documents of the PKIX series of specifications).¶

   2. CRL publication: As for certificate publication.¶

5. Recovery operations: Some PKI management operations are used when an end entity has "lost" its PSE:¶

   1. key pair recovery: As an option, user client key materials (e.g., a user's private key used for decryption purposes) MAY be backed up by a CA, an RA, or a key backup system associated with a CA or RA. If an entity needs to recover these backed up key materials (e.g., as a result of a forgotten password or a lost key chain file), a protocol exchange may be needed to support such recovery.¶

6. Revocation operations: Some PKI management operations result in the creation of new CRL entries and/or new CRLs:¶

   1. revocation request: An authorized person advises a CA of an abnormal situation requiring certificate revocation.¶

7. PSE operations: Whilst the definition of PSE operations (e.g., moving a PSE, changing a PIN, etc.) are beyond the scope of this specification, we do define a PKIMessage (CertRepMessage) that can form the basis of such operations.¶

Note that on-line protocols are not the only way of implementing the above operations. For all operations, there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the operations MAY be achieved as part of the physical token delivery.¶

Later sections define a set of standard messages supporting the above operations. Transfer protocols for conveying these exchanges in various environments (e.g., off-line: file-based, on-line: mail, HTTP [I-D.ietf-lamps-rfc6712bis], MQTT, and CoAP [RFC9482]) are beyond the scope of this document and must be specified separately. Appropriate transfer protocols MUST be capable of delivering the CMP messages reliably.¶

CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Therefore, users should consider protection of confidentiality on lower levels of the protocol stack, e.g., by using TLS [RFC8446], DTLS [RFC9147], or IPSEC [RFC7296].¶

4.2.1. Criteria Used

4.2.2. Initial Registration/Certification Schemes

The criteria above allow for a large number of initial registration/certification schemes. Examples of possible initial registration/certification schemes can be found in the following subsections. An entity may support other schemes specified in profiles of PKIX-CMP, such as Appendix C and Appendix D or [RFC9483].¶

In terms of message flow, the basic authenticated scheme is as
follows:

  End entity                                          RA/CA
  ==========                                      =============
       out-of-band distribution of Initial Authentication
       Key (IAK) and reference value (RA/CA -> EE)
  Key generation
  Creation of certification request
  Protect request with IAK
                -->>-- certification request -->>--
                                                 verify request
                                                 process request
                                                 create response
                --<<-- certification response --<<--
  handle response
  create confirmation
                -->>-- cert conf message      -->>--
                                                 verify confirmation
                                                 create response
                --<<-- conf ack (optional)    --<<--
  handle response

4.3.1. Signature Keys

For signature keys, the end entity can sign a value to prove possession of the private key, see Section 5.2.8.2.¶

4.3.2. Encryption Keys

For encryption keys, the end entity can provide the private key to the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly (see Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2).¶

The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.¶

The indirect method is to issue a certificate that is encrypted for the end entity (and have the end entity demonstrate its ability to decrypt this certificate in the confirmation message). This allows a CA to issue a certificate in a form that can only be used by the intended end entity.¶

This specification encourages use of the indirect method because it requires no extra messages to be sent (i.e., the proof can be demonstrated using the {request, response, confirmation} triple of messages).¶

4.3.3. Key Agreement Keys

For key agreement keys, the end entity and the PKI management entity (i.e., CA or RA) must establish a shared secret key in order to prove that the end entity has possession of the private key.¶

Note that this need not impose any restrictions on the keys that can be certified by a given CA. In particular, for Diffie-Hellman keys the end entity may freely choose its algorithm parameters provided that the CA can generate a short-term (or one-time) key pair with the appropriate parameters when necessary.¶

4.3.4. Key Encapsulation Mechanism Keys

For key encapsulation mechanism (KEM) keys, the end entity can provide the private key to the CA/RA (e.g., for archiving), see Section 5.2.8.3.1, or can be required to decrypt a value in order to prove possession of the private key. Decrypting a value can be achieved either directly (see Section 5.2.8.3.3) or indirectly (see Section 5.2.8.3.2).¶

Note: A definition of key encapsulation mechanisms can be found in [RFC9629], Section 1.¶

The direct method is for the RA/CA to issue a random challenge to which an immediate response by the EE is required.¶

The indirect method is to issue a certificate that is encrypted for the end entity using a shared secret key derived from a key encapsulated using the public key (and have the end entity demonstrate its ability to use its private key for decapsulation of the KEM ciphertext, derive the shared secret key, decrypt this certificate, and provide a hash of the certificate in the confirmation message). This allows a CA to issue a certificate in a form that can only be used by the intended end entity.¶

This specification encourages use of the indirect method because it requires no extra messages to be sent (i.e., the proof can be demonstrated using the {request, response, confirmation} triple of messages).¶

A certification request message for a KEM certificate SHALL use POPOPrivKey by using the keyEncipherment choice of ProofOfPossession, see Section 5.2.8, in the popo field of CertReqMsg as long as no KEM-specific choice is available.¶

4.4.1. CA Operator Actions

To change the key of the CA, the CA operator does the following:¶

1. Generate a new key pair.¶

2. Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate).¶

3. Optionally: Create a link certificate containing the new CA public key signed with the old private key (the "new with old" certificate).¶

4. Optionally: Create a link certificate containing the old CA public key signed with the new private key (the "old with new" certificate).¶

5. Publish these new certificates so that end entities may acquire it, e.g., using a repository or RootCaKeyUpdateContent.¶

The old CA private key is then no longer required when the validity of the "old with old" certificate ended. However, the old CA public key will remain in use for validating the "new with old" link certificate until the new CA public key is loaded into the trusted store. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired and stored the new CA public key.¶

The "new with new" certificate must have a validity period with a notBefore time that is before the notAfter time of the "old with old" certificate and a notAfter time that is after the notBefore time of the next update of this certificate.¶

The "new with old" certificate must have a validity period with the same notBefore time as the "new with new" certificate and a notAfter time by which all end entities of this CA will securely possess the new CA public key (at the latest, at the notAfter time of the "old with old" certificate).¶

The "old with new" certificate must have a validity period with the same notBefore and notAfter time as the "old with old" certificate.¶

Note: Further operational considerations on transition from one root CA self-signed certificate to the next is available in RFC 8649 Section 5 [RFC8649].¶

4.4.2. Verifying Certificates

Normally when verifying a signature, the verifier verifies (among other things) the certificate containing the public key of the signer. However, once a CA is allowed to update its key there are a range of new possibilities. These are shown in the table below.¶

4.4.3. Revocation - Change of CA Key

As we saw above, the verification of a certificate becomes more complex once the CA is allowed to change its key. This is also true for revocation checks as the CA may have signed the CRL using a newer private key than the one within the user's PSE.¶

The analysis of the alternatives is the same as for certificate verification.¶

5.1.1. PKI Message Header

All PKI messages require some header information for addressing and transaction identification. Some of this information will also be present in a transport-specific envelope. However, if the PKI message is protected, then this information is also protected (i.e., we make no assumption about secure transport).¶

The following data structure is used to contain this information:¶

  PKIHeader ::= SEQUENCE {
     pvno                INTEGER     { cmp1999(1), cmp2000(2),
                                       cmp2021(3) },
     sender              GeneralName,
     recipient           GeneralName,
     messageTime     [0] GeneralizedTime         OPTIONAL,
     protectionAlg   [1] AlgorithmIdentifier{ALGORITHM, {...}}
                         OPTIONAL,
     senderKID       [2] KeyIdentifier           OPTIONAL,
     recipKID        [3] KeyIdentifier           OPTIONAL,
     transactionID   [4] OCTET STRING            OPTIONAL,
     senderNonce     [5] OCTET STRING            OPTIONAL,
     recipNonce      [6] OCTET STRING            OPTIONAL,
     freeText        [7] PKIFreeText             OPTIONAL,
     generalInfo     [8] SEQUENCE SIZE (1..MAX) OF
                         InfoTypeAndValue     OPTIONAL
  }

  PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String

The usage of the protocol version number (pvno) is described in Section 7.¶

The sender field contains the name of the sender of the PKIMessage. This name (in conjunction with senderKID, if supplied) should be sufficient to indicate the key to use to verify the protection on the message. If nothing about the sender is known to the sending entity (e.g., in the initial request message, where the end entity may not know its own Distinguished Name (DN), e-mail name, IP address, etc.), then the "sender" field MUST contain a "NULL-DN" value in the directoryName choice. A "NULL-DN" is a SEQUENCE OF relative distinguished names of zero length and is encoded as 0x3000. In such a case, the senderKID field MUST hold an identifier (i.e., a reference number) that indicates to the receiver the appropriate shared secret information to use to verify the message.¶

The recipient field contains the name of the recipient of the PKIMessage. This name (in conjunction with recipKID, if supplied) should be usable to verify the protection on the message.¶

The protectionAlg field specifies the algorithm used to protect the message. If no protection bits are supplied (note that PKIProtection is OPTIONAL) then this field MUST be omitted; if protection bits are supplied, then this field MUST be supplied.¶

senderKID and recipKID are usable to indicate which keys have been used to protect the message (recipKID will normally only be required where protection of the message uses Diffie-Hellman (DH) or elliptic curve Diffie-Hellman (ECDH) keys). These fields MUST be used if required to uniquely identify a key (e.g., if more than one key is associated with a given sender name). The senderKID SHOULD be used in any case.¶

Note: The recommendation of using senderKID was changed since [RFC4210], where it was recommended to be omitted if not needed to identify the protection key.¶

The transactionID field within the message header is to be used to allow the recipient of a message to correlate this with an ongoing transaction. This is needed for all transactions that consist of more than just a single request/response pair. For transactions that consist of a single request/response pair, the rules are as follows. A client MUST populate the transactionID field if the message contains an infoValue of type KemCiphertextInfo, see Section 5.1.3.4. In all other cases the client MAY populate the transactionID field of the request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field if the message contains a KemCiphertextInfo field. In all other cases the server MAY set transactionID field of the response.¶

For transactions that consist of more than just a single request/response pair, the rules are as follows. If the message contains an infoValue of type KemCiphertextInfo, the client MUST generate a transactionID, otherwise the client SHOULD generate a transactionID for the first request. If a server receives such a request that has the transactionID field set, then it MUST set the transactionID field of the response to the same value. If a server receives such request with a missing transactionID field, then it MUST populate the transactionID field of the response with a server-generated ID. Subsequent requests and responses MUST all set the transactionID field to the thus established value. In all cases where a transactionID is being used, a given client MUST NOT have more than one transaction with the same transactionID in progress at any time (to a given server). Servers are free to require uniqueness of the transactionID or not, as long as they are able to correctly associate messages with the corresponding transaction. Typically, this means that a server will require the {client, transactionID} tuple to be unique, or even the transactionID alone to be unique, if it cannot distinguish clients based on transport-level information. A server receiving the first message of a transaction (which requires more than a single request/response pair) that contains a transactionID that does not allow it to meet the above constraints (typically because the transactionID is already in use) MUST send back an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse. It is RECOMMENDED that the clients fill the transactionID field with 128 bits of (pseudo-) random data for the start of a transaction to reduce the probability of having the transactionID in use at the server.¶

The senderNonce and recipNonce fields protect the PKIMessage against replay attacks. The senderNonce will typically be 128 bits of (pseudo-) random data generated by the sender, whereas the recipNonce is copied from the senderNonce field of the previous message in the transaction.¶

The messageTime field contains the time at which the sender created the message. This may be useful to allow end entities to correct/check their local time for consistency with the time on a central system.¶

The freeText field may be used to send a human-readable message to the recipient (in any number of languages). The first language used in this sequence indicates the desired language for replies.¶

The generalInfo field may be used to send machine-processable additional data to the recipient. The following generalInfo extensions are defined and MAY be supported.¶

  id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
  ImplicitConfirmValue ::= NULL

  id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
  ConfirmWaitTimeValue ::= GeneralizedTime

  id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15}
  OrigPKIMessageValue ::= PKIMessages

  id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21}
  CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String

  id-it-KemCiphertextInfo OBJECT IDENTIFIER ::= { id-it TBD1 }
  KemCiphertextInfoValue ::= KemCiphertextInfo

5.1.2. PKI Message Body

  PKIBody ::= CHOICE {
     ir       [0]  CertReqMessages,        --Initialization Req
     ip       [1]  CertRepMessage,         --Initialization Resp
     cr       [2]  CertReqMessages,        --Certification Req
     cp       [3]  CertRepMessage,         --Certification Resp
     p10cr    [4]  CertificationRequest,   --PKCS #10 Cert.  Req.
     popdecc  [5]  POPODecKeyChallContent, --pop Challenge
     popdecr  [6]  POPODecKeyRespContent,  --pop Response
     kur      [7]  CertReqMessages,        --Key Update Request
     kup      [8]  CertRepMessage,         --Key Update Response
     krr      [9]  CertReqMessages,        --Key Recovery Req
     krp      [10] KeyRecRepContent,       --Key Recovery Resp
     rr       [11] RevReqContent,          --Revocation Request
     rp       [12] RevRepContent,          --Revocation Response
     ccr      [13] CertReqMessages,        --Cross-Cert.  Request
     ccp      [14] CertRepMessage,         --Cross-Cert.  Resp
     ckuann   [15] CAKeyUpdContent,        --CA Key Update Ann.
     cann     [16] CertAnnContent,         --Certificate Ann.
     rann     [17] RevAnnContent,          --Revocation Ann.
     crlann   [18] CRLAnnContent,          --CRL Announcement
     pkiconf  [19] PKIConfirmContent,      --Confirmation
     nested   [20] NestedMessageContent,   --Nested Message
     genm     [21] GenMsgContent,          --General Message
     genp     [22] GenRepContent,          --General Response
     error    [23] ErrorMsgContent,        --Error Message
     certConf [24] CertConfirmContent,     --Certificate Confirm
     pollReq  [25] PollReqContent,         --Polling Request
     pollRep  [26] PollRepContent          --Polling Response
  }

The specific types are described in Section 5.3 below.¶

5.1.3. PKI Message Protection

Some PKI messages will be protected for integrity.¶

Note: If an asymmetric algorithm is used to protect a message and the relevant public component has been certified already, then the origin of the message can also be authenticated. On the other hand, if the public component is uncertified, then the message origin cannot be automatically authenticated, but may be authenticated via out-of-band means.¶

When protection is applied, the following structure is used:¶

  PKIProtection ::= BIT STRING

The input to the calculation of PKIProtection is the DER encoding of the following data structure:¶

  ProtectedPart ::= SEQUENCE {
     header    PKIHeader,
     body      PKIBody
  }

There MAY be cases in which the PKIProtection BIT STRING is deliberately not used to protect a message (i.e., this OPTIONAL field is omitted) because other protection, external to PKIX, will be applied instead. Such a choice is explicitly allowed in this specification. Examples of such external protection include CMS [RFC5652] and Security Multiparts [RFC1847] encapsulation of the PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the relevant PKIHeader information is securely carried in the external mechanism). It is noted, however, that many such external mechanisms require that the end entity already possesses a public-key certificate, and/or a unique Distinguished Name, and/or other such infrastructure-related information. Thus, they may not be appropriate for initial registration, key-recovery, or any other process with "boot-strapping" characteristics. For those cases it may be necessary that the PKIProtection parameter be used. In the future, if/when external mechanisms are modified to accommodate boot-strapping scenarios, the use of PKIProtection may become rare or non-existent.¶

Depending on the circumstances, the PKIProtection bits may contain a Message Authentication Code (MAC) or signature. Only the following cases can occur:¶

  id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
  PBMParameter ::= SEQUENCE {
     salt                OCTET STRING,
     owf                 AlgorithmIdentifier,
     iterationCount      INTEGER,
     mac                 AlgorithmIdentifier
  }

  id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30}

  DHBMParameter ::= SEQUENCE {
     owf                 AlgorithmIdentifier,
     -- AlgId for a One-Way Function
     mac                 AlgorithmIdentifier
     -- the MAC AlgId
  }

  id-KemBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 16}

  KemBMParameter ::= SEQUENCE {
    kdf              AlgorithmIdentifier{KEY-DERIVATION, {...}},
    kemContext   [0] OCTET STRING OPTIONAL,
    len              INTEGER (1..MAX),
    mac              AlgorithmIdentifier{MAC-ALGORITHM, {...}}
  }

Step# Alice                                Bob
---------------------------------------------------------------------
  1                                        perform KEM Encapsulate
                       <- KEM Ciphertext <-
  2   perform KEM Decapsulate,
        perform key derivation,
        format message with
        MAC-based protection
                       ->    message     ->
  3                                        perform key derivation,
                                             verify MAC-based
                                             protection
-------------------  Alice authenticated by Bob  --------------------

  NestedMessageContent ::= PKIMessages

5.2.1. Requested Certificate Contents

Various PKI management messages require that the originator of the message indicate some of the fields that are required to be present in a certificate. The CertTemplate structure allows an end entity or RA to specify as much as it wishes about the certificate it requires. CertTemplate is identical to a Certificate, but with all fields optional.¶

Note: Even if the originator completely specifies the contents of a certificate it requires, a CA is free to modify fields within the certificate actually issued. If the modified certificate is unacceptable to the requester, the requester MUST send back a certConf message that either does not include this certificate (via a CertHash), or does include this certificate (via a CertHash) along with a status of "rejected". See Section 5.3.18 for the definition and use of CertHash and the certConf message.¶

Note: Before requesting a new certificate, an end entity can request a certTemplate structure as a kind of certificate request blueprint, in order to learn which data the CA expects to be present in the certificate request, see Section 5.3.19.16.¶

See CRMF [RFC4211] for CertTemplate syntax.¶

If certTemplate is an empty SEQUENCE (i.e., all fields omitted), then the controls field in the CertRequest structure MAY contain the id-regCtrl-altCertTemplate control, specifying a template for a certificate other than an X.509v3 public-key certificate. Conversely, if certTemplate is not empty (i.e., at least one field is present), then controls MUST NOT contain id-regCtrl-altCertTemplate. The new control is defined as follows:¶

  id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) pkip(5) regCtrl(1) 7}

  AltCertTemplate ::= AttributeTypeAndValue

See also [RFC4212] for more details on how to manage certificates in alternative formats using CRMF [RFC4211] syntax.¶

5.2.2. Encrypted Values

When encrypted data like a private key, certificate, POP challenge, or revocation passphrase is sent in PKI messages it is RECOMMENDED to use the EnvelopedData structure. In some cases this is accomplished by using the EncryptedKey data structure instead of EncryptedValue.¶

  EncryptedKey ::= CHOICE {
     encryptedValue       EncryptedValue, -- deprecated
     envelopedData    [0] EnvelopedData }

See Certificate Request Message Format (CRMF) [RFC4211] for EncryptedKey and EncryptedValue syntax and Cryptographic Message Syntax (CMS) [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data structure offers the choice to either use EncryptedValue (for backward compatibility only) or EnvelopedData. The use of the EncryptedValue structure has been deprecated in favor of the EnvelopedData structure. Therefore, it is RECOMMENDED to use EnvelopedData.¶

Note: The EncryptedKey structure defined in CRMF [RFC4211] is used here, which makes the update backward compatible. Using the new syntax with the untagged default choice EncryptedValue is bits-on-the-wire compatible with the old syntax.¶

To indicate support for EnvelopedData, the pvno cmp2021 has been introduced. Details on the usage of the protocol version number (pvno) are described in Section 7.¶

The EnvelopedData structure is RECOMMENDED to use in CMP to transport a private key, certificate, POP challenge, or revocation passphrase in encrypted form as follows:¶

• It contains only one RecipientInfo structure because the content is encrypted only for one recipient.¶

• It may contain a private key in the AsymmetricKeyPackage structure (which is placed in the encryptedContentInfo field), as defined in [RFC5958], that is wrapped in a SignedData structure, as specified in Section 5 of [RFC5652] and [RFC8933], signed by the Key Generation Authority or CA.¶

• It may contain a certificate, POP challenge, or revocation passphrase directly in the encryptedContent field.¶

The content of the EnvelopedData structure, as specified in Section 6 of [RFC5652], MUST be encrypted using a newly generated symmetric content-encryption key. This content-encryption key MUST be securely provided to the recipient using one of four key management techniques.¶

The choice of the key management technique to be used by the sender depends on the credential available at the recipient:¶

• recipient's certificate with an algorithm identifier and a public key that supports key transport and where any given key usage extension allows keyEncipherment: The content-encryption key will be protected using the key transport key management technique, as specified in Section 6.2.1 of [RFC5652].¶

• recipient's certificate with an algorithm identifier and a public key that supports key agreement and where any given key usage extension allows keyAgreement: The content-encryption key will be protected using the key agreement key management technique, as specified in Section 6.2.2 of [RFC5652].¶

• a password or shared secret: The content-encryption key will be protected using the password-based key management technique, as specified in Section 6.2.4 of [RFC5652].¶

• recipient's certificate with an algorithm identifier and a public key that supports key encapsulation mechanism and where any given key usage extension allows keyEncipherment: The content-encryption key will be protected using the key management technique for KEM keys, as specified in [RFC9629].¶

Note: There are cases where the algorithm identifier, the type of the public key, and the key usage extension will not be sufficient to decide on the key management technique to use, e.g., when rsaEncryption is the algorithm identifier. In such cases it is a matter of local policy to decide.¶

5.2.3. Status Codes and Failure Information for PKI Messages

All response messages will include some status information. The following values are defined.¶

  PKIStatus ::= INTEGER {
     accepted               (0),
     grantedWithMods        (1),
     rejection              (2),
     waiting                (3),
     revocationWarning      (4),
     revocationNotification (5),
     keyUpdateWarning       (6)
  }

Responders may use the following syntax to provide more information about failure cases.¶

  PKIFailureInfo ::= BIT STRING {
     badAlg                 (0),
     badMessageCheck        (1),
     badRequest             (2),
     badTime                (3),
     badCertId              (4),
     badDataFormat          (5),
     wrongAuthority         (6),
     incorrectData          (7),
     missingTimeStamp       (8),
     badPOP                 (9),
     certRevoked            (10),
     certConfirmed          (11),
     wrongIntegrity         (12),
     badRecipientNonce      (13),
     timeNotAvailable       (14),
     unacceptedPolicy       (15),
     unacceptedExtension    (16),
     addInfoNotAvailable    (17),
     badSenderNonce         (18),
     badCertTemplate        (19),
     signerNotTrusted       (20),
     transactionIdInUse     (21),
     unsupportedVersion     (22),
     notAuthorized          (23),
     systemUnavail          (24),
     systemFailure          (25),
     duplicateCertReq       (26)
  }

  PKIStatusInfo ::= SEQUENCE {
     status        PKIStatus,
     statusString  PKIFreeText     OPTIONAL,
     failInfo      PKIFailureInfo  OPTIONAL
  }

5.2.4. Certificate Identification

In order to identify particular certificates, the CertId data structure is used.¶

See [RFC4211] for CertId syntax.¶

5.2.5. Out-of-band root CA Public Key

Each root CA must be able to publish its current public key via some "out-of-band" means or together with the respective link certificate using an online mechanism. While such mechanisms are beyond the scope of this document, we define data structures that can support such mechanisms.¶

There are generally two methods available: Either the CA directly publishes its self-signed certificate, or this information is available via the directory (or equivalent) and the CA publishes a hash of this value to allow verification of its integrity before use.¶

Note: As an alternative to out-of-band distribution of root CA public keys, the CA can provide the self-signed certificate together with link certificates, e.g., using RootCaKeyUpdateContent (Section 5.3.19.15).¶

  OOBCert ::= Certificate

The fields within this certificate are restricted as follows:¶

• The certificate MUST be self-signed (i.e., the signature must be verifiable using the SubjectPublicKeyInfo field);¶

• The subject and issuer fields MUST be identical;¶

• If the subject field contains a "NULL-DN", then both subjectAltNames and issuerAltNames extensions MUST be present and have exactly the same value;¶

• The values of all other extensions must be suitable for a self-signed certificate (e.g., key identifiers for subject and issuer must be the same).¶

  OOBCertHash ::= SEQUENCE {
     hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
     certId      [1] CertId                  OPTIONAL,
     hashVal         BIT STRING
  }

The intention of the hash value is that anyone who has securely received the hash value (via the out-of-band means) can verify a self-signed certificate for that CA.¶

5.2.6. Archive Options

Requesters may indicate that they wish the PKI to archive a private key value using the PKIArchiveOptions structure.¶

See [RFC4211] for PKIArchiveOptions syntax.¶

5.2.7. Publication Information

Requesters may indicate that they wish the PKI to publish a certificate using the PKIPublicationInfo structure.¶

See [RFC4211] for PKIPublicationInfo syntax.¶

5.2.8. Proof-of-Possession Structures

The proof-of-possession structure used is indicated in the popo field of type ProofOfPossession in the CertReqMsg sequence, see Section 4 of [RFC4211].¶

   ProofOfPossession ::= CHOICE {
      raVerified      [0] NULL,
      signature       [1] POPOSigningKey,
      keyEncipherment [2] POPOPrivKey,
      keyAgreement    [3] POPOPrivKey
   }

   POPOSigningKey ::= SEQUENCE {
      poposkInput [0] POPOSigningKeyInput OPTIONAL,
      algorithmIdentifier AlgorithmIdentifier,
      signature BIT STRING
   }

   POPOSigningKeyInput ::= SEQUENCE {
      authInfo CHOICE {
         sender [0] GeneralName,
         publicKeyMAC PKMACValue
      },
      publicKey SubjectPublicKeyInfo
   }

   PKMACValue ::= SEQUENCE {
      algId AlgorithmIdentifier,
      value BIT STRING
   }

   POPOPrivKey ::= CHOICE {
      thisMessage [0] BIT STRING, -- deprecated
      subsequentMessage [1] SubsequentMessage,
      dhMAC [2] BIT STRING, -- deprecated
      agreeMAC [3] PKMACValue,
      encryptedKey [4] EnvelopedData
   }

   SubsequentMessage ::= INTEGER {
      encrCert (0),
      challengeResp (1)
   }

                EE                         RA/CA
                 ----       req        ---->
                 <---  rep (enc cert)  -----
                 ---- conf (cert hash) ---->
                 <---       ack        -----

                EE            RA            CA
                 ---- req ---->
                 <--- chall ---
                 ---- resp --->
                               ---- req' --->
                               <--- rep -----
                               ---- conf --->
                               <--- ack -----
                 <--- rep -----
                 ---- conf --->
                 <--- ack -----

                EE            RA            CA
                 ---- req ---->
                 <--- chall ---
                 ---- resp --->
                               ---- req' --->
                               <--- rep -----
                 <--- rep -----
                 ---- conf --->
                               ---- conf --->
                               <--- ack -----
                 <--- ack -----

   POPODecKeyChallContent ::= SEQUENCE OF Challenge

   Challenge ::= SEQUENCE {
      owf AlgorithmIdentifier OPTIONAL,
      witness OCTET STRING,
      challenge OCTET STRING, -- deprecated
      encryptedRand [0] EnvelopedData OPTIONAL
   }

   Rand ::= SEQUENCE {
      int INTEGER,
      sender GeneralName
   }

   POPODecKeyRespContent ::= SEQUENCE OF INTEGER

   RAVerified;
   SKPOP;
   EKPOPThisMessage; -- deprecated
   KAKPOPThisMessage; -- deprecated
   EKPOPEncryptedKey;
   KAKPOPEncryptedKey;
   KEMKPOPEncryptedKey;
   KAKPOPThisMessageDHMAC;
   EKPOPEncryptedCert;
   KAKPOPEncryptedCert;
   KEMKPOPEncryptedCert;
   EKPOPChallengeResp;
   KAKPOPChallengeResp; and
   KEMKPOPChallengeResp.

5.2.9. GeneralizedTime

GeneralizedTime is a standard ASN.1 type and SHALL be used as specified in Section 4.1.2.5.2 of [RFC5280].¶

5.3.1. Initialization Request

An Initialization request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields which may be supplied for each certificate requested (see the profiles defined in [RFC9483] Section 4.1.1, Appendix C.4 and Appendix D.7 for further information). This message is intended to be used for entities when first initializing into the PKI.¶

See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.¶

5.3.2. Initialization Response

An Initialization response message contains as the PKIBody a CertRepMessage data structure, which has for each certificate requested a PKIStatusInfo field, a subject certificate, and possibly a private key (normally encrypted using EnvelopedData, see [RFC9483] Section 4.1.6 for further information).¶

See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI Message Protection is "shared secret information" (see Section 5.1.3.1), then any certificate transported in the caPubs field may be directly trusted as a root CA certificate by the initiator.¶

5.3.3. Certification Request

A Certification request message contains as the PKIBody a CertReqMessages data structure, which specifies the requested certificates (see the profiles defined in [RFC9483] Section 4.1.2 and Appendix C.2 for further information). This message is intended to be used for existing PKI entities who wish to obtain additional certificates.¶

See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.¶

Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [RFC2986], see the profiles defined in [RFC9483] Section 4.1.4 for further information). This structure may be required for certificate requests for signing key pairs when interoperation with legacy systems is desired, but its use is strongly discouraged whenever not absolutely necessary.¶

5.3.4. Certification Response

A Certification response message contains as the PKIBody a CertRepMessage data structure, which has a status value for each certificate requested, and optionally has a CA public key, failure information, a subject certificate, and an encrypted private key.¶

  CertRepMessage ::= SEQUENCE {
     caPubs          [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                         OPTIONAL,
     response            SEQUENCE OF CertResponse
  }

  CertResponse ::= SEQUENCE {
     certReqId           INTEGER,
     status              PKIStatusInfo,
     certifiedKeyPair    CertifiedKeyPair     OPTIONAL,
     rspInfo             OCTET STRING         OPTIONAL
     -- analogous to the id-regInfo-utf8Pairs string defined
     -- for regInfo in CertReqMsg [RFC4211]
  }

  CertifiedKeyPair ::= SEQUENCE {
     certOrEncCert       CertOrEncCert,
     privateKey      [0] EncryptedKey         OPTIONAL,
     -- See [RFC4211] for comments on encoding.
     publicationInfo [1] PKIPublicationInfo   OPTIONAL
  }

  CertOrEncCert ::= CHOICE {
     certificate     [0] CMPCertificate,
     encryptedCert   [1] EncryptedKey
  }

A p10cr message contains exactly one CertificationRequestInfo data structure, as specified in PKCS#10 [RFC2986], but no certReqId. Therefore, the certReqId in the corresponding Certification Response (cp) message MUST be set to -1.¶

Only one of the failInfo (in PKIStatusInfo) and certificate (in CertifiedKeyPair) fields can be present in each CertResponse (depending on the status). For some status values (e.g., waiting), neither of the optional fields will be present.¶

Given an EncryptedCert and the relevant decryption key, the certificate may be obtained. The purpose of this is to allow a CA to return the value of a certificate, but with the constraint that only the intended recipient can obtain the actual certificate. The benefit of this approach is that a CA may reply with a certificate even in the absence of a proof that the requester is the end entity that can use the relevant private key (note that the proof is not obtained until the certConf message is received by the CA). Thus, the CA will not have to revoke that certificate in the event that something goes wrong with the proof-of-possession (but MAY do so anyway, depending upon policy).¶

The use of EncryptedKey is described in Section 5.2.2.¶

Note: To indicate support for EnvelopedData, the pvno cmp2021 has been introduced. Details on the usage of different protocol version numbers (pvno) are described in Section 7.¶

5.3.5. Key Update Request Content

For key update requests the CertReqMessages syntax is used. Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template fields that may be supplied for each key to be updated (see the profiles defined in [RFC9483] Section 4.1.3 and Appendix C.6 for further information). This message is intended to be used to request updates to existing (non-revoked and non-expired) certificates (therefore, it is sometimes referred to as a "Certificate Update" operation). An update is a replacement certificate containing either a new subject public key or the current subject public key (although the latter practice may not be appropriate for some environments).¶

See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.¶

5.3.6. Key Update Response Content

For key update responses, the CertRepMessage syntax is used. The response is identical to the initialization response.¶

See Section 5.3.4 for CertRepMessage syntax.¶

5.3.7. Key Recovery Request Content

For key recovery requests the syntax used is identical to the initialization request CertReqMessages. Typically, SubjectPublicKeyInfo and KeyId are the template fields that may be used to supply a signature public key for which a certificate is required.¶

See Section 5.2.1 and [RFC4211] for CertReqMessages syntax. Note that if a key history is required, the requester must supply a Protocol Encryption Key control in the request message.¶

5.3.8. Key Recovery Response Content

For key recovery responses, the following syntax is used. For some status values (e.g., waiting) none of the optional fields will be present.¶

  KeyRecRepContent ::= SEQUENCE {
     status            PKIStatusInfo,
     newSigCert    [0] Certificate                 OPTIONAL,
     caCerts       [1] SEQUENCE SIZE (1..MAX) OF
                                  Certificate      OPTIONAL,
     keyPairHist   [2] SEQUENCE SIZE (1..MAX) OF
                                  CertifiedKeyPair OPTIONAL
  }

5.3.9. Revocation Request Content

When requesting revocation of a certificate (or several certificates), the following data structure is used (see the profiles defined in [RFC9483] Section 4.2 for further information). The name of the requester is present in the PKIHeader structure.¶

  RevReqContent ::= SEQUENCE OF RevDetails

  RevDetails ::= SEQUENCE {
     certDetails         CertTemplate,
     crlEntryDetails     Extensions       OPTIONAL
  }

5.3.10. Revocation Response Content

The revocation response is the response to the above message. If produced, this is sent to the requester of the revocation. (A separate revocation announcement message MAY be sent to the subject of the certificate for which revocation was requested.)¶

  RevRepContent ::= SEQUENCE {
     status        SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
     revCerts  [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
     crls      [1] SEQUENCE SIZE (1..MAX) OF CertificateList
                   OPTIONAL
  }

5.3.11. Cross Certification Request Content

Cross certification requests use the same syntax (CertReqMessages) as normal certification requests, with the restriction that the key pair MUST have been generated by the requesting CA and the private key MUST NOT be sent to the responding CA (see the profiles defined in Appendix D.6 for further information). This request MAY also be used by subordinate CAs to get their certificates signed by the parent CA.¶

See Section 5.2.1 and [RFC4211] for CertReqMessages syntax.¶

5.3.12. Cross Certification Response Content

Cross certification responses use the same syntax (CertRepMessage) as normal certification responses, with the restriction that no encrypted private key can be sent.¶

See Section 5.3.4 for CertRepMessage syntax.¶

5.3.13. CA Key Update Announcement Content

When a CA updates its own key pair, the following data structure MAY be used to announce this event.¶

  RootCaKeyUpdateContent ::= SEQUENCE {
     newWithNew              CMPCertificate,
     newWithOld          [0] CMPCertificate OPTIONAL,
     oldWithNew          [1] CMPCertificate OPTIONAL
  }

CAKeyUpdContent ::= CHOICE {
    cAKeyUpdAnnV2      CAKeyUpdAnnContent, -- deprecated
    cAKeyUpdAnnV3  [0] RootCaKeyUpdateContent
}

When using RootCaKeyUpdateContent in the ckuann message, the pvno cmp2021 MUST be used. Details on the usage of the protocol version number (pvno) are described in Section 7.¶

In contrast to CAKeyUpdAnnContent as supported with cmp2000, RootCaKeyUpdateContent offers omitting newWithOld and oldWithNew, depending on the needs of the EE.¶

5.3.14. Certificate Announcement

This structure MAY be used to announce the existence of certificates.¶

Note that this message is intended to be used for those cases (if any) where there is no pre-existing method for publication of certificates; it is not intended to be used where, for example, X.500 is the method for publication of certificates.¶

  CertAnnContent ::= Certificate

5.3.15. Revocation Announcement

When a CA has revoked, or is about to revoke, a particular certificate, it MAY issue an announcement of this (possibly upcoming) event.¶

  RevAnnContent ::= SEQUENCE {
     status              PKIStatus,
     certId              CertId,
     willBeRevokedAt     GeneralizedTime,
     badSinceDate        GeneralizedTime,
     crlDetails          Extensions  OPTIONAL
  }

A CA MAY use such an announcement to warn (or notify) a subject that its certificate is about to be (or has been) revoked. This would typically be used where the request for revocation did not come from the subject concerned.¶

The willBeRevokedAt field contains the time at which a new entry will be added to the relevant CRLs.¶

5.3.16. CRL Announcement

When a CA issues a new CRL (or set of CRLs) the following data structure MAY be used to announce this event.¶

  CRLAnnContent ::= SEQUENCE OF CertificateList

5.3.17. PKI Confirmation Content

This data structure is used in the protocol exchange as the final PKIMessage. Its content is the same in all cases -- actually there is no content since the PKIHeader carries all the required information.¶

  PKIConfirmContent ::= NULL

Use of this message for certificate confirmation is NOT RECOMMENDED; certConf SHOULD be used instead. Upon receiving a PKIConfirm for a certificate response, the recipient MAY treat it as a certConf with all certificates being accepted.¶

5.3.18. Certificate Confirmation Content

This data structure is used by the client to send a confirmation to the CA/RA to accept or reject certificates.¶

  CertConfirmContent ::= SEQUENCE OF CertStatus

  CertStatus ::= SEQUENCE {
     certHash    OCTET STRING,
     certReqId   INTEGER,
     statusInfo  PKIStatusInfo OPTIONAL,
     hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}
                 OPTIONAL
  }

The hashAlg field SHOULD be used only in exceptional cases where the signatureAlgorithm of the certificate to be confirmed does not specify a hash algorithm in the OID or in the parameters or no hash algorithm is specified for hashing certificates signed using the signatureAlgorithm. Note that for EdDSA a hash algorithm is specified in Section 3.3 of [RFC9481], such that the hashAlg field is not needed for EdDSA. Otherwise, the certHash value SHALL be computed using the same hash algorithm as used to create and verify the certificate signature or as specified for hashing certificates signed using the signatureAlgorithm. If hashAlg is used, the CMP version indicated by the certConf message header must be cmp2021(3).¶

For any particular CertStatus, omission of the statusInfo field indicates acceptance of the specified certificate. Alternatively, explicit status details (with respect to acceptance or rejection) MAY be provided in the statusInfo field, perhaps for auditing purposes at the CA/RA.¶

Within CertConfirmContent, omission of a CertStatus structure corresponding to a certificate supplied in the previous response message indicates rejection of the certificate. Thus, an empty CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate rejection of all supplied certificates. See Section 5.2.8.3.2, for a discussion of the certHash field with respect to proof-of-possession.¶

5.3.19. PKI General Message Content

  InfoTypeAndValue ::= SEQUENCE {
     infoType               OBJECT IDENTIFIER,
     infoValue              ANY DEFINED BY infoType  OPTIONAL
  }

  -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
  GenMsgContent ::= SEQUENCE OF InfoTypeAndValue

  GenMsg:    {id-it 1}, < absent >
  GenRep:    {id-it 1}, Certificate | < absent >

  GenMsg:    {id-it 2}, < absent >
  GenRep:    {id-it 2}, SEQUENCE SIZE (1..MAX) OF
                          AlgorithmIdentifier

  GenMsg:    {id-it 3}, < absent >
  GenRep:    {id-it 3}, SEQUENCE SIZE (1..MAX) OF
                          AlgorithmIdentifier

  GenMsg:    {id-it 4}, < absent >
  GenRep:    {id-it 4}, AlgorithmIdentifier

  GenMsg:    {id-it 18}, RootCaKeyUpdateValue

  GenMsg:    {id-it 6}, < absent >
  GenRep:    {id-it 6}, CertificateList

  GenRep:    {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER

  GenMsg:    {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
  GenRep:    {id-it 11}, AlgorithmIdentifier | < absent >

  GenMsg:    {id-it 12}, EncryptedKey
  GenRep:    {id-it 12}, < absent >

  GenMsg:    {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
  GenRep:    {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

  GenMsg:    {id-it 17}, < absent >
  GenRep:    {id-it 17}, SEQUENCE SIZE (1..MAX) OF
                           CMPCertificate | < absent >

  GenMsg:    {id-it 20}, RootCaCertValue | < absent >
  GenRep:    {id-it 18}, RootCaKeyUpdateValue | < absent >

  RootCaCertValue ::= CMPCertificate

  RootCaKeyUpdateValue ::= RootCaKeyUpdateContent

  RootCaKeyUpdateContent ::= SEQUENCE {
     newWithNew              CMPCertificate,
     newWithOld          [0] CMPCertificate OPTIONAL,
     oldWithNew          [1] CMPCertificate OPTIONAL
  }

  GenMsg:    {id-it 19}, < absent >
  GenRep:    {id-it 19}, CertReqTemplateContent | < absent >

  CertReqTemplateValue  ::= CertReqTemplateContent

  CertReqTemplateContent ::= SEQUENCE {
     certTemplate           CertTemplate,
     keySpec                Controls OPTIONAL }

  Controls  ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue

  id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) pkip(5) regCtrl(1) 11 }

  AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}}

  id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1)
     identified-organization(3) dod(6) internet(1) security(5)
     mechanisms(5) pkix(7) pkip(5) regCtrl(1) 12 }

  RsaKeyLenCtrl ::= INTEGER (1..MAX)

  GenMsg:    {id-it 22}, SEQUENCE SIZE (1..MAX) OF CRLStatus
  GenRep:    {id-it 23}, SEQUENCE SIZE (1..MAX) OF
                           CertificateList  |  < absent >

  CRLSource ::= CHOICE {
     dpn          [0] DistributionPointName,
     issuer       [1] GeneralNames }

  CRLStatus ::= SEQUENCE {
     source       CRLSource,
     thisUpdate   Time OPTIONAL }

  GenMsg:    {id-it TBD1}, < absent >
  GenRep:    {id-it TBD1}, KemCiphertextInfo

  KemCiphertextInfo ::= SEQUENCE {
    kem              AlgorithmIdentifier{KEM-ALGORITHM, {...}},
    ct               OCTET STRING
  }

5.3.20. PKI General Response Content

  GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Examples of GenReps that MAY be supported include those listed in the subsections of Section 5.3.19.¶

5.3.21. Error Message Content

This data structure MAY be used by EE, CA, or RA to convey error information and by a PKI management entity to initiate delayed delivery of responses.¶

  ErrorMsgContent ::= SEQUENCE {
     pKIStatusInfo          PKIStatusInfo,
     errorCode              INTEGER           OPTIONAL,
     errorDetails           PKIFreeText       OPTIONAL
  }

This message MAY be generated at any time during a PKI transaction. If the client sends this request, the server MUST respond with a PKIConfirm response, or another ErrorMsg if any part of the header is not valid.¶

In case a PKI management entity sends an error message to the EE with the pKIStatusInfo field containing the status "waiting", the EE SHOULD initiate polling as described in Section 5.3.22. If the EE does not initiate polling, both sides MUST treat this message as the end of the transaction (if a transaction is in progress).¶

If protection is desired on the message, the client MUST protect it using the same technique (i.e., signature or MAC) as the starting message of the transaction. The CA MUST always sign it with a signature key.¶

5.3.22. Polling Request and Response

This pair of messages is intended to handle scenarios in which the client needs to poll the server to determine the status of an outstanding response (i.e., when the "waiting" PKIStatus has been received).¶

  PollReqContent ::= SEQUENCE OF SEQUENCE {
     certReqId    INTEGER }

  PollRepContent ::= SEQUENCE OF SEQUENCE {
     certReqId    INTEGER,
     checkAfter   INTEGER,  -- time in seconds
     reason       PKIFreeText OPTIONAL }

Unless implicit confirmation has been requested and granted, in response to an ir, cr, p10cr, kur, krr, or ccr request message, polling is initiated with an ip, cp, kup, krp, or ccp response message containing status "waiting". For any type of request message, polling can be initiated with an error response messages with status "waiting". The following clauses describe how polling messages are used. It is assumed that multiple certConf messages can be sent during transactions. There will be one sent in response to each ip, cp, kup, krp, or ccp that contains a CertStatus for an issued certificate.¶

1

In response to an ip, cp, kup, krp, or ccp message, an EE will send a certConf for all issued certificates and expect a PKIconf for each certConf. An EE will send a pollReq message in response to each CertResponse element of an ip, cp, or kup message with status "waiting" and in response to an error message with status "waiting". Its certReqId MUST be either the index of a CertResponse data structure with status "waiting" or -1 referring to the complete response.¶

2

In response to a pollReq, a CA/RA will return an ip, cp, kup, krp, or ccp if one or more of still pending requested certificates are ready or the final response to some other type of request is available; otherwise, it will return a pollRep.¶

3

If the EE receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq.¶

• [RFC-Editor: Please fix the indentation. This note belongs to 3.] Note that the checkAfter value heavily depends on the certificate management environment. There are different reasons for a delayed delivery of response messages possible, e.g., high load on the server's backend, offline transfer of messages between two PKI management entities, or required RA operator approval. Therefore, the checkAfter time can vary greatly. This should also be considered by the transfer protocol.¶

1. [RFC-Editor: Please fix the enumeration and continue with '4'.] If the EE receives an ip, cp, kup, krp, or ccp, then it will be treated in the same way as the initial response; if it receives any other response, then this will be treated as the final response to the original request.¶

The following client-side state machine describes polling for individual CertResponse elements at the example of an ir request message.¶

                            START
                              |
                              v
                           Send ir
                              | ip
                              v
                         Check status
                         of returned <------------------------+
                            certs                             |
                              |                               |
    +------------------------>|<------------------+           |
    |                         |                   |           |
    |        (issued)         v       (waiting)   |           |
  Add to <----------- Check CertResponse ------> Add to       |
 conf list           for each certificate      pending list   |
                             / \                              |
                            /   \                             |
               (conf list) /     \ (empty conf list)          |
                          /       \              ip           |
                         /         \        +-----------------+
   (empty pending list) /           \       |    pollRep
     END <---- Send certConf        Send pollReq---------->Wait
                      |                 ^   ^               |
                      |                 |   |               |
                      +-----------------+   +---------------+
                         (pending list)

In the following exchange, the end entity is enrolling for two certificates in one request.¶

Step# End Entity                       PKI
---------------------------------------------------------------------
  1   format ir
  2                    -> ir      ->
  3                                    handle ir
  4                                    manual intervention is
                                         required for both certs
  5                    <- ip      <-
  6   process ip
  7   format pollReq
  8                    -> pollReq  ->
  9                                    check status of cert requests,
                                         certificates not ready
 10                                    format pollRep
 11                    <- pollRep  <-
 12   wait
 13   format pollReq
 14                    -> pollReq  ->
 15                                    check status of cert requests,
                                         one certificate is ready
 16                                    format ip
 17                    <- ip       <-
 18   handle ip
 19   format certConf
 20                    -> certConf ->
 21                                    handle certConf
 22                                    format ack
 23                    <- pkiConf   <-
 24   format pollReq
 25                    -> pollReq  ->
 26                                    check status of certificate,
                                         certificate is ready
 27                                    format ip
 28                    <- ip       <-
 29   handle ip
 30   format certConf
 31                    -> certConf ->
 32                                    handle certConf
 33                                    format ack
 34                    <- pkiConf  <-

The following client-side state machine describes polling for a complete response message.¶

                                Start
                                  |
                                  | Send request
                                  |
             +----------- Receive response ------------+
             |                                         |
             | ip/cp/kup/krp/ccp/error with            | other
             | status "waiting"                        | response
             |                                         |
             v                                         |
 +------> Polling                                      |
 |           |                                         |
 |           | Send pollReq                            |
 |           | Receive response                        |
 |           |                                         |
 |   pollRep | other response                          |
 +-----------+------------------->+<-------------------+
                                  |
                                  v
                            Handle response
                                  |
                                  v
                                 End

In the following exchange, the end entity is sending a general message request, and the response is delayed by the server.¶

Step# End Entity                       PKI
---------------------------------------------------------------------
  1   format genm
  2                  -> genm     ->
  3                                 handle genm
  4                                 delay in response is necessary
  5                                 format error message "waiting"
                                      with certReqId set to -1
  6                   <- error   <-
  7   process error
  8   format pollReq
  9                   -> pollReq ->
 10                                 check status of original request,
                                      general message response not
                                      ready
 11                                 format pollRep
 12                   <- pollRep <-
 13   wait
 14   format pollReq
 15                   -> pollReq ->
 16                                 check status of original request,
                                      general message response is
                                      ready
 17                                 format genp
 18                   <- genp    <-
 19   handle genp

6.6.1. One-Way Request-Response Scheme:

The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross-certificates be created in "both directions", then each CA, in turn, must initiate a cross-certification operation (or use another scheme).¶

This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request.¶

Detailed Description:¶

Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on-line exchange.¶

The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged. (Authentication may alternatively be done using signatures instead of MACs, if the CAs are able to retrieve and validate the required public keys by some means, such as an out-of-band hash comparison.)¶

The requester CA initiates the exchange by generating a cross-certification request (ccr) with a fresh random number (requester random number). The requester CA then sends the ccr message to the responder CA. The fields in this message are protected from modification with a MAC based on the authorization code.¶

Upon receipt of the ccr message, the responder CA validates the message and the MAC, saves the requester random number, and generates its own random number (responder random number). It then generates (and archives, if desired) a new requester certificate that contains the requester CA public key and is signed with the responder CA signature private key. The responder CA responds with the cross certification response (ccp) message. The fields in this message are protected from modification with a MAC based on the authorization code.¶

Upon receipt of the ccp message, the requester CA validates the message (including the received random numbers) and the MAC. The requester CA responds with the certConf message. The fields in this message are protected from modification with a MAC based on the authorization code. The requester CA MAY write the requester certificate to the Repository as an aid to later certificate path construction.¶

Upon receipt of the certConf message, the responder CA validates the message and the MAC, and sends back an acknowledgement using the PKIConfirm message. It MAY also publish the requester certificate as an aid to later path construction.¶

Notes:¶

1. The ccr message must contain a "complete" certification request; that is, all fields except the serial number (including, e.g., a BasicConstraints extension) must be specified by the requester CA.¶

2. The ccp message SHOULD contain the verification certificate of the responder CA; if present, the requester CA must then verify this certificate (for example, via the "out-of-band" mechanism).¶

(A simpler, non-interactive model of cross-certification may also be envisioned, in which the issuing CA acquires the subject CA's public key from some repository, verifies it via some out-of-band mechanism, and creates and publishes the cross-certificate without the subject CA's explicit involvement. This model may be perfectly legitimate for many environments, but since it does not require any protocol message exchanges, its detailed description is outside the scope of this specification.)¶

6.7.1. Acquisition of PKI Information

The information REQUIRED is:¶

• the current root-CA public key¶

• (if the certifying CA is not a root-CA) the certification path from the root CA to the certifying CA together with appropriate revocation lists¶

• the algorithms and algorithm parameters that the certifying CA supports for each relevant usage¶

Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request that will be successful. However, for simplicity we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key, but the CA doesn't allow that).¶

The required information MAY be acquired as described in Section 6.5.¶

6.7.2. Out-of-Band Verification of Root-CA Key

An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate.¶

See Section 6.1 for further details.¶

7.1.1. Clients Talking to RFC 2510 Servers

If, after sending a message with a protocol version number higher than cmp1999, a client receives an ErrorMsgContent with a version of cmp1999, then it MUST abort the current transaction.¶

If a client receives a non-error PKIMessage with a version of cmp1999, then it MAY decide to continue the transaction (if the transaction hasn't finished) using RFC 2510 semantics. If it does not choose to do so and the transaction is not finished, then it MUST abort the transaction and send an ErrorMsgContent with a version of cmp1999.¶

7.1.2. Servers Receiving Version cmp1999 PKIMessages

If a server receives a version cmp1999 message it MAY revert to RFC 2510 behaviour and respond with version cmp1999 messages. If it does not choose to do so, then it MUST send back an ErrorMsgContent as described above in Section 7.¶