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 [RFCCCCC]. 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, by an RA, 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, RA, 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, TCP/IP, 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, 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 indirect POP is completed (typically through use of the certConf message). In case of publication of the certificate or a precertificate in a Certificate Transparency log [RFC9162], the certificate must be revoked if it was not accepted or the indirect 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) must also be able to verify certificates verifiable using the old public key. End entities who directly trust the old CA key pair must also 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 protect 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 public 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, 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.¶

      1. 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.¶
      2. 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.¶
      3. Note 3. Issuance of cross-certificates may be, but is not necessarily, mutual; that is, two CAs may issue cross-certificates for each other.¶
   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 it is 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 [RFC4510], [RFC4510] (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. Transport protocols for conveying these exchanges in different environments (e.g., off-line: file-based, on-line: mail, HTTP [RFCDDDD], and CoAP [RFCEEEE]) are beyond the scope of this document and are specified separately.¶

4.2.1. Criteria Used

4.2.2. Mandatory Schemes

The criteria above allow for a large number of initial registration/certification schemes. This specification mandates that conforming CA equipment, RA equipment, and EE equipment MUST support the second scheme listed below (Section 4.2.2.2). Any entity MAY additionally support other schemes, if desired.¶

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

4.3.2. Encryption Keys

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

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 keys, the end entity can be required to decrypt a value in order to prove possession of the private key (see Section 5.2.8). Decrypting a value can be achieved either directly or indirectly.¶

Note: A definition of Key Encapsulation Mechanisms can be found in [I-D.ietf-lamps-cms-kemri], 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).¶

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 old CA public key signed with the new private key (the "old with new" certificate);¶
3. Create a certificate containing the new CA public key signed with the old private key (the "new with old" certificate);¶
4. Create a certificate containing the new CA public key signed with the new private key (the "new with new" certificate);¶
5. Publish these new certificates via the repository and/or other means (perhaps using a CAKeyUpdAnn message or RootCaKeyUpdateContent);¶
6. Export the new CA public key so that end entities may acquire it using the "out-of-band" mechanism (if required).¶

The old CA private key is then no longer required. However, the old CA public key will remain in use for some time. The old CA public key is no longer required (other than for non-repudiation) when all end entities of this CA have securely acquired the new CA public key.¶

The "old with new" certificate must have a validity period with the same notBefore and notAfter time as the "old with old" 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 "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.¶

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

             Repository contains NEW    Repository contains only OLD
               and OLD public keys       public key (due to, e.g.,
                                           delay in publication)
                PSE      PSE Contains  PSE Contains    PSE Contains
             Contains     OLD public    NEW public      OLD public
            NEW public       key            key            key
                key

 Signer's   Case 1:      Case 3:       Case 5:        Case 7:
 certifi-   This is      In this case  Although the   In this case
 cate is    the          the verifier  CA operator    the CA
 protected  standard     must access   has not        operator  has
 using NEW  case where   the           updated the    not updated
 key pair   the          repository in repository the the repository
            verifier     order to get  verifier can   and so the
            can          the value of  verify the     verification
            directly     the NEW       certificate    will FAIL
            verify the   public key    directly -
            certificate                this is thus
            without                    the same as
            using the                  case 1.
            repository

 Signer's   Case 2:      Case 4:       Case 6:        Case 8:
 certifi-   In this      In this case  The verifier   Although the
 cate is    case the     the verifier  thinks this    CA operator
 protected  verifier     can directly  is the         has not
 using OLD  must         verify the    situation of   updated the
 key pair   access the   certificate   case 2 and     repository the
            repository   without       will access    verifier can
            in order     using the     the            verify the
            to get the   repository    repository;    certificate
            value of                   however, the   directly -
            the OLD                    verification   this is thus
            public key                 will FAIL      the same as
                                                      case 4.

Note: Instead of using a repository, the end entity can use the root CA update general message to request the respective certificates from a PKI management entity, see Section 5.3.19.15, and follow the required validation steps.¶

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 pvno values 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 init. req. 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" value; that is, the SEQUENCE OF relative distinguished names is of zero length. 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 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 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. Clients 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 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

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] CAKeyUpdAnnContent,    --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-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 TBD4}

  KemBMParameter ::= SEQUENCE {
    kdf              AlgorithmIdentifier{KEY-DERIVATION, {...}},
    len              INTEGER (1..MAX),
    mac              AlgorithmIdentifier{MAC-ALGORITHM, {...}}
  }

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

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

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

5.2.2. Encrypted Values

Where encrypted data (in this specification, private keys, certificates, or revocation passphrase) are sent in PKI messages, the EncryptedKey data structure is used.¶

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

See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and 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 pvno values is described in Section 7.¶

The EncryptedKey data structure is used in CMP to transport a private key, certificate, or revocation passphrase in encrypted form.¶

EnvelopedData is used 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 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure as specified in CMS section 5 [RFC5652] and [RFC8933] signed by the Key Generation Authority.¶
• It may contain a certificate or revocation passphrase directly in the encryptedContent field.¶

The content of the EnvelopedData structure, as specified in CMS section 6 [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 three 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 CMS Section 6.2.1 [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 CMS Section 6.2.2 [RFC5652]. This is the preferred technique.¶
• A password or shared secret: The content-encryption key will be protected using the password-based key management technique, as specified in CMS Section 6.2.4 [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 additional key management technique for KEM keys, as specified in [I-D.ietf-lamps-cms-kemri].¶

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

  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 is NULL, 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

< ToDo: This section should be aligned with Section 4.3 of this document and RFC 4211 Section 4. It should potentially be restructured and updated for better readability. Also some inconsistencies in Section 5.2.8.3 resulting from the update of RFC2510 to RFC4210 should be fixed. >¶

If the certification request is for a key pair that supports signing , then the proof-of-possession of the private signing key is demonstrated through use of the POPOSigningKey structure as defined in RFC 4211 [RFC4211].¶

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

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

The signature (using "algorithmIdentifier") is on the DER-encoded value of poposkInput (i.e., the "value" OCTETs of the POPOSigningKeyInput DER).¶

If certTemplate (or the altCertTemplate control as defined in Section 5.2.1) contains the subject and publicKey values, then poposkInput MUST be omitted and the signature MUST be computed on the DER-encoded value of certReq field if the CertReqMsg (or the DER-encoded value of AltCertTemplate). If certTemplate/altCertTemplate does not contain both the subject and public key values (i.e., if it contains only one of these, or neither), then poposkInput MUST be present and MUST be signed.¶

On the other hand, if the certification request is for a key pair that does not support signing (i.e., a request for an encryption or KEM certificate), then the proof-of-possession of the private decryption key may be demonstrated in one of three ways, as detailed in the following subsections.¶

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

                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
  }

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

  POPODecKeyRespContent ::= SEQUENCE OF INTEGER

   RAVerified;
   SKPOP;
   EKPOPThisMessage;
   KAKPOPThisMessage;
   KAKPOPThisMessageDHMAC;
   EKPOPEncryptedCert;
   KAKPOPEncryptedCert;
   EKPOPChallengeResp; and
   KAKPOPChallengeResp.

5.2.9. GeneralizedTime

GeneralizedTime is a standard ASN.1 type and SHALL be used as specified in RFC 5280 Section 4.1.2.5.2 [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 [RFCBBBB] 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 an 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 [RFCBBBB] 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), 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 [RFCBBBB] 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 [RFCBBBB] 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 comment 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 is introduced by this document. Details on the usage of different pvno values 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 [RFCBBBB] 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).¶

SeeSection 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 Appendix C profiles for further information).¶

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

  CAKeyUpdAnnContent ::= SEQUENCE {
     oldWithNew         Certificate,
     newWithOld         Certificate,
     newWithNew         Certificate
  }

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

  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 does not define a hash algorithm to use with CMP, e.g., for EdDSA in [RFCCCCC] Section 3.3). Otherwise, the certHash value SHALL be computed using the same hash algorithm as used to create and verify the certificate signature. 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, item (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 5}, CAKeyUpdAnnContent

  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}, RootCaKeyUpdateContent | < 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 }

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 info 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 }

In response to an ir, cr, p10cr, or kur request message, polling is initiated with an ip, cp, or kup 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, or kup that contains a CertStatus for an issued certificate.¶

1

In response to an ip, cp, or kup 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, or kup 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.¶

4

If the EE receives an ip, cp, or kup, 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.¶

                            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
 10                                   Certificates not ready
 11                                   Format pollRep
 12                   <- pollRep  <-
 13  Wait
 14  Format pollReq
 15                   -> pollReq  ->
 16                                   Check status of cert requests
 17                                   One certificate is ready
 18                                   Format ip
 19                   <- ip       <-
 20  Handle ip
 21  Format certConf
 22                   -> certConf ->
 23                                   Handle certConf
 24                                   Format ack
 25                   <- pkiConf   <-
 26  Format pollReq
 27                   -> pollReq  ->
 28                                   Check status of certificate
 29                                   Certificate is ready
 30                                   Format ip
 31                   <- ip       <-
 31  Handle ip
 32  Format certConf
 33                   -> certConf ->
 34                                   Handle certConf
 35                                   Format ack
 36                   <- pkiConf  <-

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

                                Start
                                  |
                                  | Send request
                                  |
             +----------- Receive response ------------+
             |                                         |
             | ip/cp/kup/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.¶