Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4210

Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

Pages: 95
Proposed Standard
Errata
Obsoletes:  2510
Updated by:  671294809481
Part 1 of 5 – Pages 1 to 14
None   None   Next

Top   ToC   RFC4210 - Page 1
Network Working Group                                           C. Adams
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
Top   ToC   RFC4210 - Page 2
      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
Top   ToC   RFC4210 - Page 3
      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
Top   ToC   RFC4210 - Page 4
      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
Top   ToC   RFC4210 - Page 5

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.
Top   ToC   RFC4210 - Page 6
   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
Top   ToC   RFC4210 - Page 7
   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.
Top   ToC   RFC4210 - Page 8
   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.
Top   ToC   RFC4210 - Page 9
   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
        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.
Top   ToC   RFC4210 - Page 10
   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.
Top   ToC   RFC4210 - Page 11
     +---+     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.
Top   ToC   RFC4210 - Page 12
   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.
Top   ToC   RFC4210 - Page 13
           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.
Top   ToC   RFC4210 - Page 14
   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.



(page 14 continued on part 2)

Next Section