Request for Comments: 4210 University of Ottawa
Obsoletes: 2510 S. Farrell
Category: Standards Track Trinity College Dublin
T. Kause
SSH
T. Mononen
SafeNet
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 Notice
Copyright (C) The Internet Society (2005).
Abstract
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 ....................................................5
2. Requirements ....................................................5
3. PKI Management Overview .........................................5
3.1. PKI Management Model .......................................6
3.1.1. Definitions of PKI Entities .........................6
3.1.1.1. Subjects and End Entities ..................6
3.1.1.2. Certification Authority ....................7
3.1.1.3. Registration Authority .....................7
3.1.2. PKI Management Requirements .........................8
3.1.3. PKI Management Operations ..........................10
4. Assumptions and Restrictions ...................................14
4.1. End Entity Initialization .................................14
4.2. Initial Registration/Certification ........................14
4.2.1. Criteria Used ......................................15
4.2.1.1. Initiation of Registration/Certification ..15
4.2.1.2. End Entity Message Origin Authentication ..15
4.2.1.3. Location of Key Generation ................15
4.2.1.4. Confirmation of Successful Certification ..16
4.2.2. Mandatory Schemes ..................................16
4.2.2.1. Centralized Scheme ........................16
4.2.2.2. Basic Authenticated Scheme ................17
4.3. Proof-of-Possession (POP) of Private Key ..................17
4.3.1. Signature Keys .....................................18
4.3.2. Encryption Keys ....................................18
4.3.3. Key Agreement Keys .................................19
4.4. Root CA Key Update ........................................19
4.4.1. CA Operator Actions ................................20
4.4.2. Verifying Certificates .............................21
4.4.2.1. Verification in Cases 1, 4, 5, and 8 ......22
4.4.2.2. Verification in Case 2 ....................22
4.4.2.3. Verification in Case 3 ....................23
4.4.2.4. Failure of Verification in Case 6 .........23
4.4.2.5. Failure of Verification in Case 7 .........23
4.4.3. Revocation - Change of CA Key ......................23
5. Data Structures ................................................24
5.1. Overall PKI Message .......................................24
5.1.1. PKI Message Header .................................24
5.1.1.1. ImplicitConfirm ...........................27
5.1.1.2. ConfirmWaitTime ...........................27
5.1.2. PKI Message Body ...................................27
5.1.3. PKI Message Protection .............................28
5.1.3.1. Shared Secret Information .................29
5.1.3.2. DH Key Pairs ..............................30
5.1.3.3. Signature .................................30
5.1.3.4. Multiple Protection .......................30
5.2. Common Data Structures ....................................31
5.2.1. Requested Certificate Contents .....................31
5.2.2. Encrypted Values ...................................31
5.2.3. Status codes and Failure Information for
PKI Messages .......................................32
5.2.4. Certificate Identification .........................33
5.2.5. Out-of-band root CA Public Key .....................33
5.2.6. Archive Options ....................................34
5.2.7. Publication Information ............................34
5.2.8. Proof-of-Possession Structures .....................34
5.2.8.1. Inclusion of the Private Key ..............35
5.2.8.2. Indirect Method ...........................35
5.2.8.3. Challenge-Response Protocol ...............35
5.2.8.4. Summary of PoP Options ....................37
5.3. Operation-Specific Data Structures ........................38
5.3.1. Initialization Request .............................38
5.3.2. Initialization Response ............................39
5.3.3. Certification Request ..............................39
5.3.4. Certification Response .............................39
5.3.5. Key Update Request Content .........................40
5.3.6. Key Update Response Content ........................41
5.3.7. Key Recovery Request Content .......................41
5.3.8. Key Recovery Response Content ......................41
5.3.9. Revocation Request Content .........................41
5.3.10. Revocation Response Content .......................42
5.3.11. Cross Certification Request Content ...............42
5.3.12. Cross Certification Response Content ..............42
5.3.13. CA Key Update Announcement Content ................42
5.3.14. Certificate Announcement ..........................43
5.3.15. Revocation Announcement ...........................43
5.3.16. CRL Announcement ..................................43
5.3.17. PKI Confirmation Content ..........................43
5.3.18. Certificate Confirmation Content ..................44
5.3.19. PKI General Message Content .......................44
5.3.19.1. CA Protocol Encryption Certificate .......44
5.3.19.2. Signing Key Pair Types ...................45
5.3.19.3. Encryption/Key Agreement Key Pair Types ..45
5.3.19.4. Preferred Symmetric Algorithm ............45
5.3.19.5. Updated CA Key Pair ......................45
5.3.19.6. CRL ......................................46
5.3.19.7. Unsupported Object Identifiers ...........46
5.3.19.8. Key Pair Parameters ......................46
5.3.19.9. Revocation Passphrase ....................46
5.3.19.10. ImplicitConfirm .........................46
5.3.19.11. ConfirmWaitTime .........................47
5.3.19.12. Original PKIMessage .....................47
5.3.19.13. Supported Language Tags .................47
5.3.20. PKI General Response Content ......................47
5.3.21. Error Message Content .............................47
5.3.22. Polling Request and Response ......................48
6. Mandatory PKI Management Functions .............................51
6.1. Root CA Initialization ....................................51
6.2. Root CA Key Update ........................................51
6.3. Subordinate CA Initialization .............................51
6.4. CRL production ............................................52
6.5. PKI Information Request ...................................52
6.6. Cross Certification .......................................52
6.6.1. One-Way Request-Response Scheme: ...................52
6.7. End Entity Initialization .................................54
6.7.1. Acquisition of PKI Information .....................54
6.7.2. Out-of-Band Verification of Root-CA Key ............55
6.8. Certificate Request .......................................55
6.9. Key Update ................................................55
7. Version Negotiation ............................................56
7.1. Supporting RFC 2510 Implementations .......................56
7.1.1. Clients Talking to RFC 2510 Servers ................56
7.1.2. Servers Receiving Version cmp1999 PKIMessages ......57
8. Security Considerations ........................................57
8.1. Proof-Of-Possession with a Decryption Key .................57
8.2. Proof-Of-Possession by Exposing the Private Key ...........57
8.3. Attack Against Diffie-Hellman Key Exchange ................57
9. IANA Considerations ............................................58
Normative References ..............................................58
Informative References ............................................59
A. Reasons for the Presence of RAs ................................61
B. The Use of Revocation Passphrase ...............................61
C. Request Message Behavioral Clarifications ......................63
D. PKI Management Message Profiles (REQUIRED) .....................65
D.1. General Rules for Interpretation of These Profiles ........65
D.2. Algorithm Use Profile .....................................66
D.3. Proof-of-Possession Profile ...............................68
D.4. Initial Registration/Certification (Basic
Authenticated Scheme) .....................................68
D.5. Certificate Request .......................................74
D.6. Key Update Request ........................................75
E. PKI Management Message Profiles (OPTIONAL) .....................75
E.1. General Rules for Interpretation of These Profiles ........76
E.2. Algorithm Use Profile .....................................76
E.3. Self-Signed Certificates ..................................76
E.4. Root CA Key Update ........................................77
E.5. PKI Information Request/Response ..........................77
E.6. Cross Certification Request/Response (1-way) ..............79
E.7. In-Band Initialization Using External Identity
Certificate ..............................................82
F. Compilable ASN.1 Definitions ...................................83
G. Acknowledgements ...............................................93
1. Introduction
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
profile.
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.
2. Requirements
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.
3.1.1.1. 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
management entities.
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
used.
3.1.1.2. 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
it supports.
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
equipment".
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.
3.1.1.3. 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
management
1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509
standards.
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
cryptographic equipment).
11. The functions of an RA may, in some implementations or
environments, be carried out by the CA itself. The protocols