rfc2510.txt

PKIX的RFC英文文档

   protected  verifier     can directly  is the         has not
   using OLD  must         verify the    situation of   updated the
   public     access the   certificate   case 2 and     directory the
   key        directory    without       will access    verifier can
              in order     using the     the            verify the
              to get the   directory     directory;     certificate
              value of                   however, the   directly -
              the OLD                    verification   this is thus
              public key                 will FAIL      the same as
                                                        case 4.







Adams & Farrell             Standards Track                    [Page 17]

RFC 2510          PKI Certificate Management Protocols        March 1999


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

2.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 directory and pick
         the OldWithNew certificate (determined based on validity
         periods);
      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 key and then issued the verifier's
   certificate, so it is quite a typical case.

2.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 directory and pick
         the NewWithOld certificate (determined based on validity
         periods);
      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 key and then issued the signer's
   certificate, so it is also quite a typical case.





Adams & Farrell             Standards Track                    [Page 18]

RFC 2510          PKI Certificate Management Protocols        March 1999


2.4.2.4 Failure of verification in case 6.

   In this case the CA has issued the verifier's PSE containing the new
   key without updating the directory 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.

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

2.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 that is within the user's PSE.

   The analysis of the alternatives is as for certificate verification.

3. Data Structures

   This section contains descriptions of the data structures required
   for PKI management messages. Section 4 describes constraints on their
   values and the sequence of events for each of the various PKI
   management operations. Section 5 describes how these may be
   encapsulated in various transport mechanisms.

3.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 Certificate OPTIONAL
     }





Adams & Farrell             Standards Track                    [Page 19]

RFC 2510          PKI Certificate Management Protocols        March 1999


   The PKIHeader contains information which 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.

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

   The following data structure is used to contain this information:

     PKIHeader ::= SEQUENCE {
         pvno                INTEGER     { ietf-version2 (1) },
         sender              GeneralName,
         -- identifies the sender
         recipient           GeneralName,
         -- identifies the intended recipient
         messageTime     [0] GeneralizedTime         OPTIONAL,
         -- time of production of this message (used when sender
         -- believes that the transport will be "suitable"; i.e.,
         -- that the time will still be meaningful upon receipt)
         protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,
         -- algorithm used for calculation of protection bits
         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             Standards Track                    [Page 20]

RFC 2510          PKI Certificate Management Protocols        March 1999


         -- 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 (note:  each UTF8String SHOULD
         -- include an RFC 1766 language tag to indicate the language
         -- of the contained text)

   The pvno field is fixed (at one) 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
   usable 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).







Adams & Farrell             Standards Track                    [Page 21]

RFC 2510          PKI Certificate Management Protocols        March 1999


   The transactionID field within the message header MAY be used to
   allow the recipient of a response message to correlate this with a
   previously issued request. For example, in the case of an RA there
   may be many requests "outstanding" at a given moment.

   The senderNonce and recipNonce fields protect the PKIMessage against
   replay attacks.

   The messageTime field contains the time at which the sender created
   the message. This may be useful to allow end entities to correct
   their local time to be consistent 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.

3.1.2 PKI Message Body

     PKIBody ::= CHOICE {       -- message-specific body elements
         ir      [0]  CertReqMessages,        --Initialization Request
         ip      [1]  CertRepMessage,         --Initialization Response
         cr      [2]  CertReqMessages,        --Certification Request
         cp      [3]  CertRepMessage,         --Certification Response
         p10cr   [4]  CertificationRequest,   --PKCS #10 Cert. Req.
           -- the PKCS #10 certification request (see [PKCS10])
         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 Request
         krp     [10] KeyRecRepContent,       --Key Recovery Response
         rr      [11] RevReqContent,          --Revocation Request
         rp      [12] RevRepContent,          --Revocation Response
         ccr     [13] CertReqMessages,        --Cross-Cert. Request
         ccp     [14] CertRepMessage,         --Cross-Cert. Response
         ckuann  [15] CAKeyUpdAnnContent,     --CA Key Update Ann.
         cann    [16] CertAnnContent,         --Certificate Ann.
         rann    [17] RevAnnContent,          --Revocation Ann.
         crlann  [18] CRLAnnContent,          --CRL Announcement
         conf    [19] PKIConfirmContent,      --Confirmation
         nested  [20] NestedMessageContent,   --Nested Message
         genm    [21] GenMsgContent,          --General Message
         genp    [22] GenRepContent,          --General Response
         error   [23] ErrorMsgContent         --Error Message
     }



Adams & Farrell             Standards Track                    [Page 22]

RFC 2510          PKI Certificate Management Protocols        March 1999


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