draft-ietf-pkix-rfc2510bis-07.txt

PKIX的RFC英文文档

   This discussion only applies to CAs that are a root CA for some end
   entity.

   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.

   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 period of a CA key pair must be greater than the
   validity period of any certificate issued by that CA using that key
   pair.





Adams & Farrell               Expires May 2003                   [Page 17]




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

2.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. The old CA public
   key will however remain in use for some time. The time when the old
   CA public key is no longer required (other than for non-repudiation)
   will be when all end entities of this CA have securely acquired the
   new CA public key.

   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.







Adams & Farrell               Expires May 2003                   [Page 18]




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

   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.









Adams & Farrell               Expires May 2003                   [Page 19]




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

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 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 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 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 key and then issued the signer's
   certificate, so it is also quite a typical case.







Adams & Farrell               Expires May 2003                   [Page 20]




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

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

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. 

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
     }

     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage


Adams & Farrell               Expires May 2003                   [Page 21]




   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     { cmp1999(1), cmp2000(2) },
         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