tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4210

 
 
 

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

Part 2 of 5, p. 14 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 14 
4.  Assumptions and Restrictions

4.1.  End Entity Initialization

   The first step for an end entity in dealing with PKI management
   entities is to request information about the PKI functions supported
   and to securely acquire a copy of the relevant root CA public key(s).

4.2.  Initial Registration/Certification

   There are many schemes that can be used to achieve initial
   registration and certification of end entities.  No one method is
   suitable for all situations due to the range of policies that a CA
   may implement and the variation in the types of end entity which can
   occur.

   However, we can classify the initial registration/certification
   schemes that are supported by this specification.  Note that the word
   "initial", above, is crucial: we are dealing with the situation where
   the end entity in question has had no previous contact with the PKI.
   Where the end entity already possesses certified keys, then some
   simplifications/alternatives are possible.

   Having classified the schemes that are supported by this
   specification we can then specify some as mandatory and some as
   optional.  The goal is that the mandatory schemes cover a sufficient
   number of the cases that will arise in real use, whilst the optional
   schemes are available for special cases that arise less frequently.
   In this way, we achieve a balance between flexibility and ease of
   implementation.

   We will now describe the classification of initial
   registration/certification schemes.

Top      Up      ToC       Page 15 
4.2.1.  Criteria Used

4.2.1.1.  Initiation of Registration/Certification

   In terms of the PKI messages that are produced, we can regard the
   initiation of the initial registration/certification exchanges as
   occurring wherever the first PKI message relating to the end entity
   is produced.  Note that the real-world initiation of the
   registration/certification procedure may occur elsewhere (e.g., a
   personnel department may telephone an RA operator).

   The possible locations are at the end entity, an RA, or a CA.

4.2.1.2.  End Entity Message Origin Authentication

   The on-line messages produced by the end entity that requires a
   certificate may be authenticated or not.  The requirement here is to
   authenticate the origin of any messages from the end entity to the
   PKI (CA/RA).

   In this specification, such authentication is achieved by the PKI
   (CA/RA) issuing the end entity with a secret value (initial
   authentication key) and reference value (used to identify the secret
   value) via some out-of-band means.  The initial authentication key
   can then be used to protect relevant PKI messages.

   Thus, we can classify the initial registration/certification scheme
   according to whether or not the on-line end entity -> PKI messages
   are authenticated or not.

   Note 1: We do not discuss the authentication of the PKI -> end entity
   messages here, as this is always REQUIRED.  In any case, it can be
   achieved simply once the root-CA public key has been installed at the
   end entity's equipment or it can be based on the initial
   authentication key.

   Note 2: An initial registration/certification procedure can be secure
   where the messages from the end entity are authenticated via some
   out-of-band means (e.g., a subsequent visit).

4.2.1.3.  Location of Key Generation

   In this specification, "key generation" is regarded as occurring
   wherever either the public or private component of a key pair first
   occurs in a PKIMessage.  Note that this does not preclude a
   centralized key generation service; the actual key pair MAY have been

Top      Up      ToC       Page 16 
   generated elsewhere and transported to the end entity, RA, or CA
   using a (proprietary or standardized) key generation request/response
   protocol (outside the scope of this specification).

   Thus, there are three possibilities for the location of "key
   generation":  the end entity, an RA, or a CA.

4.2.1.4.  Confirmation of Successful Certification

   Following the creation of an initial certificate for an end entity,
   additional assurance can be gained by having the end entity
   explicitly confirm successful receipt of the message containing (or
   indicating the creation of) the certificate.  Naturally, this
   confirmation message must be protected (based on the initial
   authentication key or other means).

   This gives two further possibilities: confirmed or not.

4.2.2.  Mandatory Schemes

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

4.2.2.1.  Centralized Scheme

   In terms of the classification above, this scheme is, in some ways,
   the simplest possible, where:

   o  initiation occurs at the certifying CA;

   o  no on-line message authentication is required;

   o  "key generation" occurs at the certifying CA (see Section
      4.2.1.3);

   o  no confirmation message is required.

   In terms of message flow, this scheme means that the only message
   required is sent from the CA to the end entity.  The message must
   contain the entire PSE for the end entity.  Some out-of-band means
   must be provided to allow the end entity to authenticate the message
   received and to decrypt any encrypted values.

Top      Up      ToC       Page 17 
4.2.2.2.  Basic Authenticated Scheme

   In terms of the classification above, this scheme is where:

   o  initiation occurs at the end entity;

   o  message authentication is REQUIRED;

   o  "key generation" occurs at the end entity (see Section 4.2.1.3);

   o  a confirmation message is REQUIRED.

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

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

   (Where verification of the cert confirmation message fails, the RA/CA
   MUST revoke the newly issued certificate if it has been published or
   otherwise made available.)

4.3.  Proof-of-Possession (POP) of Private Key

   In order to prevent certain attacks and to allow a CA/RA to properly
   check the validity of the binding between an end entity and a key
   pair, the PKI management operations specified here make it possible
   for an end entity to prove that it has possession of (i.e., is able
   to use) the private key corresponding to the public key for which a
   certificate is requested.  A given CA/RA is free to choose how to
   enforce POP (e.g., out-of-band procedural means versus PKIX-CMP

Top      Up      ToC       Page 18 
   in-band messages) in its certification exchanges (i.e., this may be a
   policy issue).  However, it is REQUIRED that CAs/RAs MUST enforce POP
   by some means because there are currently many non-PKIX operational
   protocols in use (various electronic mail protocols are one example)
   that do not explicitly check the binding between the end entity and
   the private key.  Until operational protocols that do verify the
   binding (for signature, encryption, and key agreement key pairs)
   exist, and are ubiquitous, this binding can only be assumed to have
   been verified by the CA/RA.  Therefore, if the binding is not
   verified by the CA/RA, certificates in the Internet Public-Key
   Infrastructure end up being somewhat less meaningful.

   POP is accomplished in different ways depending upon the type of key
   for which a certificate is requested.  If a key can be used for
   multiple purposes (e.g., an RSA key) then any appropriate method MAY

   be used (e.g., a key that may be used for signing, as well as other
   purposes, SHOULD NOT be sent to the CA/RA in order to prove
   possession).

   This specification explicitly allows for cases where an end entity
   supplies the relevant proof to an RA and the RA subsequently attests
   to the CA that the required proof has been received (and validated!).
   For example, an end entity wishing to have a signing key certified
   could send the appropriate signature to the RA, which then simply
   notifies the relevant CA that the end entity has supplied the
   required proof.  Of course, such a situation may be disallowed by
   some policies (e.g., CAs may be the only entities permitted to verify
   POP during certification).

4.3.1.  Signature Keys

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

4.3.2.  Encryption Keys

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

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

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

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

4.3.3.  Key Agreement Keys

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

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

4.4.  Root CA Key Update

   This discussion only applies to CAs that are directly trusted by some
   end entities.  Self-signed CAs SHALL be considered as directly
   trusted CAs.  Recognizing whether a non-self-signed CA is supposed to
   be directly trusted for some end entities is a matter of CA policy
   and is thus beyond the scope of this document.

   The basis of the procedure described here is that the CA protects its
   new public key using its previous private key and vice versa.  Thus,
   when a CA updates its key pair it must generate two extra
   cACertificate attribute values if certificates are made available
   using an X.500 directory (for a total of four: OldWithOld,
   OldWithNew, NewWithOld, and NewWithNew).

   When a CA changes its key pair, those entities who have acquired the
   old CA public key via "out-of-band" means are most affected.  It is
   these end entities who will need access to the new CA public key
   protected with the old CA private key.  However, they will only
   require this for a limited period (until they have acquired the new
   CA public key via the "out-of-band" mechanism).  This will typically
   be easily achieved when these end entities' certificates expire.

Top      Up      ToC       Page 20 
   The data structure used to protect the new and old CA public keys is
   a standard certificate (which may also contain extensions).  There
   are no new data structures required.

   Note 1.  This scheme does not make use of any of the X.509 v3
   extensions as it must be able to work even for version 1
   certificates.  The presence of the KeyIdentifier extension would make
   for efficiency improvements.

   Note 2.  While the scheme could be generalized to cover cases where
   the CA updates its key pair more than once during the validity period
   of one of its end entities' certificates, this generalization seems
   of dubious value.  Not having this generalization simply means that
   the validity periods of certificates issued with the old CA key pair
   cannot exceed the end of the OldWithNew validity period.

   Note 3.  This scheme ensures that end entities will acquire the new
   CA public key, at the latest by the expiry of the last certificate
   they owned that was signed with the old CA private key (via the
   "out-of-band" means).  Certificate and/or key update operations
   occurring at other times do not necessarily require this (depending
   on the end entity's equipment).

4.4.1.  CA Operator Actions

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

   1.  Generate a new key pair;

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

   3.  Create a certificate containing the new CA public key signed with
       the old private key (the "new with old" certificate);

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

   5.  Publish these new certificates via the repository and/or other
       means (perhaps using a CAKeyUpdAnn message);

   6.  Export the new CA public key so that end entities may acquire it
       using the "out-of-band" mechanism (if required).

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

Top      Up      ToC       Page 21 
   The "old with new" certificate must have a validity period starting
   at the generation time of the old key pair and ending at the expiry
   date of the old public key.

   The "new with old" certificate must have a validity period starting
   at the generation time of the new key pair and ending at the time by
   which all end entities of this CA will securely possess the new CA
   public key (at the latest, the expiry date of the old public key).

   The "new with new" certificate must have a validity period starting
   at the generation time of the new key pair and ending at or before
   the time by which the CA will next update its key pair.

4.4.2.  Verifying Certificates

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

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

                   PSE      PSE Contains  PSE Contains    PSE Contains
                Contains     OLD public    NEW public      OLD public
               NEW public       key            key            key
                   key

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

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

4.4.2.1.  Verification in Cases 1, 4, 5, and 8

   In these cases, the verifier has a local copy of the CA public key
   that can be used to verify the certificate directly.  This is the
   same as the situation where no key change has occurred.

   Note that case 8 may arise between the time when the CA operator has
   generated the new key pair and the time when the CA operator stores
   the updated attributes in the repository.  Case 5 can only arise if

   the CA operator has issued both the signer's and verifier's
   certificates during this "gap" (the CA operator SHOULD avoid this as
   it leads to the failure cases described below)

4.4.2.2.  Verification in Case 2

   In case 2, the verifier must get access to the old public key of the
   CA.  The verifier does the following:

   1.  Look up the caCertificate attribute in the repository and pick
       the OldWithNew certificate (determined based on validity periods;
       note that the subject and issuer fields must match);

   2.  Verify that this is correct using the new CA key (which the
       verifier has locally);

   3.  If correct, check the signer's certificate using the old CA key.

   Case 2 will arise when the CA operator has issued the signer's
   certificate, then changed the key, and then issued the verifier's
   certificate; so it is quite a typical case.

Top      Up      ToC       Page 23 
4.4.2.3.  Verification in Case 3

   In case 3, the verifier must get access to the new public key of the
   CA.  The verifier does the following:

   1.  Look up the CACertificate attribute in the repository and pick
       the NewWithOld certificate (determined based on validity periods;
       note that the subject and issuer fields must match);

   2.  Verify that this is correct using the old CA key (which the
       verifier has stored locally);

   3.  If correct, check the signer's certificate using the new CA key.

   Case 3 will arise when the CA operator has issued the verifier's
   certificate, then changed the key, and then issued the signer's
   certificate; so it is also quite a typical case.

4.4.2.4.  Failure of Verification in Case 6

   In this case, the CA has issued the verifier's PSE, which contains
   the new key, without updating the repository attributes.  This means
   that the verifier has no means to get a trustworthy version of the
   CA's old key and so verification fails.

   Note that the failure is the CA operator's fault.

4.4.2.5.  Failure of Verification in Case 7

   In this case, the CA has issued the signer's certificate protected
   with the new key without updating the repository attributes.  This
   means that the verifier has no means to get a trustworthy version of
   the CA's new key and so verification fails.

   Note that the failure is again the CA operator's fault.

4.4.3.  Revocation - Change of CA Key

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

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

Top      Up      ToC       Page 24 
5.  Data Structures

   This section contains descriptions of the data structures required
   for PKI management messages.  Section 6 describes constraints on
   their values and the sequence of events for each of the various PKI
   management operations.

5.1.  Overall PKI Message

   All of the messages used in this specification for the purposes of
   PKI management use the following structure:

      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL
     }
     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

   The PKIHeader contains information that is common to many PKI
   messages.

   The PKIBody contains message-specific information.

   The PKIProtection, when used, contains bits that protect the PKI
   message.

   The extraCerts field can contain certificates that may be useful to
   the recipient.  For example, this can be used by a CA or RA to
   present an end entity with certificates that it needs to verify its
   own new certificate (if, for example, the CA that issued the end
   entity's certificate is not a root CA for the end entity).  Note that
   this field does not necessarily contain a certification path; the
   recipient may have to sort, select from, or otherwise process the
   extra certificates in order to use them.

5.1.1.  PKI Message Header

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

Top      Up      ToC       Page 25 
   The following data structure is used to contain this information:

     PKIHeader ::= SEQUENCE {
         pvno                INTEGER     { cmp1999(1), cmp2000(2) },
         sender              GeneralName,
         recipient           GeneralName,
         messageTime     [0] GeneralizedTime         OPTIONAL,
         protectionAlg   [1] AlgorithmIdentifier     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 pvno field is fixed (at 2) for this version of this
   specification.

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

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

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

   senderKID and recipKID are usable to indicate which keys have been
   used to protect the message (recipKID will normally only be required
   where protection of the message uses Diffie-Hellman (DH) keys).

Top      Up      ToC       Page 26 
   These fields MUST be used if required to uniquely identify a key
   (e.g., if more than one key is associated with a given sender name)
   and SHOULD be omitted otherwise.

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

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

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

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

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

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

5.1.1.1.  ImplicitConfirm

   This is used by the EE to inform the CA that it does not wish to send
   a certificate confirmation for issued certificates.

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

   If the CA grants the request to the EE, it MUST put the same
   extension in the PKIHeader of the response.  If the EE does not find
   the extension in the response, it MUST send the certificate
   confirmation.

5.1.1.2.  ConfirmWaitTime

   This is used by the CA to inform the EE how long it intends to wait
   for the certificate confirmation before revoking the certificate and
   deleting the transaction.

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

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

Top      Up      ToC       Page 28 
          krp      [10] KeyRecRepContent,      --Key Recovery Resp
          rr       [11] RevReqContent,         --Revocation Request
          rp       [12] RevRepContent,         --Revocation Response
          ccr      [13] CertReqMessages,       --Cross-Cert.  Request
          ccp      [14] CertRepMessage,        --Cross-Cert.  Resp
          ckuann   [15] CAKeyUpdAnnContent,    --CA Key Update Ann.
          cann     [16] CertAnnContent,        --Certificate Ann.
          rann     [17] RevAnnContent,         --Revocation Ann.
          crlann   [18] CRLAnnContent,         --CRL Announcement
          pkiconf  [19] PKIConfirmContent,     --Confirmation
          nested   [20] NestedMessageContent,  --Nested Message
          genm     [21] GenMsgContent,         --General Message
          genp     [22] GenRepContent,         --General Response
          error    [23] ErrorMsgContent,       --Error Message
          certConf [24] CertConfirmContent,    --Certificate confirm
          pollReq  [25] PollReqContent,        --Polling request
          pollRep  [26] PollRepContent         --Polling response
          }

   The specific types are described in Section 5.3 below.

5.1.3.  PKI Message Protection

   Some PKI messages will be protected for integrity.  (Note that if an
   asymmetric algorithm is used to protect a message and the relevant
   public component has been certified already, then the origin of the
   message can also be authenticated.  On the other hand, if the public
   component is uncertified, then the message origin cannot be
   automatically authenticated, but may be authenticated via out-of-band
   means.)

   When protection is applied, the following structure is used:

        PKIProtection ::= BIT STRING

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

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

   There MAY be cases in which the PKIProtection BIT STRING is
   deliberately not used to protect a message (i.e., this OPTIONAL field
   is omitted) because other protection, external to PKIX, will be
   applied instead.  Such a choice is explicitly allowed in this
   specification.  Examples of such external protection include PKCS #7

Top      Up      ToC       Page 29 
   [PKCS7] and Security Multiparts [RFC1847] encapsulation of the
   PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the
   relevant PKIHeader information is securely carried in the external
   mechanism).  It is noted, however, that many such external mechanisms
   require that the end entity already possesses a public-key
   certificate, and/or a unique Distinguished Name, and/or other such
   infrastructure-related information.  Thus, they may not be
   appropriate for initial registration, key-recovery, or any other
   process with "boot-strapping" characteristics.  For those cases it
   may be necessary that the PKIProtection parameter be used.  In the
   future, if/when external mechanisms are modified to accommodate
   boot-strapping scenarios, the use of PKIProtection may become rare or
   non-existent.

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

5.1.3.1.  Shared Secret Information

   In this case, the sender and recipient share secret information
   (established via out-of-band means or from a previous PKI management
   operation).  PKIProtection will contain a MAC value and the
   protectionAlg will be the following (see also Appendix D.2):

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

   In the above protectionAlg, the salt value is appended to the shared
   secret input.  The OWF is then applied iterationCount times, where
   the salted secret is the input to the first iteration and, for each
   successive iteration, the input is set to be the output of the
   previous iteration.  The output of the final iteration (called
   "BASEKEY" for ease of reference, with a size of "H") is what is used
   to form the symmetric key.  If the MAC algorithm requires a K-bit key
   and K <= H, then the most significant K bits of BASEKEY are used.  If
   K > H, then all of BASEKEY is used for the most significant H bits of
   the key, OWF("1" || BASEKEY) is used for the next most significant H
   bits of the key, OWF("2" || BASEKEY) is used for the next most
   significant H bits of the key, and so on, until all K bits have been
   derived.  [Here "N" is the ASCII byte encoding the number N and "||"
   represents concatenation.]

Top      Up      ToC       Page 30 
   Note: it is RECOMMENDED that the fields of PBMParameter remain
   constant throughout the messages of a single transaction (e.g.,
   ir/ip/certConf/pkiConf) in order to reduce the overhead associated
   with PasswordBasedMac computation).

5.1.3.2.  DH Key Pairs

   Where the sender and receiver possess Diffie-Hellman certificates
   with compatible DH parameters, in order to protect the message the
   end entity must generate a symmetric key based on its private DH key
   value and the DH public key of the recipient of the PKI message.
   PKIProtection will contain a MAC value keyed with this derived
   symmetric key and the protectionAlg will be the following:

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

        DHBMParameter ::= SEQUENCE {
            owf                 AlgorithmIdentifier,
            -- AlgId for a One-Way Function (SHA-1 recommended)
            mac                 AlgorithmIdentifier
            -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
        }   -- or HMAC [RFC2104, RFC2202])

   In the above protectionAlg, OWF is applied to the result of the
   Diffie-Hellman computation.  The OWF output (called "BASEKEY" for
   ease of reference, with a size of "H") is what is used to form the
   symmetric key.  If the MAC algorithm requires a K-bit key and K <= H,
   then the most significant K bits of BASEKEY are used.  If K > H, then
   all of BASEKEY is used for the most significant H bits of the key,
   OWF("1" || BASEKEY) is used for the next most significant H bits of
   the key, OWF("2" || BASEKEY) is used for the next most significant H
   bits of the key, and so on, until all K bits have been derived.
   [Here "N" is the ASCII byte encoding the number N and "||" represents
   concatenation.]

5.1.3.3.  Signature

   In this case, the sender possesses a signature key pair and simply
   signs the PKI message.  PKIProtection will contain the signature
   value and the protectionAlg will be an AlgorithmIdentifier for a
   digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).

5.1.3.4.  Multiple Protection

   In cases where an end entity sends a protected PKI message to an RA,
   the RA MAY forward that message to a CA, attaching its own protection
   (which MAY be a MAC or a signature, depending on the information and
   certificates shared between the RA and the CA).  This is accomplished

Top      Up      ToC       Page 31 
   by nesting the entire message sent by the end entity within a new PKI
   message.  The structure used is as follows.

          NestedMessageContent ::= PKIMessages

   (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch
   the requests of several EEs in a single new message.  For simplicity,
   all messages in the batch MUST be of the same type (e.g., ir).)  If
   the RA wishes to modify the message(s) in some way (e.g., add
   particular field values or new extensions), then it MAY create its
   own desired PKIBody.  The original PKIMessage from the EE MAY be
   included in the generalInfo field of PKIHeader (to accommodate, for
   example, cases in which the CA wishes to check POP or other
   information on the original EE message).  The infoType to be used in
   this situation is {id-it 15} (see Section 5.3.19 for the value of
   id-it) and the infoValue is PKIMessages (contents MUST be in the same
   order as the requests in PKIBody).

5.2.  Common Data Structures

   Before specifying the specific types that may be placed in a PKIBody,
   we define some data structures that are used in more than one case.

5.2.1.  Requested Certificate Contents

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

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

   See Appendix C and [CRMF] for CertTemplate syntax.

5.2.2.  Encrypted Values

   Where encrypted values (restricted, in this specification, to be
   either private keys or certificates) are sent in PKI messages, the
   EncryptedValue data structure is used.

Top      Up      ToC       Page 32 
   See [CRMF] for EncryptedValue syntax.

   Use of this data structure requires that the creator and intended
   recipient be able to encrypt and decrypt, respectively.  Typically,
   this will mean that the sender and recipient have, or are able to
   generate, a shared secret key.

   If the recipient of the PKIMessage already possesses a private key
   usable for decryption, then the encSymmKey field MAY contain a
   session key encrypted using the recipient's public key.

5.2.3.  Status codes and Failure Information for PKI Messages

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

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

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

        PKIFailureInfo ::= BIT STRING {
            badAlg              (0),
            badMessageCheck     (1),
            badRequest          (2),
            badTime             (3),
            badCertId           (4),
            badDataFormat       (5),
            wrongAuthority      (6),
            incorrectData       (7),
            missingTimeStamp    (8),
            badPOP              (9),
            certRevoked         (10),
            certConfirmed       (11),
            wrongIntegrity      (12),
            badRecipientNonce   (13),
            timeNotAvailable    (14),
            unacceptedPolicy    (15),
            unacceptedExtension (16),
            addInfoNotAvailable (17),

Top      Up      ToC       Page 33 
            badSenderNonce      (18),
            badCertTemplate     (19),
            signerNotTrusted    (20),
            transactionIdInUse  (21),
            unsupportedVersion  (22),
            notAuthorized       (23),
            systemUnavail       (24),
            systemFailure       (25),
            duplicateCertReq    (26)
        }

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

5.2.4.  Certificate Identification

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

   See [CRMF] for CertId syntax.

5.2.5.  Out-of-band root CA Public Key

   Each root CA must be able to publish its current public key via some
   "out-of-band" means.  While such mechanisms are beyond the scope of
   this document, we define data structures that can support such
   mechanisms.

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

        OOBCert ::= Certificate

   The fields within this certificate are restricted as follows:

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

   o  The subject and issuer fields MUST be identical;

   o  If the subject field is NULL, then both subjectAltNames and
      issuerAltNames extensions MUST be present and have exactly the
      same value;

Top      Up      ToC       Page 34 
   o  The values of all other extensions must be suitable for a self-
      signed certificate (e.g., key identifiers for subject and issuer
      must be the same).

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

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

5.2.6.  Archive Options

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

   See [CRMF] for PKIArchiveOptions syntax.

5.2.7.  Publication Information

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

   See [CRMF] for PKIPublicationInfo syntax.

5.2.8.  Proof-of-Possession Structures

   If the certification request is for a signing key pair (i.e., a
   request for a verification certificate), then the proof-of-possession
   of the private signing key is demonstrated through use of the
   POPOSigningKey structure.

   See Appendix C and [CRMF] for POPOSigningKey syntax, but note that
   POPOSigningKeyInput has the following semantic stipulations in this
   specification.

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

Top      Up      ToC       Page 35 
   On the other hand, if the certification request is for an encryption
   key pair (i.e., a request for an encryption certificate), then the
   proof-of-possession of the private decryption key may be demonstrated
   in one of three ways.

5.2.8.1.  Inclusion of the Private Key

   By the inclusion of the private key (encrypted) in the CertRequest
   (in the thisMessage field of POPOPrivKey (see Appendix C) or in the
   PKIArchiveOptions control structure, depending upon whether or not
   archival of the private key is also desired).

5.2.8.2.  Indirect Method

   By having the CA return not the certificate, but an encrypted
   certificate (i.e., the certificate encrypted under a randomly-
   generated symmetric key, and the symmetric key encrypted under the
   public key for which the certification request is being made) -- this
   is the "indirect" method mentioned previously in Section 4.3.2. The
   end entity proves knowledge of the private decryption key to the CA
   by providing the correct CertHash for this certificate in the
   certConf message.  This demonstrates POP because the EE can only
   compute the correct CertHash if it is able to recover the
   certificate, and it can only recover the certificate if it is able to
   decrypt the symmetric key using the required private key.  Clearly,
   for this to work, the CA MUST NOT publish the certificate until the
   certConf message arrives (when certHash is to be used to demonstrate
   POP).  See Section 5.3.18 for further details.

5.2.8.3.  Challenge-Response Protocol

   By having the end entity engage in a challenge-response protocol
   (using the messages POPODecKeyChall and POPODecKeyResp; see below)
   between CertReqMessages and CertRepMessage -- this is the "direct"
   method mentioned previously in Section 4.3.2.  (This method would
   typically be used in an environment in which an RA verifies POP and
   then makes a certification request to the CA on behalf of the end
   entity.  In such a scenario, the CA trusts the RA to have done POP
   correctly before the RA requests a certificate for the end entity.)
   The complete protocol then looks as follows (note that req' does not
   necessarily encapsulate req as a nested message):

Top      Up      ToC       Page 36 
                   EE            RA            CA
                    ---- req ---->
                    <--- chall ---
                    ---- resp --->
                                  ---- req' --->
                                  <--- rep -----
                                  ---- conf --->
                                  <--- ack -----
                    <--- rep -----
                    ---- conf --->
                    <--- ack -----

   This protocol is obviously much longer than the 3-way exchange given
   in choice (2) above, but allows a local Registration Authority to be
   involved and has the property that the certificate itself is not
   actually created until the proof-of-possession is complete.  In some
   environments, a different order of the above messages may be
   required, such as the following (this may be determined by policy):

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

   If the cert. request is for a key agreement key (KAK) pair, then the
   POP can use any of the 3 ways described above for enc. key pairs,
   with the following changes: (1) the parenthetical text of bullet 2)
   is replaced with "(i.e., the certificate encrypted under the
   symmetric key derived from the CA's private KAK and the public key
   for which the certification request is being made)"; (2) the first
   parenthetical text of the challenge field of "Challenge" below is
   replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and
   Appendix E.5) and a symmetric key derived from the CA's private KAK
   and the public key for which the certification request is being
   made)".  Alternatively, the POP can use the POPOSigningKey structure
   given in [CRMF] (where the alg field is DHBasedMAC and the signature
   field is the MAC) as a fourth alternative for demonstrating POP if
   the CA already has a D-H certificate that is known to the EE.

Top      Up      ToC       Page 37 
   The challenge-response messages for proof-of-possession of a private
   decryption key are specified as follows (see [MvOV97], p.404 for
   details).  Note that this challenge-response exchange is associated
   with the preceding cert. request message (and subsequent cert.
   response and confirmation messages) by the transactionID used in the
   PKIHeader and by the protection (MACing or signing) applied to the
   PKIMessage.

        POPODecKeyChallContent ::= SEQUENCE OF Challenge
        Challenge ::= SEQUENCE {
            owf                 AlgorithmIdentifier  OPTIONAL,
            witness             OCTET STRING,
            challenge           OCTET STRING
        }

   Note that the size of Rand needs to be appropriate for encryption
   under the public key of the requester.  Given that "int" will
   typically not be longer than 64 bits, this leaves well over 100 bytes
   of room for the "sender" field when the modulus is 1024 bits.  If, in
   some environment, names are so long that they cannot fit (e.g., very
   long DNs), then whatever portion will fit should be used (as long as
   it includes at least the common name, and as long as the receiver is
   able to deal meaningfully with the abbreviation).

        POPODecKeyRespContent ::= SEQUENCE OF INTEGER

5.2.8.4.  Summary of PoP Options

   The text in this section provides several options with respect to POP
   techniques.  Using "SK" for "signing key", "EK" for "encryption key",
   and "KAK" for "key agreement key", the techniques may be summarized
   as follows:

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

   Given this array of options, it is natural to ask how an end entity
   can know what is supported by the CA/RA (i.e., which options it may
   use when requesting certificates).  The following guidelines should
   clarify this situation for EE implementers.

Top      Up      ToC       Page 38 
   RAVerified.  This is not an EE decision; the RA uses this if and only
   if it has verified POP before forwarding the request on to the CA, so
   it is not possible for the EE to choose this technique.

   SKPOP.  If the EE has a signing key pair, this is the only POP method
   specified for use in the request for a corresponding certificate.

   EKPOPThisMessage and KAKPOPThisMessage.  Whether or not to give up
   its private key to the CA/RA is an EE decision.  If the EE decides to
   reveal its key, then these are the only POP methods available in this
   specification to achieve this (and the key pair type will determine
   which of these two methods to use).

   KAKPOPThisMessageDHMAC.  The EE can only use this method if (1) the
   CA has a DH certificate available for this purpose, and (2) the EE
   already has a copy of this certificate.  If both these conditions
   hold, then this technique is clearly supported and may be used by the
   EE, if desired.

   EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp,
   KAKPOPChallengeResp.  The EE picks one of these (in the
   subsequentMessage field) in the request message, depending upon
   preference and key pair type.  The EE is not doing POP at this point;
   it is simply indicating which method it wants to use.  Therefore, if
   the CA/RA replies with a "badPOP" error, the EE can re-request using
   the other POP method chosen in subsequentMessage.  Note, however,
   that this specification encourages the use of the EncryptedCert
   choice and, furthermore, says that the challenge-response would
   typically be used when an RA is involved and doing POP verification.
   Thus, the EE should be able to make an intelligent decision regarding
   which of these POP methods to choose in the request message.



(page 38 continued on part 3)

Next RFC Part