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 CA (i.e., the entity that issues the certificate). An RA might also be involved in PKI management.¶

3.1.2.PKI Management Requirements

The protocols given here meet the following requirements on PKImanagement¶

1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 standards, in particular[X509.2019].¶

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 email, Hypertext Transfer Protocol (HTTP), Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), and various offline and non-networked file transfer methods.¶

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, seeSection 8.11) or a precertificate in a CT log[RFC9162], the certificate must be revoked if it was not accepted by the end entity or the POP could not be completed.¶

10. A graceful, scheduled changeover 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 TEE 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. SeeSection 4.3 for details of the in-band methods defined for the PKIX-CMP (i.e., CMP) messages.¶

3.1.3.PKI Management Operations

The following diagram shows the relationship between the entitiesdefined above in terms of the PKI management operations. The lettersin the diagram indicate "protocols" in the sense that a defined setof PKI management messages can be sent along each of the letteredlines.¶

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 and 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 Bootstrapping Remote Secure Key Infrastructure (BRSKI)[RFC8995] or Secure Zero Touch Provisioning (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.¶

   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 PKIXMAY involve the messages specified in Sections5.3.13 to5.3.16 orMAY involve other methods (for example, Lightweight Directory Access Protocol (LDAP)) 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 TEE:¶

   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. TEE operations: Whilst the definition of TEE operations (e.g., moving a TEE, 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 online protocols are not the only way of implementing theabove operations. For all operations, there are offline methods ofachieving the same result, and this specification does not mandateuse of online protocols. For example, when hardware tokens areused, many of the operationsMAY be achieved as part of the physicaltoken delivery.¶

Later sections define a set of standard messages supporting the aboveoperations. Transfer protocols for conveying these exchanges invarious environments (e.g., offline: file-based; online: email,HTTP[RFC9811], MQTT, and CoAP[RFC9482]) arebeyond the scope of this document and must be specified separately.Appropriate transfer protocolsMUST be capable of delivering the CMPmessages reliably.¶

CMP provides inbuilt integrity protection and authentication. The informationcommunicated unencrypted in CMP messages does not contain sensitiveinformation endangering the security of the PKI when intercepted. However,it might be possible for an eavesdropper to utilize the available information togather confidential technical or business-critical information. Therefore, usersshould consider protection of confidentiality on lower levels of the protocolstack, e.g., by using TLS[RFC8446], DTLS[RFC9147], or IPsec[RFC7296][RFC4303].¶

4.2.1.Criteria Used

4.2.2.Initial Registration/Certification Schemes

The criteria above allow for a large number of initialregistration/certification schemes. Examples of possible initialregistration/certification schemes can be found in the followingsubsections. An entity may support other schemes specified inprofiles of PKIX-CMP, such as AppendicesC andD or[RFC9483].¶

4.3.1.Signature Keys

For signature keys, the end entity can sign a value to provepossession of the private key; seeSection 5.2.8.2.¶

4.3.2.Encryption Keys

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

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

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

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

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 provethat the end entity has possession of the private key.¶

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

4.3.4.KEM Keys

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

Note: A definition of KEMs can be found inSection 1 of [RFC9629].¶

The direct method is for the RA/CA to issue a random challenge to which animmediate response by the end entity 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 requiresno 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 certificateSHALL use POPOPrivKey by using the keyEncipherment choice of ProofOfPossession (seeSection 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 or by the private key of some other CA (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 validityof the "old with old" certificate ended. However, the oldCA public key will remain in use for validating the "new with old"link certificate until the new CA public key is loaded into thetrusted store. The old CA public key is no longer required (otherthan for non-repudiation) when all end entities of this CA havesecurely acquired and stored the new CA public key.¶

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

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

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

Note: Further operational considerations on transition from one root CAself-signed certificate to the next is available inSection 5 of [RFC8649].¶

4.4.2.Verifying Certificates

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

4.4.3.Revocation - Change of the CA Key

As we saw above, the verification of a certificate becomes morecomplex once the CA is allowed to change its key. This is also truefor revocation checks, as the CA may have signed the CRL using a newerprivate key than the one within the user's TEE.¶

The analysis of the alternatives is the same as for certificateverification.¶

5.1.1.PKI Message Header

All PKI messages require some header information for addressing andtransaction identification. Some of this information will also bepresent in a transport-specific envelope. However, if the PKImessage 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 inSection 7.¶

The sender field contains the name of the sender of the PKIMessage.This name (in conjunction with senderKID, if supplied) should besufficient to indicate the key to use to verify the protection on themessage. If nothing about the sender is known to the sending entity(e.g., in the initial request message, where the end entity may not knowits own DN, email name, IP address, etc.), thenthe "sender" fieldMUST contain a "NULL-DN" value in the directoryName choice.A "NULL-DN" is a SEQUENCE OF relative DNs of zero length and is encoded as 0x3000.In such a case, the senderKID fieldMUST hold an identifier (i.e., a referencenumber) that indicates to the receiver the appropriate shared secretinformation to use to verify the message.¶

The recipient field contains the name of the recipient of thePKIMessage. 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 themessage. If no protection bits are supplied (note that PKIProtectionisOPTIONAL), then this fieldMUST be omitted; if protection bits aresupplied, then this fieldMUST be supplied.¶

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

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

The transactionID field within the message header is to be used toallow the recipient of a message to correlate this with an ongoingtransaction. This is needed for all transactions that consist ofmore than just a single request/response pair. For transactions thatconsist of a single request/response pair, the rules are as follows.A clientMUST populate the transactionID field if the messagecontains an infoValue of type KemCiphertextInfo (seeSection 5.1.3.4). In all other cases,the clientMAY populate the transactionID field of the request. If aserver receives such a request that has the transactionID field set,then itMUST set the transactionID field of the response to the samevalue. If a server receives such request with a missingtransactionID field, then itMUST populate the transactionID field ifthe message contains a KemCiphertextInfo field. In all other cases,the serverMAY set the transactionID field of the response.¶

For transactions that consist of more than just a singlerequest/response pair, the rules are as follows. If the messagecontains an infoValue of type KemCiphertextInfo, the clientMUST generate a transactionID; otherwise, the clientSHOULDgenerate a transactionID for the first request. If a server receivessuch a request that has the transactionID field set, then itMUST setthe transactionID field of the response to the same value. If aserver receives such request with a missing transactionID field, thenitMUST populate the transactionID field of the response with aserver-generated ID. Subsequent requests and responsesMUST all setthe transactionID field to the thus established value. In all caseswhere a transactionID is being used, a given clientMUST NOT havemore than one transaction with the same transactionID in progress atany time (to a given server). Servers are free to require uniquenessof the transactionID or not, as long as they are able to correctlyassociate 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, ifit cannot distinguish clients based on any transport-level information.A server receiving the first message of a transaction (which requiresmore than a single request/response pair) that contains atransactionID that does not allow it to meet the above constraints(typically because the transactionID is already in use)MUST sendback an ErrorMsgContent with a PKIFailureInfo of transactionIdInUse.It isRECOMMENDED that the clients fill the transactionID field with128 bits of (pseudo-)random data for the start of a transaction toreduce the probability of having the transactionID in use at theserver.¶

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

The messageTime field contains the time at which the sender createdthe message. This may be useful to allow end entities tocorrect/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 tothe recipient (in any number of languages). Each UTF8StringMAYinclude a language tag[RFC5646] to indicate the language of thecontained text. The first language used in this sequence indicatesthe desired language for replies.¶

The generalInfo field may be used to send machine-processableadditional data to the recipient. The following generalInfoextensions are defined andMAY 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 24 }  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 inSection 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 relevantpublic component has been certified already, then the origin of themessage can also be authenticated. On the other hand, if the publiccomponent is uncertified, then the message origin cannot beautomatically authenticated but may be authenticated via out-of-bandmeans.¶

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

  PKIProtection ::= BIT STRING

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

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

ThereMAY be cases in which the PKIProtection BIT STRING isdeliberately not used to protect a message (i.e., thisOPTIONAL fieldis omitted) because other protection, external to PKIX, will beapplied instead. Such a choice is explicitly allowed in thisspecification. Examples of such external protection include CMS[RFC5652] and Security Multiparts[RFC1847] encapsulation of thePKIMessage (or simply the PKIBody (omitting the CHOICE tag), if therelevant PKIHeader information is securely carried in the externalmechanism). It is noted, however, that many such external mechanismsrequire that the end entity already possesses a public-keycertificate, a unique DN, and/or other suchinfrastructure-related information. Thus, they may not beappropriate for initial registration, key-recovery, or any otherprocess with "bootstrapping" characteristics. For those cases, itmay be necessary that the PKIProtection parameter be used. In thefuture, if/when external mechanisms are modified to accommodatebootstrapping scenarios, the use of PKIProtection may become rare ornon-existent.¶

Depending on the circumstances, the PKIProtection bits may contain aMAC or signature. Only the followingcases 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 an OWF     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, {...}}  }

  NestedMessageContent ::= PKIMessages

5.2.1.Requested Certificate Contents

Various PKI management messages require that the originator of themessage indicate some of the fields that are required to be presentin a certificate. The CertTemplate structure allows entities requesting a certificate to specify the data fields that they want to be included. Typically, they are required to provide at least the publicKey field.A CertTemplate structure is identical to a TBSCertificate structure (see[RFC5280]) but with all fields optional/situational.¶

Note: Even if the originator completely specifies the contents ofa certificate it requires, a CA is free to modify fields within thecertificate actually issued. If the modified certificate isunacceptable to the requester, the requesterMUST send back acertConf message that either does not include this certificate (via aCertHash) or does include this certificate (via a CertHash) alongwith a status of "rejected". SeeSection 5.3.18 for the definitionand use of CertHash and the certConf message.¶

Note: Before requesting a new certificate, an end entity can request a certTemplatestructure as a kind of certificate request blueprint in order to learn whichdata the CA expects to be present in the certificate request (seeSection 5.3.19.16).¶

See CRMF[RFC4211] for CertTemplate syntax.¶

If certTemplate is an empty SEQUENCE (i.e., all fields omitted), then thecontrols field in the CertRequest structureMAY contain the id-regCtrl-altCertTemplatecontrol, specifying a template for a certificate other than an X.509v3 public-keycertificate. Conversely, if certTemplate is not empty (i.e., at least onefield is present), then controlsMUST 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

Also see[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 isRECOMMENDED 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 thechoice to either use EncryptedValue (for backward compatibility only) orEnvelopedData. The use of the EncryptedValue structure has been deprecatedin favor of the EnvelopedData structure. Therefore, it isRECOMMENDED touse EnvelopedData.¶

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

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

The EnvelopedData structure isRECOMMENDED to be used 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 encryptedonly for one recipient.¶

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

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

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

The choice of the key management technique to be used by the sender dependson 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 inSection 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 inSection 6.2.2 of [RFC5652].¶

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

• recipient's certificate with an algorithm identifier and a public key that supports KEM 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 managementtechnique to use, e.g., when rsaEncryption is the algorithm identifier. Insuch 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. Thefollowing 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 informationabout 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 datastructure is used.¶

See[RFC4211] for CertId syntax.¶

5.2.5.Out-of-Band Root CA Public Key

Each root CA that provides a self-signed certificate 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 ofthis document, we define data structures that can support suchmechanisms.¶

There are generally two methods available: Either the CA directlypublishes its self-signed certificate, or this information isavailable via the directory (or equivalent) and the CA publishes ahash 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 certificateMUST be self-signed (i.e., the signature must beverifiable using the SubjectPublicKeyInfo field);¶

• The subject and issuer fieldsMUST be identical;¶

• If the subject field contains a "NULL-DN", then both subjectAltNames andissuerAltNames extensionsMUST be present and have exactly thesame value; and¶

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

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

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

5.2.6.Archive Options

Requesters may indicate that they wish the PKI to archive a privatekey 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 acertificate using the PKIPublicationInfo structure.¶

See[RFC4211] for PKIPublicationInfo syntax.¶

5.2.8.POP Structures

The POP structure used is indicated in the popo fieldof type ProofOfPossession in the CertReqMsg sequence (seeSection 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)   }

   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

5.2.9.GeneralizedTime

GeneralizedTime is a standard ASN.1 type andSHALL be used as specified inSection 4.1.2.5.2 of [RFC5280].¶

5.3.1.Initialization Request

An Initialization request message contains as the PKIBody aCertReqMessages data structure, which specifies the requestedcertificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validityare the template fields that may be supplied for each certificaterequested (see the profiles defined inSection 4.1.1 of [RFC9483] and AppendicesC.4andD.7 for further information). Thismessage is intended to be used for entities when first initializinginto the PKI.¶

SeeSection 5.2.1 and[RFC4211] for CertReqMessages syntax.¶

5.3.2.Initialization Response

An Initialization response message contains as the PKIBody aCertRepMessage data structure, which has for each certificaterequested a PKIStatusInfo field, a subject certificate, and possiblya private key (normally encrypted using EnvelopedData; seeSection 4.1.6 of [RFC9483] for further information).¶

SeeSection 5.3.4 for CertRepMessage syntax. Note that if the PKImessage protection is "shared secret information" (seeSection 5.1.3.1),then any certificate transported in the caPubs field may bedirectly trusted as a root CA certificate by the initiator.¶

5.3.3.Certification Request

A Certification request message contains as the PKIBody aCertReqMessages data structure, which specifies the requestedcertificates (see the profiles defined inSection 4.1.2 of [RFC9483] andAppendix C.2for further information). This message is intended to be used for existing PKIentities who wish to obtain additional certificates.¶

SeeSection 5.2.1 and[RFC4211] for CertReqMessages syntax.¶

Alternatively, the PKIBodyMAY be a CertificationRequest (thisstructure is fully specified by the ASN.1 structureCertificationRequest given in[RFC2986]; see the profiles defined inSection 4.1.4 of [RFC9483] for further information).This structure may berequired for certificate requests for signing key pairs wheninteroperation with legacy systems is desired, but its use isstrongly discouraged whenever not absolutely necessary.¶

5.3.4.Certification Response

A Certification response message contains as the PKIBody aCertRepMessage data structure, which has a status value for eachcertificate requested and optionally has a CA public key, failureinformation, 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 CertificationResponse (cp) messageMUST be set to -1.¶

Only one of the failInfo (in PKIStatusInfo) and certificate (inCertifiedKeyPair) 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, thecertificate may be obtained. The purpose of this is to allow a CA toreturn the value of a certificate but with the constraint that onlythe intended recipient can obtain the actual certificate. Thebenefit of this approach is that a CA may reply with a certificateeven in the absence of proof that the requester is the end entitythat can use the relevant private key (note that the proof is notobtained until the certConf message is received by the CA). Thus,the CA will not have to revoke that certificate in the event thatsomething goes wrong with the POP (butMAY do soanyway, depending upon policy).¶

The use of EncryptedKey is described inSection 5.2.2.¶

Note: To indicate support for EnvelopedData, the pvno cmp2021 has beenintroduced. Details on the usage of different protocol versionnumbers are described inSection 7.¶

5.3.5.Key Update Request Content

For key update requests, the CertReqMessages syntax is used.Typically, SubjectPublicKeyInfo, KeyId, and Validity are the templatefields that may be supplied for each key to be updated (see the profilesdefined inSection 4.1.3 of [RFC9483] andAppendix C.6 for further information).This messageis intended to be used to request updates to existing (non-revokedand non-expired) certificates (therefore, it is sometimes referred toas a "Certificate Update" operation). An update is a replacementcertificate containing either a new subject public key or the currentsubject public key (although the latter practice may not beappropriate 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. Theresponse is identical to the initialization response.¶

SeeSection 5.3.4 for CertRepMessage syntax.¶

5.3.7.Key Recovery Request Content

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

SeeSection 5.2.1 and[RFC4211] for CertReqMessages syntax. Note that if akey history is required, the requester must supply a protocolencryption key control in the request message.¶

5.3.8.Key Recovery Response Content

For key recovery responses, the following syntax is used. For somestatus values (e.g., waiting), none of the optional fields will bepresent.¶

  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 severalcertificates), the following data structure is used (see the profiles definedinSection 4.2 of [RFC9483] for further information). The name of therequester 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. Ifproduced, this is sent to the requester of the revocation. (Aseparate revocation announcement messageMAY be sent to the subjectof 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) asnormal certification requests, with the restriction that the key pairMUST have been generated by the requesting CA and the private keyMUST NOT be sent to the responding CA (see the profiles defined inAppendix D.6for further information). This requestMAY also be usedby subordinate CAs to get their certificates signed by the parent CA.¶

SeeSection 5.2.1 and[RFC4211] for CertReqMessages syntax.¶

5.3.12.Cross-Certification Response Content

Cross-certification responses use the same syntax (CertRepMessage) asnormal certification responses, with the restriction that noencrypted private key can be sent.¶

SeeSection 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 structureMAYbe 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 cmp2021MUST be used. Details on the usage of the protocol version number are described inSection 7.¶

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

5.3.14.Certificate Announcement

This structureMAY be used to announce the existence of certificates.¶

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

  CertAnnContent ::= Certificate

5.3.15.Revocation Announcement

When a CA has revoked, or is about to revoke, a particularcertificate, itMAY issue an announcement of this (possibly upcoming)event.¶

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

A CAMAY use such an announcement to warn (or notify) a subject thatits certificate is about to be (or has been) revoked. This wouldtypically be used where the request for revocation did not come fromthe subject concerned.¶

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

5.3.16.CRL Announcement

When a CA issues a new CRL (or set of CRLs), the following datastructureMAY 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 finalPKIMessage. Its content is the same in all cases -- actually, thereis no content since the PKIHeader carries all the requiredinformation.¶

  PKIConfirmContent ::= NULL

Use of this message for certificate confirmation isNOT RECOMMENDED;certConfSHOULD be used instead. Upon receiving a pkiconf for acertificate response, the recipientMAY treat it as a certConf withall certificates being accepted.¶

5.3.18.Certificate Confirmation Content

This data structure is used by the client to send a confirmation tothe 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 fieldSHOULD be used only in exceptional cases where the signatureAlgorithmof the certificate to be confirmed does not specify a hash algorithm in theOID 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 inSection 3.3 of [RFC9481], such that the hashAlg field is not needed for EdDSA. Otherwise, the certHash valueSHALL be computed using the same hash algorithm as used to create and verifythe certificate signature or as specified for hashing certificates signed using the signatureAlgorithm. If hashAlg is used, the CMP version indicatedby the certConf message header must be cmp2021(3).¶

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

Within CertConfirmContent, omission of a CertStatus structurecorresponding to a certificate supplied in the previous responsemessage indicates rejection of the certificate. Thus, an emptyCertConfirmContent (a zero-length SEQUENCE)MAY be used to indicaterejection of all supplied certificates. SeeSection 5.2.8.3.2for a discussion of the certHash field with respect toPOP.¶

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 24}, < absent >  GenRep:    {id-it 24}, KemCiphertextInfo

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

5.3.20.PKI General Response Content

  GenRepContent ::= SEQUENCE OF InfoTypeAndValue

Examples of GenReps thatMAY be supported include those listed in thesubsections ofSection 5.3.19.¶

5.3.21.Error Message Content

This data structureMAY be used by an end entity, CA, or RA to convey error information andby a PKI management entity to initiate delayed delivery of responses.¶

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

This messageMAY be generated at any time during a PKI transaction. If theclient sends this request, the serverMUST respond with a pkiconf responseor another error message if any part of the header is not valid.¶

In case a PKI management entity sends an error message to the end entity with thepKIStatusInfo field containing the status "waiting", the end entitySHOULD initiatepolling as described inSection 5.3.22.If the end entity does not initiate polling, both sidesMUST treat this messageas the end of the transaction (if a transaction is in progress).¶

If protection is desired on the message, the clientMUST protect itusing the same technique (i.e., signature or MAC) as the startingmessage of the transaction. The CAMUST always sign it with asignature key.¶

5.3.22.Polling Request and Response

This pair of messages is intended to handle scenarios in which the clientneeds 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 initiatedwith an ip, cp, kup, krp, or ccp response message containing status "waiting". Forany type of request message, polling can be initiated with an error responsemessage with status "waiting". The following clauses describe how pollingmessages are used. It is assumed that multiple certConf messages can besent 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 end entity will send a certConf for all issued certificates and expect a pkiconf for each certConf. An end entity 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 certReqIdMUST 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 the 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 end entity receives a pollRep, it will wait for at least the number of seconds given in the checkAfter field before sending another pollReq.¶

   Note that the checkAfter value heavily depends on the certificate management environment. There are different possible reasons for a delayed delivery of response messages, 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.¶

4. If the end entity 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 individualCertResponse elements at the example of an ir request message.¶

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

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

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

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 ofone new cross-certificate. If the requirement is that cross-certificatesbe created in "both directions", then each CA, in turn,must initiate a cross-certification operation (or use anotherscheme).¶

This scheme is suitable where the two CAs in question can alreadyverify each other's signatures (they have some common points oftrust) or where there is an out-of-band verification of the origin ofthe 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 tocross-certify and the responder CA equipment generates anauthorization code. The responder CA administrator passes thisauthorization code by out-of-band means to the requester CAadministrator. The requester CA administrator enters theauthorization code at the requester CA in order to initiate theonline exchange.¶

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

The requester CA initiates the exchange by generating a cross-certificationrequest (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 aMAC based on the authorization code.¶

Upon receipt of the ccr message, the responder CA validates themessage and the MAC, saves the requester random number, and generatesits own random number (responder random number). It then generates(and archives, if desired) a new requester certificate that containsthe requester CA public key and is signed with the responder CAsignature private key. The responder CA responds with the cross-certification response (ccp) message. The fields in this message areprotected from modification with a MAC based on the authorizationcode.¶

Upon receipt of the ccp message, the requester CA validates themessage (including the received random numbers) and the MAC. Therequester CA responds with the certConf message. The fields in thismessage are protected from modification with a MAC based on theauthorization code. The requester CAMAY write the requestercertificate to the Repository as an aid to later certificate pathconstruction.¶

Upon receipt of the certConf message, the responder CA validates themessage and the MAC and sends back an acknowledgement using thepkiconf message. ItMAY also publish the requester certificate asan 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 messageSHOULD 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 beenvisioned, in which the issuing CA acquires the subject CA's publickey from some repository, verifies it via some out-of-band mechanism,and creates and publishes the cross-certificate without the subjectCA's explicit involvement. This model may be perfectly legitimatefor many environments, but since it does not require any protocolmessage exchanges, its detailed description is outside the scope ofthis specification.)¶

6.7.1.Acquisition of PKI Information

The informationREQUIRED is:¶

• the current root-CA public key¶

• (if the certifying CA is not a root-CA) the certification pathfrom the root CA to the certifying CA together with appropriaterevocation lists¶

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

Additional information could be required (e.g., supported extensionsor CA policy information) in order to produce a certification requestthat will be successful. However, for simplicity, we do not mandatethat 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 informationMAY be acquired as described inSection 6.5.¶

6.7.2.Out-of-Band Verification of the 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'sself-certificate fingerprint via some secure "out-of-band" means.The end entity can then securely use the CA's self-certificate.¶

SeeSection 6.1 for further details.¶

7.1.1.Clients Talking to RFC 2510 Servers

If, after sending a message with a pvno value higher than cmp1999, a client receives an ErrorMsgContent with a version of cmp1999, then itMUSTabort the current transaction.¶

If a client receives a non-error PKIMessage with a version ofcmp1999, then itMAY decide to continue the transaction (if thetransaction hasn't finished) using the semantics described in[RFC2510]. If it doesnot choose to do so and the transaction is not finished, then itMUSTabort the transaction and send an ErrorMsgContent with a version ofcmp1999.¶

7.1.2.Servers Receiving Version cmp1999 PKIMessages

If a server receives a version cmp1999 message, itMAY revert to the behavior described in[RFC2510] and respond with version cmp1999 messages. If it doesnot choose to do so, then itMUST send back an ErrorMsgContent asdescribed above inSection 7.¶