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