draft-ietf-pkix-rfc2510bis-07.txt

PKIX的RFC英文文档

   mandate that the RA is certified by the CA with which it is
   interacting at the moment (so one RA may work with more than one CA
   whilst only being certified once).

   In some circumstances end entities will communicate directly with a
   CA even where an RA is present. For example, for initial registration
   and/or certification the subject may use its RA, but communicate
   directly with the CA in order to refresh its certificate.

1.3 PKI Management Requirements

   The protocols given here meet the following requirements on PKI
   management.

      1. PKI management must conform to the ISO 9594-8 standard and the
         associated amendments (certificate extensions)

      2. PKI management must conform to the other parts of this series.

      3. It must be possible to regularly update any key pair without
         affecting any other key pair.

      4. The use of confidentiality in PKI management protocols must be
         kept to a minimum in order to ease regulatory problems.







Adams & Farrell               Expires May 2003                    [Page 6]




      5. PKI management protocols must allow the use of different
         industry-standard cryptographic algorithms, (specifically
         including RSA, DSA, MD5, SHA-1) -- this means that any given
         CA, RA, or end entity may, in principle, use whichever
         algorithms suit it for its own key pair(s).

      6. PKI management protocols must not preclude the generation of
         key pairs by the end-entity concerned, by an RA, or by a CA --
         key generation may also occur elsewhere, but for the purposes
         of PKI management we can regard key generation as occurring
         wherever the key is first present at an end entity, RA, or CA.

      7. PKI management protocols must support the publication of
         certificates by the end-entity concerned, by an RA, or by a CA.
         Different implementations and different environments may choose
         any of the above approaches.

      8. PKI management protocols must support the production of
         Certificate Revocation Lists (CRLs) by allowing certified end
         entities to make requests for the revocation of certificates -
         this must be done in such a way that the denial-of-service
         attacks which are possible are not made simpler.

      9. PKI management protocols must be usable over a variety of
         "transport" mechanisms, specifically including mail, http,
         TCP/IP and ftp.

      10. Final authority for certification creation rests with the CA;
          no RA or end-entity equipment can assume that any certificate
          issued by a CA will contain what was requested -- a CA may
          alter certificate field values or may add, delete or alter
          extensions according to its operating policy. In other words,
          all PKI entities (end-entities, RAs, and CAs) must be capable
          of handling responses to requests for certificates in which
          the actual certificate issued is different from that requested
          (for example, a CA may shorten the validity period requested).
          Note that policy may dictate that the CA must not publish or
          otherwise distribute the certificate until the requesting
          entity has reviewed and accepted the newly-created certificate
          (typically through use of the certConf message).

      11. A graceful, scheduled change-over from one non-compromised CA
          key pair to the next (CA key update) must be supported (note
          that if the CA key is compromised, re-initialization must be
          performed for all entities in the domain of that CA). An end
          entity whose PSE contains the new CA public key (following a
          CA key update) must also be able to verify certificates
          verifiable using the old public key. End entities who directly





Adams & Farrell               Expires May 2003                    [Page 7]




          trust the old CA key pair must also be able to verify
          certificates signed using the new CA private key.  (Required
          for situations where the old CA public key is "hardwired" into
          the end entity's cryptographic equipment).

      12. The Functions of an RA may, in some implementations or
          environments, be carried out by the CA itself. The protocols
          must be designed so that end entities will use the same
          protocol (but, of course, not the same key!) regardless of
          whether the communication is with an RA or CA.

      13. Where an end entity requests a certificate containing a given
          public key value, the end entity must be ready to demonstrate
          possession of the corresponding private key value. This may be
          accomplished in various ways, depending on the type of
          certification request. See Section 2.3, "Proof of Possession
          of Private Key", for details of the in-band methods defined
          for the PKIX-CMP (i.e., Certificate Management Protocol)
          messages.

1.4 PKI Management Operations

   The following diagram shows the relationship between the entities
   defined above in terms of the PKI management operations. The letters
   in the diagram indicate "protocols" in the sense that a defined set
   of PKI management messages can be sent along each of the lettered
   lines.


























Adams & Farrell               Expires May 2003                    [Page 8]




      +---+     cert. publish        +------------+      j
      |   |  <---------------------  | End Entity | <-------
      | C |             g            +------------+      "out-of-band"
      | e |                            | ^                loading
      | r |                            | |      initial
      | t |                          a | | b     registration/
      |   |                            | |       certification
      | / |                            | |      key pair recovery
      |   |                            | |      key pair update
      | C |                            | |      certificate update
      | R |  PKI "USERS"               V |      revocation request
      | L | -------------------+-+-----+-+------+-+-------------------
      |   |  PKI MANAGEMENT    | ^              | ^
      |   |    ENTITIES      a | | b          a | | b
      | R |                    V |              | |
      | e |             g   +------+    d       | |
      | p |   <------------ | RA   | <-----+    | |
      | o |      cert.      |      | ----+ |    | |
      | s |       publish   +------+   c | |    | |
      | i |                              | |    | |
      | t |                              V |    V |
      | o |          g                 +------------+   i
      | r |   <------------------------|     CA     |------->
      | y |          h                 +------------+  "out-of-band"
      |   |      cert. publish              | ^         publication
      |   |      CRL publish                | |
      +---+                                 | |    cross-certification
                                          e | | f  cross-certificate
                                            | |       update
                                            | |
                                            V |
                                          +------+
                                          | CA-2 |
                                          +------+

                           Figure 1 - PKI Entities

   At a high level the set of operations for which management messages
   are defined can be grouped as follows.

      1 CA establishment: When establishing a new CA, certain steps are
        required (e.g., production of initial CRLs, export of CA public
        key).

      2 End entity initialization: this includes importing a root CA
        public key and requesting information about the options
        supported by a PKI management entity.






Adams & Farrell               Expires May 2003                    [Page 9]




      3 Certification: various operations result in the creation of new
        certificates:

        3.1 initial registration/certification: This is the process
            whereby  an end entity first makes itself known to a CA or
            RA, prior to the CA issuing a certificate or certificates
            for that end entity. The end result of this process (when it
            is successful) is that a CA issues a certificate for an end
            entity's public key, and returns that certificate to the end
            entity and/or posts that certificate in a public repository.
            This process may, and typically will, involve multiple
            "steps", possibly including an initialization of the end
            entity's equipment. For example, the end entity's equipment
            must be securely initialized with the public key of a CA, to
            be used in validating certificate paths.  Furthermore, an
            end entity typically needs to be initialized with its own
            key pair(s).

        3.2 key pair update:  Every key pair needs to be updated
            regularly (i.e., replaced with a new key pair), and a new
            certificate needs to be issued.

        3.3 certificate update: As certificates expire they may be
            "refreshed" if nothing relevant in the environment has
            changed.

        3.4 CA key pair update: As with end entities, CA key pairs need
            to be updated regularly; however, different mechanisms are
            required.

        3.5 cross-certification request:  One CA requests issuance of a
            cross-certificate from another CA.  For the purposes of this
            standard, the following terms are defined.  A "cross-
            certificate" is a certificate in which the subject CA and
            the issuer CA are distinct and SubjectPublicKeyInfo contains
            a verification key (i.e., the certificate has been issued
            for the subject CA's signing key pair).  When it is
            necessary to distinguish more finely, the following terms
            may be used: a cross-certificate is called an "inter-domain
            cross-certificate" if the subject and issuer CAs belong to
            different administrative domains; it is called an "intra-
            domain cross-certificate" otherwise.











Adams & Farrell               Expires May 2003                   [Page 10]




            Notes:

            Note 1. The above definition of "cross-certificate" aligns 
            with the defined term "CA-certificate" in X.509.  Note that 
            this term is not to be confused with the X.500 "cACertificate" 
            attribute type, which is unrelated.

            Note 2. In many environments the term "cross-certificate", 
            unless further qualified, will be understood to be synonymous 
            with "inter-domain cross-certificate" as defined above.

            Note 3. Issuance of cross-certificates may be, but is not
            necessarily, mutual; that is, two CAs may issue 
            cross-certificates for each other.

        3.6 cross-certificate update: Similar to a normal certificate
            update but involving a cross-certificate.

      4 Certificate/CRL discovery operations: some PKI management
        operations result in the publication of certificates or CRLs:

        4.1 certificate publication: Having gone to the trouble of
            producing a certificate, some means for publishing it is
            needed.  The "means" defined in PKIX MAY involve the
            messages specified in Sections 3.3.13 - 3.3.16, or MAY
            involve other methods (LDAP, for example) as described in 
            [RFC2559, RFC2585] (the "Operational Protocols" documents
            of the PKIX series of specifications).

        4.2 CRL publication: As for certificate publication.

      5 Recovery operations: some PKI management operations are used
        when an end entity has "lost" its PSE:

        5.1 key pair recovery:  As an option, user client key materials
            (e.g., a user's private key used for decryption purposes)
            MAY be backed up by a CA, an RA, or a key backup system
            associated with a CA or RA. If an entity needs to recover
            these backed up key materials (e.g., as a result of a
            forgotten password or a lost key chain file), a  protocol
            exchange may be needed to support such recovery.

      6 Revocation operations: some PKI operations result in the
        creation of new CRL entries and/or new CRLs:

        6.1 revocation request:  An authorized person advises a CA of an
            abnormal situation requiring certificate revocation.