lines.Adams & Farrell             Standards Track                     [Page 6]RFC 2510          PKI Certificate Management Protocols        March 1999      +---+     cert. publish        +------------+      j      |   |  <---------------------  | End Entity | <-------      | C |             g            +------------+      "out-of-band"      |   |                            | ^                loading      | e |                            | |      initial      | r |                          a | | b     registration/      | t |                            | |       certification      |   |                            | |      key pair recovery      | / |                            | |      key pair update      |   |                            | |      certificate update      | C |  PKI "USERS"               V |      revocation request      | R | -------------------+-+-----+-+------+-+-------------------      | L |  PKI MANAGEMENT    | ^              | ^      |   |    ENTITIES      a | | b          a | | b      |   |                    V |              | |      | R |             g   +------+    d       | |      | e |   <------------ | RA   | <-----+    | |      | p |      cert.      |      | ----+ |    | |      | o |       publish   +------+   c | |    | |      | s |                              | |    | |      | i |                              V |    V |      | t |          g                 +------------+   i      | o |   <------------------------|     CA     |------->      | r |          h                 +------------+  "out-of-band"      | y |      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             Standards Track                     [Page 7]RFC 2510          PKI Certificate Management Protocols        March 1999      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             Standards Track                     [Page 8]RFC 2510          PKI Certificate Management Protocols        March 1999   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            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.Adams & Farrell             Standards Track                     [Page 9]RFC 2510          PKI Certificate Management Protocols        March 1999      7 PSE operations: whilst the definition of PSE operations (e.g.,        moving a PSE, changing a PIN, etc.) are beyond the scope of this        specification, we do define a PKIMessage (CertRepMessage) which        can form the basis of such operations.   Note that on-line protocols are not the only way of implementing the   above operations.  For all operations there are off-line methods of   achieving the same result, and this specification does not mandate   use of on-line protocols.  For example, when hardware tokens are   used, many of the operations MAY be achieved as part of the physical   token delivery.   Later sections define a set of standard messages supporting the above   operations.  The protocols for conveying these exchanges in different   environments (file based, on-line, E-mail, and WWW) is also   specified.2. Assumptions and restrictions2.1 End entity initialization   The first step for an end entity in dealing with PKI management   entities is to request information about the PKI functions supported   and to securely acquire a copy of the relevant root CA public key(s).2.2 Initial registration/certification   There are many schemes that can be used to achieve initial   registration and certification of end entities. No one method is   suitable for all situations due to the range of policies which a CA   may implement and the variation in the types of end entity which can   occur.   We can however, classify the initial registration / certification   schemes that are supported by this specification. Note that the word   "initial", above, is crucial - we are dealing with the situation   where the end entity in question has had no previous contact with the   PKI. Where the end entity already possesses certified keys then some   simplifications/alternatives are possible.   Having classified the schemes that are supported by this   specification we can then specify some as mandatory and some as   optional. The goal is that the mandatory schemes cover a sufficient   number of the cases which will arise in real use, whilst the optional   schemes are available for special cases which arise less frequently.   In this way we achieve a balance between flexibility and ease of   implementation.Adams & Farrell             Standards Track                    [Page 10]RFC 2510          PKI Certificate Management Protocols        March 1999   We will now describe the classification of initial registration /   certification schemes.2.2.1 Criteria used2.2.1.1 Initiation of registration / certification   In terms of the PKI messages which are produced we can regard the   initiation of the initial registration / certification exchanges as   occurring wherever the first PKI message relating to the end entity   is produced. Note that the real-world initiation of the registration   / certification procedure may occur elsewhere (e.g., a personnel   department may telephone an RA operator).   The possible locations are at the end entity, an RA, or a CA.2.2.1.2 End entity message origin authentication   The on-line messages produced by the end entity that requires a   certificate may be authenticated or not. The requirement here is to   authenticate the origin of any messages from the end entity to the   PKI (CA/RA).   In this specification, such authentication is achieved by the PKI   (CA/RA) issuing the end entity with a secret value (initial   authentication key) and reference value (used to identify the   transaction) via some out-of-band means. The initial authentication   key can then be used to protect relevant PKI messages.   We can thus classify the initial registration/certification scheme   according to whether or not the on-line end entity -> PKI messages   are authenticated or not.   Note 1: We do not discuss the authentication of the PKI -> end entity   messages here as this is always REQUIRED. In any case, it can be   achieved simply once the root-CA public key has been installed at the   end entity's equipment or it can be based on the initial   authentication key.   Note 2: An initial registration / certification procedure can be   secure where the messages from the end entity are authenticated via   some out- of-band means (e.g., a subsequent visit).2.2.1.3 Location of key generation   In this specification, "key generation" is regarded as occurring   wherever either the public or private component of a key pair first   occurs in a PKIMessage. Note that this does not preclude aAdams & Farrell             Standards Track                    [Page 11]RFC 2510          PKI Certificate Management Protocols        March 1999   centralized key generation service - the actual key pair MAY have   been generated elsewhere and transported to the end entity, RA, or CA