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.

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

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

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
    }

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
    }

5.3.14.  Certificate Announcement

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

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

        CertAnnContent ::= Certificate

5.3.15.  Revocation Announcement

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

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

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

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

5.3.16.  CRL Announcement

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

        CRLAnnContent ::= SEQUENCE OF CertificateList

5.3.17.  PKI Confirmation Content

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

        PKIConfirmContent ::= NULL

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

5.3.18.  Certificate Confirmation Content

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

         CertConfirmContent ::= SEQUENCE OF CertStatus

         CertStatus ::= SEQUENCE {
            certHash    OCTET STRING,
            certReqId   INTEGER,
            statusInfo  PKIStatusInfo OPTIONAL
         }

   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.

      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

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

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.

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.

                               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)

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

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".]

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

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

   Detailed Description:

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

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

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

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

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

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

   Notes:

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

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

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

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

   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.