Network Working Group C. Adams
Request for Comments: 4210 University of Ottawa
Obsoletes: 2510 S. Farrell
Category: Standards Track Trinity College Dublin
September 2005 Internet X.509 Public Key Infrastructure
Certificate Management Protocol (CMP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2005).
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for X.509v3 certificate creation and management. CMP
provides on-line interactions between PKI components, including an
exchange between a Certification Authority (CA) and a client system.
Table of Contents
1. Introduction ....................................................52. Requirements ....................................................53. PKI Management Overview .........................................53.1. PKI Management Model .......................................63.1.1. Definitions of PKI Entities .........................188.8.131.52. Subjects and End Entities ..................184.108.40.206. Certification Authority ....................220.127.116.11. Registration Authority .....................73.1.2. PKI Management Requirements .........................83.1.3. PKI Management Operations ..........................104. Assumptions and Restrictions ...................................144.1. End Entity Initialization .................................14
This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocol (CMP). Protocol messages are
defined for certificate creation and management. The term
"certificate" in this document refers to an X.509v3 Certificate as
defined in [X509].
This specification obsoletes RFC 2510. This specification differs
from RFC 2510 in the following areas:
The PKI management message profile section is split to two
appendices: the required profile and the optional profile. Some
of the formerly mandatory functionality is moved to the optional
The message confirmation mechanism has changed substantially.
A new polling mechanism is introduced, deprecating the old polling
method at the CMP transport level.
The CMP transport protocol issues are handled in a separate
document [CMPtrans], thus the Transports section is removed.
A new implicit confirmation method is introduced to reduce the
number of protocol messages exchanged in a transaction.
The new specification contains some less prominent protocol
enhancements and improved explanatory text on several issues.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
3. PKI Management Overview
The PKI must be structured to be consistent with the types of
individuals who must administer it. Providing such administrators
with unbounded choices not only complicates the software required,
but also increases the chances that a subtle mistake by an
administrator or software developer will result in broader
compromise. Similarly, restricting administrators with cumbersome
mechanisms will cause them not to use the PKI.
Management protocols are REQUIRED to support on-line interactions
between Public Key Infrastructure (PKI) components. For example, a
management protocol might be used between a Certification Authority
(CA) and a client system with which a key pair is associated, or
between two CAs that issue cross-certificates for each other.
3.1. PKI Management Model
Before specifying particular message formats and procedures, we first
define the entities involved in PKI management and their interactions
(in terms of the PKI management functions required). We then group
these functions in order to accommodate different identifiable types
of end entities.
3.1.1. Definitions of PKI Entities
The entities involved in PKI management include the end entity (i.e.,
the entity to whom the certificate is issued) and the certification
authority (i.e., the entity that issues the certificate). A
registration authority MAY also be involved in PKI management.
18.104.22.168. Subjects and End Entities
The term "subject" is used here to refer to the entity to whom the
certificate is issued, typically named in the subject or
subjectAltName field of a certificate. When we wish to distinguish
the tools and/or software used by the subject (e.g., a local
certificate management module), we will use the term "subject
equipment". In general, the term "end entity" (EE), rather than
"subject", is preferred in order to avoid confusion with the field
name. It is important to note that the end entities here will
include not only human users of applications, but also applications
themselves (e.g., for IP security). This factor influences the
protocols that the PKI management operations use; for example,
application software is far more likely to know exactly which
certificate extensions are required than are human users. PKI
management entities are also end entities in the sense that they are
sometimes named in the subject or subjectAltName field of a
certificate or cross-certificate. Where appropriate, the term "end-
entity" will be used to refer to end entities who are not PKI
All end entities require secure local access to some information --
at a minimum, their own name and private key, the name of a CA that
is directly trusted by this entity, and that CA's public key (or a
fingerprint of the public key where a self-certified version is
available elsewhere). Implementations MAY use secure local storage
for more than this minimum (e.g., the end entity's own certificate or
application-specific information). The form of storage will also
vary -- from files to tamper-resistant cryptographic tokens. The
information stored in such local, trusted storage is referred to here
as the end entity's Personal Security Environment (PSE).
Though PSE formats are beyond the scope of this document (they are
very dependent on equipment, et cetera), a generic interchange format
for PSEs is defined here: a certification response message MAY be
22.214.171.124. Certification Authority
The certification authority (CA) may or may not actually be a real
"third party" from the end entity's point of view. Quite often, the
CA will actually belong to the same organization as the end entities
Again, we use the term "CA" to refer to the entity named in the
issuer field of a certificate. When it is necessary to distinguish
the software or hardware tools used by the CA, we use the term "CA
The CA equipment will often include both an "off-line" component and
an "on-line" component, with the CA private key only available to the
"off-line" component. This is, however, a matter for implementers
(though it is also relevant as a policy issue).
We use the term "root CA" to indicate a CA that is directly trusted
by an end entity; that is, securely acquiring the value of a root CA
public key requires some out-of-band step(s). This term is not meant
to imply that a root CA is necessarily at the top of any hierarchy,
simply that the CA in question is trusted directly.
A "subordinate CA" is one that is not a root CA for the end entity in
question. Often, a subordinate CA will not be a root CA for any
entity, but this is not mandatory.
126.96.36.199. Registration Authority
In addition to end-entities and CAs, many environments call for the
existence of a Registration Authority (RA) separate from the
Certification Authority. The functions that the registration
authority may carry out will vary from case to case but MAY include
personal authentication, token distribution, revocation reporting,
name assignment, key generation, archival of key pairs, et cetera.
This document views the RA as an OPTIONAL component: when it is not
present, the CA is assumed to be able to carry out the RA's functions
so that the PKI management protocols are the same from the end-
entity's point of view.
Again, we distinguish, where necessary, between the RA and the tools
used (the "RA equipment").
Note that an RA is itself an end entity. We further assume that all
RAs are in fact certified end entities and that RAs have private keys
that are usable for signing. How a particular CA equipment
identifies some end entities as RAs is an implementation issue (i.e.,
this document specifies no special RA certification operation). We
do not 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.
3.1.2. PKI Management Requirements
The protocols given here meet the following requirements on PKI
1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509
2. It must be possible to regularly update any key pair without
affecting any other key pair.
3. The use of confidentiality in PKI management protocols must be
kept to a minimum in order to ease acceptance in environments
where strong confidentiality might cause regulatory problems.
4. PKI management protocols must allow the use of different
industry-standard cryptographic algorithms (specifically
including RSA, DSA, MD5, and 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).
5. 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.
6. 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.
7. 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.
8. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including mail, http,
TCP/IP and ftp.
9. 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).
10. 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 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
11. 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
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
+---+ 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
| 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
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
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
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
4. CA key pair update: As with end entities, CA key pairs need
to be updated regularly; however, different mechanisms are
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
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.