must be designed so that end entities will use the same protocol
regardless of whether the communication is with an RA or CA.
Naturally, the end entity must use the correct RA of CA public
key to protect the communication.
12. 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 4.3 for details of the in-
band methods defined for the PKIX-CMP (i.e., Certificate
Management Protocol) messages.
3.1.3. 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.
+---+ 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.
3. Certification: various operations result in the creation of new
certificates:
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).
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. certificate update: As certificates expire, they may be
"refreshed" if nothing relevant in the environment has
changed.
4. CA key pair update: As with end entities, CA key pairs need
to be updated regularly; however, different mechanisms are
required.
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.
1. 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.
2. 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.
3. Note 3. Issuance of cross-certificates may be, but is
not necessarily, mutual; that is, two CAs may issue
cross-certificates for each other.
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:
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 5.3.13 to 5.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).
2. CRL publication: As for certificate publication.
5. Recovery operations: some PKI management operations are used when
an end entity has "lost" its PSE:
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:
1. revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
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) that
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.
4. Assumptions and Restrictions
4.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).
4.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 that a CA
may implement and the variation in the types of end entity which can
occur.
However, we can 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 that will arise in real use, whilst the optional
schemes are available for special cases that arise less frequently.
In this way, we achieve a balance between flexibility and ease of
implementation.
We will now describe the classification of initial
registration/certification schemes.
4.2.1. Criteria Used
4.2.1.1. Initiation of Registration/Certification
In terms of the PKI messages that 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.
4.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.
Thus, we can 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).
4.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 a
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).
Thus, there are three possibilities for the location of "key
generation": the end entity, an RA, or a CA.
4.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.
4.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 (Section 4.2.2.2). Any entity MAY
additionally support other schemes, if desired.
4.2.2.1. Centralized Scheme
In terms of the classification above, this scheme is, in some ways,
the simplest possible, where:
o initiation occurs at the certifying CA;
o no on-line message authentication is required;
o "key generation" occurs at the certifying CA (see Section
4.2.1.3);
o 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 to decrypt any encrypted values.
4.2.2.2. Basic Authenticated Scheme
In terms of the classification above, this scheme is where:
o initiation occurs at the end entity;
o message authentication is REQUIRED;
o "key generation" occurs at the end entity (see Section 4.2.1.3);
o 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.)
4.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 the
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 that 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).
4.3.1. Signature Keys
For signature keys, the end entity can sign a value to prove
possession of the private key.
4.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 5.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 that 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 that can only be used by the
intended end entity.
This specification encourages use of the indirect method because it
requires no extra messages to be sent (i.e., the proof can be
demonstrated using the {request, response, confirmation} triple of
messages).
4.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.
4.4. Root CA Key Update
This discussion only applies to CAs that are directly trusted by some
end entities. Self-signed CAs SHALL be considered as directly
trusted CAs. Recognizing whether a non-self-signed CA is supposed to
be directly trusted for some end entities is a matter of CA policy
and is thus beyond the scope of this document.
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