Adams & Farrell               Expires May 2003                   [Page 11]      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.  Transport protocols for conveying these exchanges in    different environments (file based, on-line, E-mail, and WWW) are    beyond the scope of this document and are specified separately.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               Expires May 2003                   [Page 12]   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   secret value) 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               Expires May 2003                   [Page 13]   centralized key generation service - the actual key pair MAY have   been generated elsewhere and transported to the end entity, RA, or CA   using a (proprietary or standardized) key generation request/response   protocol (outside the scope of this specification).   There are thus three possibilities for the location of "key   generation":  the end entity, an RA, or a CA.2.2.1.4 Confirmation of successful certification   Following the creation of an initial certificate for an end entity,   additional assurance can be gained by having the end entity   explicitly confirm successful receipt of the message containing (or   indicating the creation of) the certificate. Naturally, this   confirmation message must be protected (based on the initial   authentication key or other means).   This gives two further possibilities: confirmed or not.2.2.2 Mandatory schemes   The criteria above allow for a large number of initial registration /   certification schemes. This specification mandates that conforming CA   equipment, RA equipment, and EE equipment MUST support the second   scheme listed below. Any entity MAY additionally support other   schemes, if desired.2.2.2.1 Centralized scheme   In terms of the classification above, this scheme is, in some ways,   the simplest possible, where:   - initiation occurs at the certifying CA;   - no on-line message authentication is required;   - "key generation" occurs at the certifying CA (see Section 2.2.1.3);   - no confirmation message is required.   In terms of message flow, this scheme means that the only message   required is sent from the CA to the end entity. The message must   contain the entire PSE for the end entity. Some out-of-band means   must be provided to allow the end entity to authenticate the message   received and decrypt any encrypted values.Adams & Farrell               Expires May 2003                   [Page 14]2.2.2.2 Basic authenticated scheme   In terms of the classification above, this scheme is where:   - initiation occurs at the end entity;   - message authentication is REQUIRED;   - "key generation" occurs at the end entity (see Section 2.2.1.3);   - a confirmation message is REQUIRED.   In terms of message flow, the basic authenticated scheme is as   follows:      End entity                                          RA/CA      ==========                                      =============           out-of-band distribution of Initial Authentication           Key (IAK) and reference value (RA/CA -> EE)      Key generation      Creation of certification request      Protect request with IAK                    -->>--certification request-->>--                                                     verify request                                                     process request                                                     create response                    --<<--certification response--<<--      handle response      create confirmation                    -->>--cert conf message-->>--                                                     verify confirmation                                                     create response                    --<<-- conf ack (optional)  --<<--      handle response   (Where verification of the cert confirmation message fails, the RA/CA    MUST revoke the newly issued certificate if it has been published or   otherwise made available.)2.3 Proof of Possession (POP) of Private Key   In order to prevent certain attacks and to allow a CA/RA to properly   check the validity of the binding between an end entity and a key   pair, the PKI management operations specified here make it possible   for an end entity to prove that it has possession of (i.e., is able   to use) the private key corresponding to the public key for which a   certificate is requested.  A given CA/RA is free to choose how to   enforce POP (e.g., out-of-band procedural means versus PKIX-CMP in-   band messages) in its certification exchanges (i.e., this may be a   policy issue).  However, it is REQUIRED that CAs/RAs MUST enforce POP   by some means because there are currently many non-PKIX operational   protocols in use (various electronic mail protocols are one example)   that do not explicitly check the binding between the end entity and   the private key.  Until operational protocols that do verify theAdams & Farrell               Expires May 2003                   [Page 15]   binding (for signature, encryption, and key agreement key pairs)   exist, and are ubiquitous, this binding can only be assumed to have   been verified by the CA/RA. Therefore, if the binding is not verified   by the CA/RA, certificates in the Internet Public-Key Infrastructure   end up being somewhat less meaningful.   POP is accomplished in different ways depending upon the type of key   for which a certificate is requested. If a key can be used for   multiple purposes (e.g., an RSA key) then any appropriate method MAY   be used (e.g., a key which may be used for signing, as well as other   purposes, SHOULD NOT be sent to the CA/RA in order to prove   possession).   This specification explicitly allows for cases where an end entity   supplies the relevant proof to an RA and the RA subsequently attests   to the CA that the required proof has been received (and validated!).   For example, an end entity wishing to have a signing key certified   could send the appropriate signature to the RA which then simply   notifies the relevant CA that the end entity has supplied the   required proof. Of course, such a situation may be disallowed by some   policies (e.g., CAs may be the only entities permitted to verify POP   during certification).2.3.1 Signature Keys   For signature keys, the end entity can sign a value to prove   possession of the private key.2.3.2 Encryption Keys   For encryption keys, the end entity can provide the private key to   the CA/RA, or can be required to decrypt a value in order to prove   possession of the private key (see Section 3.2.8). Decrypting a value   can be achieved either directly or indirectly.   The direct method is for the RA/CA to issue a random challenge to   which an immediate response by the EE is required.   The indirect method is to issue a certificate which is encrypted for   the end entity (and have the end entity demonstrate its ability to   decrypt this certificate in the confirmation message). This allows a   CA to issue a certificate in a form which can only be used by the   intended end entity.   This specification encourages use of the indirect method because this   requires no extra messages to be sent (i.e., the proof can be   demonstrated using the {request, response, confirmation} triple of   messages).Adams & Farrell               Expires May 2003                   [Page 16]2.3.3 Key Agreement Keys   For key agreement keys, the end entity and the PKI management entity   (i.e., CA or RA) must establish a shared secret key in order to prove   that the end entity has possession of the private key.   Note that this need not impose any restrictions on the keys that can   be certified by a given CA -- in particular, for Diffie-Hellman keys   the end entity may freely choose its algorithm parameters -- provided   that the CA can generate a short-term (or one-time) key pair with the   appropriate parameters when necessary.2.4 Root CA key update