Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4210

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

Pages: 95
Proposed Standard
Errata
Obsoletes:  2510
Updated by:  6712
Part 3 of 5 – Pages 38 to 55
First   Prev   Next

Top   ToC   RFC4210 - Page 38   prevText

5.3. Operation-Specific Data Structures

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 Appendix D profiles for further information). This message is intended to be used for entities when first initializing into the PKI. See Appendix C and [CRMF] for CertReqMessages syntax.
Top   ToC   RFC4210 - Page 39

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 with a session key, which is itself encrypted with the protocolEncrKey). 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. This message is intended to be used for existing PKI entities who wish to obtain additional certificates. See Appendix C and [CRMF] for CertReqMessages syntax. Alternatively, the PKIBody MAY be a CertificationRequest (this structure is fully specified by the ASN.1 structure CertificationRequest given in [PKCS10]). 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 Certificate 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
Top   ToC   RFC4210 - Page 40
         -- for regInfo in CertReqMsg [CRMF]
     }

     CertifiedKeyPair ::= SEQUENCE {
         certOrEncCert       CertOrEncCert,
         privateKey      [0] EncryptedValue      OPTIONAL,
         -- see [CRMF] for comment on encoding
         publicationInfo [1] PKIPublicationInfo  OPTIONAL
     }

     CertOrEncCert ::= CHOICE {
         certificate     [0] Certificate,
         encryptedCert   [1] EncryptedValue
     }

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

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. This message is intended to be used to request updates to existing (non-revoked and non-expired) certificates (therefore, it is sometimes referred to as a "Certificate Update" operation). An update is a replacement certificate containing either a new subject public key or the current subject public key (although the latter practice may not be appropriate for some environments). See Appendix C and [CRMF] for CertReqMessages syntax.
Top   ToC   RFC4210 - Page 41

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 D profiles for further information). See Appendix C and [CRMF] 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. The name of the requester is present in the PKIHeader structure. RevReqContent ::= SEQUENCE OF RevDetails RevDetails ::= SEQUENCE { certDetails CertTemplate, crlEntryDetails Extensions OPTIONAL }
Top   ToC   RFC4210 - Page 42

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. This request MAY also be used by subordinate CAs to get their certificates signed by the parent CA. See Appendix C and [CRMF] 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 }
Top   ToC   RFC4210 - Page 43

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
Top   ToC   RFC4210 - Page 44
   Use of this message for certificate confirmation is NOT RECOMMENDED;
   certConf SHOULD be used instead.  Upon receiving a PKIConfirm for a
   certificate response, the recipient MAY treat it as a certConf with
   all certificates being accepted.

5.3.18. Certificate Confirmation Content

This data structure is used by the client to send a confirmation to the CA/RA to accept or reject certificates. CertConfirmContent ::= SEQUENCE OF CertStatus CertStatus ::= SEQUENCE { certHash OCTET STRING, certReqId INTEGER, statusInfo PKIStatusInfo OPTIONAL } 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
5.3.19.1. CA Protocol Encryption Certificate
This MAY be used by the EE to get a certificate from the CA to use to protect sensitive information during the protocol.
Top   ToC   RFC4210 - Page 45
      GenMsg:    {id-it 1}, < absent >
      GenRep:    {id-it 1}, Certificate | < absent >

   EEs MUST ensure that the correct certificate is used for this
   purpose.

5.3.19.2. Signing Key Pair Types
This MAY be used by the EE to get the list of signature algorithms (e.g., RSA, DSA) whose subject public key values the CA is willing to certify. Note that for the purposes of this exchange, rsaEncryption and rsaWithSHA1, for example, are considered to be equivalent; the question being asked is, "Is the CA willing to certify an RSA public key?" GenMsg: {id-it 2}, < absent > GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
5.3.19.3. Encryption/Key Agreement Key Pair Types
This MAY be used by the client to get the list of encryption/key agreement algorithms whose subject public key values the CA is willing to certify. GenMsg: {id-it 3}, < absent > GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF AlgorithmIdentifier
5.3.19.4. Preferred Symmetric Algorithm
This MAY be used by the client to get the CA-preferred symmetric encryption algorithm for any confidential information that needs to be exchanged between the EE and the CA (for example, if the EE wants to send its private decryption key to the CA for archival purposes). GenMsg: {id-it 4}, < absent > GenRep: {id-it 4}, AlgorithmIdentifier
5.3.19.5. Updated CA Key Pair
This MAY be used by the CA to announce a CA key update event. GenMsg: {id-it 5}, CAKeyUpdAnnContent
Top   ToC   RFC4210 - Page 46
5.3.19.6. CRL
This MAY be used by the client to get a copy of the latest CRL. GenMsg: {id-it 6}, < absent > GenRep: {id-it 6}, CertificateList
5.3.19.7. Unsupported Object Identifiers
This is used by the server to return a list of object identifiers that it does not recognize or support from the list submitted by the client. GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
5.3.19.8. Key Pair Parameters
This MAY be used by the EE to request the domain parameters to use for generating the key pair for certain public-key algorithms. It can be used, for example, to request the appropriate P, Q, and G to generate the DH/DSA key, or to request a set of well-known elliptic curves. GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id) GenRep: {id-it 11}, AlgorithmIdentifier | < absent > An absent infoValue in the GenRep indicates that the algorithm specified in GenMsg is not supported. EEs MUST ensure that the parameters are acceptable to it and that the GenRep message is authenticated (to avoid substitution attacks).
5.3.19.9. Revocation Passphrase
This MAY be used by the EE to send a passphrase to a CA/RA for the purpose of authenticating a later revocation request (in the case that the appropriate signing private key is no longer available to authenticate the request). See Appendix B for further details on the use of this mechanism. GenMsg: {id-it 12}, EncryptedValue GenRep: {id-it 12}, < absent >
5.3.19.10. ImplicitConfirm
See Section 5.1.1.1 for the definition and use of {id-it 13}.
Top   ToC   RFC4210 - Page 47
5.3.19.11. ConfirmWaitTime
See Section 5.1.1.2 for the definition and use of {id-it 14}.
5.3.19.12 Original PKIMessage
See Section 5.1.3 for the definition and use of {id-it 15}.
5.3.19.13. Supported Language Tags
This MAY be used to determine the appropriate language tag to use in subsequent messages. The sender sends its list of supported languages (in order, most preferred to least); the receiver returns the one it wishes to use. (Note: each UTF8String MUST include a language tag.) If none of the offered tags are supported, an error MUST be returned. GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String

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. 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. 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.
Top   ToC   RFC4210 - Page 48

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 in order to determine the status of an outstanding ir, cr, or kur transaction (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 } The following clauses describe when polling messages are used, and how they 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, following the ack, a pollReq for all pending certificates. 2. In response to a pollReq, a CA/RA will return an ip, cp, or kup if one or more of the pending certificates is ready; otherwise, it will return a pollRep. 3. If the EE receives a pollRep, it will wait for at least as long as the checkAfter value before sending another pollReq. 4. If an ip, cp, or kup is received in response to a pollReq, then it will be treated in the same way as the initial response.
Top   ToC   RFC4210 - Page 49
                               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)  /                  |    pRep
        END <---- Send certConf         Send pReq------------>Wait
                         |                 ^   ^               |
                         |                 |   |               |
                         +-----------------+   +---------------+
                            (pending list)
Top   ToC   RFC4210 - Page 50
   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 pReq
    8                    -> pReq     ->
    9                                    Check status of cert requests
    10                                   Certificates not ready
    11                                   Format pRep
    12                   <- pRep     <-
    13  Wait
    14  Format pReq
    15                   -> pReq     ->
    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 pReq
    27                   -> pReq     ->
    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  <-
Top   ToC   RFC4210 - Page 51

6. Mandatory PKI Management Functions

Some of the PKI management functions outlined in Section 3.1 above are described in this section. This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described. This part is effectively the profile of the PKI management functionality that MUST be supported. Note, however, that the management functions described in this section do not need to be accomplished using the PKI messages defined in Section 5 if alternate means are suitable for a given environment (see Appendix D for profiles of the PKIMessages that MUST be supported).

6.1. Root CA Initialization

[See Section 3.1.1.2 for this document's definition of "root CA".] A newly created root CA must produce a "self-certificate", which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update. In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its certificate. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and, hence, the other attributes contained therein. The data structure used to carry the fingerprint is the OOBCertHash.

6.2. Root CA Key Update

CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 4.4.1) MAY be issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self- signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.

6.3. Subordinate CA Initialization

[See Section 3.1.1.2 for this document's definition of "subordinate CA".]
Top   ToC   RFC4210 - Page 52
   From the perspective of PKI management protocols, the initialization
   of a subordinate CA is the same as the initialization of an end
   entity.  The only difference is that the subordinate CA must also
   produce an initial revocation list.

6.4. CRL production

Before issuing any certificates, a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which are to be periodically produced.

6.5. PKI Information Request

When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA, it MAY send that CA a request for such information. The CA MUST respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided, then an error must be conveyed to the requester. If PKIMessages are used to request and supply this PKI information, then the request MUST be the GenMsg message, the response MUST be the GenRep message, and the error MUST be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or using any other authenticated means (if the end entity has an existing certificate).

6.6. Cross Certification

The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate. The requester CA must be "up and running" before initiating the cross-certification operation.

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).
Top   ToC   RFC4210 - Page 53
   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.
Top   ToC   RFC4210 - Page 54
   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. End Entity Initialization

As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps: o acquisition of PKI information o out-of-band verification of one root-CA public key (other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys).

6.7.1. Acquisition of PKI Information

The information REQUIRED is: o the current root-CA public key o (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
Top   ToC   RFC4210 - Page 55
   o  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.

6.8. Certificate Request

An initialized end entity MAY request an additional certificate at any time (for any purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.

6.9. Key Update

When a key pair is due to expire, the relevant end entity MAY request a key update; that is, it MAY request that the CA issue a new certificate for a new key pair (or, in certain circumstances, a new certificate for the same key pair). The request is made using a key update request (kur) message (referred to, in some environments, as a "Certificate Update" operation). If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.