Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
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 2 of 5 – Pages 14 to 38
First   Prev   Next

Top   ToC   RFC4210 - Page 14   prevText

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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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   ToC   RFC4210 - 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 Section