draft-ietf-pkix-rfc2510bis-07.txt

PKIX的RFC英文文档

         senderKID       [2] KeyIdentifier           OPTIONAL,
         recipKID        [3] KeyIdentifier           OPTIONAL,
         -- to identify specific keys used for protection
         transactionID   [4] OCTET STRING            OPTIONAL,
         -- identifies the transaction; i.e., this will be the same in
         -- corresponding request, response and confirmation messages
         senderNonce     [5] OCTET STRING            OPTIONAL,
         recipNonce      [6] OCTET STRING            OPTIONAL,
         -- nonces used to provide replay protection, senderNonce





Adams & Farrell               Expires May 2003                   [Page 22]




         -- is inserted by the creator of this message; recipNonce
         -- is a nonce previously inserted in a related message by
         -- the intended recipient of this message
         freeText        [7] PKIFreeText             OPTIONAL,
         -- this may be used to indicate context-specific instructions
         -- (this field is intended for human consumption)
         generalInfo     [8] SEQUENCE SIZE (1..MAX) OF
                                InfoTypeAndValue     OPTIONAL
         -- this may be used to convey context-specific information
         -- (this field not primarily intended for human consumption)
     }

     PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
         -- text encoded as UTF-8 String [RFC2279] (note:  each UTF8String 
         -- MAY include an RFC 1766/RFC 3066 language tag to indicate the 
         -- language of the contained text -- see [RFC2482] for details)

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






Adams & Farrell               Expires May 2003                   [Page 23]


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

   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.

Adams & Farrell               Expires May 2003                   [Page 24]


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

3.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 -- time CA will wait until
   

3.1.2 PKI Message Body

     PKIBody ::= CHOICE {  -- message-specific body elements & Section ref
       ir      [0]   CertReqMessages,       --Initialization Req  (3.3.1)
       ip      [1]   CertRepMessage,        --Initialization Resp (3.3.2)
       cr      [2]   CertReqMessages,       --Certification Req   (3.3.3)
       cp      [3]   CertRepMessage,        --Certification Resp  (3.3.4)
       p10cr   [4]   CertificationRequest,  --PKCS #10 Cert. Req. [PKCS10]
         -- the PKCS #10 certification request (see [PKCS10])
       popdecc [5]   POPODecKeyChallContent --pop Challenge       (3.2.8)
       popdecr [6]   POPODecKeyRespContent, --pop Response        (3.2.8)
       kur     [7]   CertReqMessages,       --Key Update Request  (3.3.5)
       kup     [8]   CertRepMessage,        --Key Update Response (3.3.6)
       krr     [9]   CertReqMessages,       --Key Recovery Req    (3.3.7)
       krp     [10]  KeyRecRepContent,      --Key Recovery Resp   (3.3.8)
       rr      [11]  RevReqContent,         --Revocation Request  (3.3.9)
       rp      [12]  RevRepContent,         --Revocation Response (3.3.10)
       ccr     [13]  CertReqMessages,       --Cross-Cert. Request (3.3.11)
       ccp     [14]  CertRepMessage,        --Cross-Cert. Resp    (3.3.12)
       ckuann  [15]  CAKeyUpdAnnContent,    --CA Key Update Ann.  (3.3.13)
       cann    [16]  CertAnnContent,        --Certificate Ann.    (3.3.14)
       rann    [17]  RevAnnContent,         --Revocation Ann.     (3.3.15)
       crlann  [18]  CRLAnnContent,         --CRL Announcement    (3.3.16)
       pkiconf [19]  PKIConfirmContent,     --Confirmation        (3.3.17)
       nested  [20]  NestedMessageContent,  --Nested Message      (3.1.3)
       genm    [21]  GenMsgContent,         --General Message     (3.3.19)
       genp    [22]  GenRepContent,         --General Response    (3.3.20)
       error   [23]  ErrorMsgContent,       --Error Message       (3.3.21)
       certConf [24] CertConfirmContent,    --Certificate confirm (3.3.18)
       pollReq [25]  PollReqContent,        --Polling request     (3.3.22)
       pollRep [26]  PollRepContent         --Polling response    (3.3.22)
       }

Adams & Farrell               Expires May 2003                   [Page 25]




   The specific types are described in Section 3.3 below.

3.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 instead
   be applied. Such a choice is explicitly allowed in this
   specification.  Examples of such external protection include PKCS #7
   [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:







Adams & Farrell               Expires May 2003                   [Page 26]




   - 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 B2):

     id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
     PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         iterationCount      INTEGER,
         -- number of times the OWF is applied
         mac                 AlgorithmIdentifier
         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
     }   -- or HMAC [RFC2104, RFC2202])

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

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

   - DH key pairs

   Where the sender and receiver possess Diffie-Hellman certificates
   with compatible DH parameters, then 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:







Adams & Farrell               Expires May 2003                   [Page 27]

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

     DHBMParameter ::= SEQUENCE {
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 r