From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5272.txt | 4651 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 4651 insertions(+) create mode 100644 doc/rfc/rfc5272.txt (limited to 'doc/rfc/rfc5272.txt') diff --git a/doc/rfc/rfc5272.txt b/doc/rfc/rfc5272.txt new file mode 100644 index 0000000..ba5d7b5 --- /dev/null +++ b/doc/rfc/rfc5272.txt @@ -0,0 +1,4651 @@ + + + + + + +Network Working Group J. Schaad +Request for Comments: 5272 Soaring Hawk Consulting +Obsoletes: 2797 M. Myers +Category: Standards Track TraceRoute Security, Inc. + June 2008 + + + Certificate Management over CMS (CMC) + +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. + +Abstract + + This document defines the base syntax for CMC, a Certificate + Management protocol using the Cryptographic Message Syntax (CMS). + This protocol addresses two immediate needs within the Internet + Public Key Infrastructure (PKI) community: + + 1. The need for an interface to public key certification products + and services based on CMS and PKCS #10 (Public Key Cryptography + Standard), and + + 2. The need for a PKI enrollment protocol for encryption only keys + due to algorithm or hardware design. + + CMC also requires the use of the transport document and the + requirements usage document along with this document for a full + definition. + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 1] + +RFC 5272 CMC: Structures June 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5 + 1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5 + 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9 + 3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10 + 3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12 + 3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13 + 3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14 + 3.2.1.2. Certification Request Formats . . . . . . . . . . 15 + 3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16 + 3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17 + 3.2.1.2.3. Other Certification Request . . . . . . . . . 18 + 3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19 + 3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19 + 3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20 + 3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20 + 3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20 + 3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21 + 3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21 + 3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22 + 4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23 + 4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23 + 4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24 + 4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24 + 5. Application of Encryption to a PKI Request/Response . . . . . 25 + 6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28 + 6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28 + 6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30 + 6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31 + 6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32 + 6.2. Identification and Identity Proof Controls . . . . . . . . 33 + 6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33 + 6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35 + 6.2.3. Identification Control . . . . . . . . . . . . . . . . 35 + 6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36 + 6.3. Linking Identity and POP Information . . . . . . . . . . . 36 + 6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37 + 6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37 + 6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38 + 6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38 + 6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39 + + + +Schaad & Myers Standards Track [Page 2] + +RFC 5272 CMC: Structures June 2008 + + + 6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39 + 6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40 + 6.5. RA Certificate Modification Controls . . . . . . . . . . . 40 + 6.5.1. Modify Certification Request Control . . . . . . . . . 41 + 6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42 + 6.6. Transaction Identifier Control and Sender and + Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44 + 6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45 + 6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48 + 6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49 + 6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49 + 6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50 + 6.12. Registration and Response Information Controls . . . . . . 52 + 6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53 + 6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53 + 6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54 + 6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55 + 6.17. Batch Request and Response Controls . . . . . . . . . . . 56 + 6.18. Publication Information Control . . . . . . . . . . . . . 57 + 6.19. Control Processed Control . . . . . . . . . . . . . . . . 58 + 7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59 + 7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60 + 7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 61 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 63 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 63 + Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65 + Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74 + B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74 + B.2. Single Certification Request, But Modified by RA . . . . . 75 + B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78 + Appendix C. Production of Diffie-Hellman Public Key + Certification Requests . . . . . . . . . . . . . . . 81 + C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 81 + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 3] + +RFC 5272 CMC: Structures June 2008 + + +1. Introduction + + This document defines the base syntax for CMC, a Certificate + Management protocol using the Cryptographic Message Syntax (CMS). + This protocol addresses two immediate needs within the Internet PKI + community: + + 1. The need for an interface to public key certification products + and services based on CMS and PKCS #10, and + + 2. The need for a PKI enrollment protocol for encryption only keys + due to algorithm or hardware design. + + A small number of additional services are defined to supplement the + core certification request service. + +1.1. Protocol Requirements + + The protocol must be based as much as possible on the existing CMS, + PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format) + [CRMF] specifications. + + The protocol must support the current industry practice of a PKCS #10 + certification request followed by a PKCS#7 "certs-only" response as a + subset of the protocol. + + The protocol must easily support the multi-key enrollment protocols + required by S/MIME and other groups. + + The protocol must supply a way of doing all enrollment operations in + a single round-trip. When this is not possible the number of + round-trips is to be minimized. + + The protocol must be designed such that all key generation can occur + on the client. + + Support must exist for the mandatory algorithms used by S/MIME. + Support should exist for all other algorithms cited by the S/MIME + core documents. + + The protocol must contain Proof-of-Possession (POP) methods. + Optional provisions for multiple-round-trip POP will be made if + necessary. + + The protocol must support deferred and pending responses to + enrollment requests for cases where external procedures are required + to issue a certificate. + + + + +Schaad & Myers Standards Track [Page 4] + +RFC 5272 CMC: Structures June 2008 + + + The protocol must support arbitrary chains of Registration + Authorities (RAs) as intermediaries between certification requesters + and Certification Authorities (CAs). + +1.2. Requirements Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.3. Changes since RFC 2797 + + We have done a major overhaul on the layout of the document. This + included two different steps. Firstly we removed some sections from + the document and moved them to two other documents. Information on + how to transport our messages are now found in [CMC-TRANS]. + Information on which controls and sections of this document must be + implemented along with which algorithms are required can now be found + in [CMC-COMPL]. + + A number of new controls have been added in this version: + + Extended CMC Status Info Section 6.1.1 + + Publish Trust Anchors Section 6.15 + + Authenticate Data Section 6.16 + + Batch Request and Response Processing Section 6.17 + + Publication Information Section 6.18 + + Modify Certification Request Section 6.5.1 + + Control Processed Section 6.19 + + Identity Proof Section 6.2.2 + + Identity POP Link Witness V2 Section 6.3.1.1 + +2. Protocol Overview + + A PKI enrollment transaction in this specification is generally + composed of a single round-trip of messages. In the simplest case a + PKI enrollment request, henceforth referred to as a PKI Request, is + sent from the client to the server and a PKI enrollment response, + henceforth referred to as a PKI Response, is then returned from the + + + + +Schaad & Myers Standards Track [Page 5] + +RFC 5272 CMC: Structures June 2008 + + + server to the client. In more complicated cases, such as delayed + certificate issuance, more than one round-trip is required. + + This specification defines two PKI Request types and two PKI Response + types. + + PKI Requests are formed using either the PKCS #10 or CRMF structure. + The two PKI Requests are: + + Simple PKI Request: the bare PKCS #10 (in the event that no other + services are needed), and + + Full PKI Request: one or more PKCS #10, CRMF or Other Request + Messages structures wrapped in a CMS encapsulation as part of a + PKIData. + + PKI Responses are based on SignedData or AuthenticatedData [CMS]. + The two PKI Responses are + + Simple PKI Response: a "certs-only" SignedData (in the event no + other services are needed), or + + Full PKI Response: a PKIResponse content type wrapped in a + SignedData. + + No special services are provided for either renewal (i.e., a new + certificate with the same key) or rekey (i.e., a new certificate with + a new key) of client certificates. Instead renewal and rekey + requests look the same as any certification request, except that the + identity proof is supplied by existing certificates from a trusted + CA. (This is usually the same CA, but could be a different CA in the + same organization where naming is shared.) + + No special services are provided to distinguish between a rekey + request and a new certification request (generally for a new + purpose). A control to unpublish a certificate would normally be + included in a rekey request, and be omitted in a new certification + request. CAs or other publishing agents are also expected to have + policies for removing certificates from publication either based on + new certificates being added or the expiration or revocation of a + certificate. + + A provision exists for RAs to participate in the protocol by taking + PKI Requests, wrapping them in a second layer of PKI Request with + additional requirements or statements from the RA and then passing + this new expanded PKI Request on to the CA. + + + + + +Schaad & Myers Standards Track [Page 6] + +RFC 5272 CMC: Structures June 2008 + + + This specification makes no assumptions about the underlying + transport mechanism. The use of CMS does not imply an email-based + transport. Several different possible transport methods are defined + in [CMC-TRANS]. + + Optional services available through this specification are + transaction management, replay detection (through nonces), deferred + certificate issuance, certificate revocation requests and + certificate/certificate revocation list (CRL) retrieval. + +2.1. Terminology + + There are several different terms, abbreviations, and acronyms used + in this document. These are defined here, in no particular order, + for convenience and consistency of usage: + + End-Entity (EE) refers to the entity that owns a key pair and for + whom a certificate is issued. + + Registration Authority (RA) or Local RA (LRA) refers to an entity + that acts as an intermediary between the EE and the CA. Multiple + RAs can exist between the end-entity and the Certification + Authority. RAs may perform additional services such as key + generation or key archival. This document uses the term RA for + both RA and LRA. + + Certification Authority (CA) refers to the entity that issues + certificates. + + Client refers to an entity that creates a PKI Request. In this + document, both RAs and EEs can be clients. + + Server refers to the entities that process PKI Requests and create + PKI Responses. In this document, both CAs and RAs can be servers. + + PKCS #10 refers to the Public Key Cryptography Standard #10 + [PKCS10], which defines a certification request syntax. + + CRMF refers to the Certificate Request Message Format RFC [CRMF]. + CMC uses this certification request syntax defined in this + document as part of the protocol. + + CMS refers to the Cryptographic Message Syntax RFC [CMS]. This + document provides for basic cryptographic services including + encryption and signing with and without key management. + + + + + + +Schaad & Myers Standards Track [Page 7] + +RFC 5272 CMC: Structures June 2008 + + + PKI Request/Response refers to the requests/responses described in + this document. PKI Requests include certification requests, + revocation requests, etc. PKI Responses include certs-only + messages, failure messages, etc. + + Proof-of-Identity refers to the client proving they are who they say + that they are to the server. + + Enrollment or certification request refers to the process of a + client requesting a certificate. A certification request is a + subset of the PKI Requests. + + Proof-of-Possession (POP) refers to a value that can be used to + prove that the private key corresponding to a public key is in the + possession and can be used by an end-entity. The different types + of POP are: + + Signature provides the required POP by a signature operation over + some data. + + Direct provides the required POP operation by an encrypted + challenge/response mechanism. + + Indirect provides the required POP operation by returning the + issued certificate in an encrypted state. (This method is not + used by CMC.) + + Publish provides the required POP operation by providing the + private key to the certificate issuer. (This method is not + currently used by CMC. It would be used by Key Generation or + Key Escrow extensions.) + + Attested provides the required POP operation by allowing a + trusted entity to assert that the POP has been proven by one of + the above methods. + + Object IDentifier (OID) is a primitive type in Abstract Syntax + Notation One (ASN.1). + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 8] + +RFC 5272 CMC: Structures June 2008 + + +2.2. Protocol Requests/Responses + + Figure 1 shows the Simple PKI Requests and Responses. The contents + of Simple PKI Request and Response are detailed in Sections 3.1 and + 4.1. + + Simple PKI Request Simple PKI Response + ------------------------- -------------------------- + + +----------+ +------------------+ + | PKCS #10 | | CMS ContentInfo | + +----------+--------------+ +------------------+------+ + | Certification Request | | CMS Signed Data, | + | | | no SignerInfo | + | Subject Name | | + | Subject Public Key Info | | SignedData contains one | + | (K_PUB) | | or more certificates in | + | Attributes | | the certificates field | + | | | Relevant CA certs and | + +-----------+-------------+ | CRLs can be included | + | signed with | | as well. | + | matching | | | + | K_PRIV | | encapsulatedContentInfo | + +-------------+ | is absent. | + +--------------+----------+ + | unsigned | + +----------+ + + Figure 1: Simple PKI Requests and Responses + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 9] + +RFC 5272 CMC: Structures June 2008 + + + Figure 2 shows the Full PKI Requests and Responses. The contents of + the Full PKI Request and Response are detailed in Sections 3.2 and + 4.2. + + Full PKI Request Full PKI Response + ----------------------- ------------------------ + +----------------+ +----------------+ + | CMS ContentInfo| | CMS ContentInfo| + | CMS SignedData | | CMS SignedData | + | or Auth Data | | or Auth Data | + | object | | object | + +----------------+--------+ +----------------+--------+ + | | | | + | PKIData | | PKIResponseBody | + | | | | + | Sequence of: | | Sequence of: | + | * | | * | + | *| | * | + | * | | * | + | * | | | + | | | where * == zero or more | + | where * == zero or more | | | + | | | All certificates issued | + | Certification requests | | as part of the response | + | are CRMF, PKCS #10, or | | are included in the | + | Other. | | "certificates" field | + | | | of the SignedData. | + +-------+-----------------+ | Relevant CA certs and | + | signed (keypair | | CRLs can be included as | + | used may be pre-| | well. | + | existing or | | | + | identified in | +---------+---------------+ + | the request) | | signed by the | + +-----------------+ | CA or an LRA | + +---------------+ + + Figure 2: Full PKI Requests and Responses + +3. PKI Requests + + Two types of PKI Requests exist. This section gives the details for + both types. + +3.1. Simple PKI Request + + A Simple PKI Request uses the PKCS #10 syntax CertificationRequest + [PKCS10]. + + + + +Schaad & Myers Standards Track [Page 10] + +RFC 5272 CMC: Structures June 2008 + + + When a server processes a Simple PKI Request, the PKI Response + returned is: + + Simple PKI Response on success. + + Full PKI Response on failure. The server MAY choose not to return a + PKI Response in this case. + + The Simple PKI Request MUST NOT be used if a proof-of-identity needs + to be included. + + The Simple PKI Request cannot be used if the private key is not + capable of producing some type of signature (i.e., Diffie-Hellman + (DH) keys can use the signature algorithms in [DH-POP] for production + of the signature). + + The Simple PKI Request cannot be used for any of the advanced + services specified in this document. + + The client MAY incorporate one or more X.509v3 extensions in any + certification request based on PKCS #10 as an ExtensionReq attribute. + The ExtensionReq attribute is defined as: + + ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension + + where Extension is imported from [PKIXCERT] and ExtensionReq is + identified by: + + id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) 14} + + Servers MUST be able to process all extensions defined, but not + prohibited, in [PKIXCERT]. Servers are not required to be able to + process other X.509v3 extensions transmitted using this protocol, nor + are they required to be able to process private extensions. Servers + are not required to put all client-requested extensions into a + certificate. Servers are permitted to modify client-requested + extensions. Servers MUST NOT alter an extension so as to invalidate + the original intent of a client-requested extension. (For example, + changing key usage from keyAgreement to digitalSignature.) If a + certification request is denied due to the inability to handle a + requested extension and a PKI Response is returned, the server MUST + return a PKI Response with a CMCFailInfo value with the value + unsupportedExt. + + + + + + + +Schaad & Myers Standards Track [Page 11] + +RFC 5272 CMC: Structures June 2008 + + +3.2. Full PKI Request + + The Full PKI Request provides the most functionality and flexibility. + + The Full PKI Request is encapsulated in either a SignedData or an + AuthenticatedData with an encapsulated content type of id-cct-PKIData + (Section 3.2.1). + + When a server processes a Full PKI Request, a PKI Response MUST be + returned. The PKI Response returned is: + + Simple PKI Response if the enrollment was successful and only + certificates are returned. (A CMCStatusInfoV2 control with + success is implied.) + + Full PKI Response if the enrollment was successful and information + is returned in addition to certificates, if the enrollment is + pending, or if the enrollment failed. + + If SignedData is used, the signature can be generated using either + the private key material of an embedded signature certification + request (i.e., included in the TaggedRequest tcr or crm fields) or a + previously certified signature key. If the private key of a + signature certification request is used, then: + + a. The certification request containing the corresponding public key + MUST include a Subject Key Identifier extension. + + b. The subjectKeyIdentifier form of the signerIdentifier in + SignerInfo MUST be used. + + c. The value of the subjectKeyIdentifier form of SignerInfo MUST be + the Subject Key Identifier specified in the corresponding + certification request. (The subjectKeyIdentifier form of + SignerInfo is used here because no certificates have yet been + issued for the signing key.) If the request key is used for + signing, there MUST be only one SignerInfo in the SignedData. + + If AuthenticatedData is used, then: + + a. The Password Recipient Info option of RecipientInfo MUST be used. + + b. A randomly generated key is used to compute the Message + Authentication Code (MAC) value on the encapsulated content. + + c. The input for the key derivation algorithm is a concatenation of + the identifier (encoded as UTF8) and the shared-secret. + + + + +Schaad & Myers Standards Track [Page 12] + +RFC 5272 CMC: Structures June 2008 + + + When creating a PKI Request to renew or rekey a certificate: + + a. The Identification and Identity Proof controls are absent. The + same information is provided by the use of an existing + certificate from a CA when signing the PKI Request. In this + case, the CA that issued the original certificate and the CA the + request is made to will usually be the same, but could have a + common operator. + + b. CAs and RAs can impose additional restrictions on the signing + certificate used. They may require that the most recently issued + signing certificate for a client be used. + + c. Some CAs may prevent renewal operations (i.e., reuse of the same + keys). In this case the CA MUST return a PKI Response with + noKeyReuse as the CMCFailInfo failure code. + +3.2.1. PKIData Content Type + + The PKIData content type is used for the Full PKI Request. A PKIData + content type is identified by: + + id-cct-PKIData ::= {id-pkix id-cct(12) 2 } + + The ASN.1 structure corresponding to the PKIData content type is: + + PKIData ::= SEQUENCE { + controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, + reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, + cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, + otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg + } + + The fields in PKIData have the following meaning: + + controlSequence is a sequence of controls. The controls defined in + this document are found in Section 6. Controls can be defined by + other parties. Details on the TaggedAttribute structure can be + found in Section 3.2.1.1. + + reqSequence is a sequence of certification requests. The + certification requests can be a CertificationRequest (PKCS #10), a + CertReqMsg (CRMF), or an externally defined PKI request. Full + details are found in Section 3.2.1.2. If an externally defined + certification request is present, but the server does not + understand the certification request (or will not process it), a + CMCStatus of noSupport MUST be returned for the certification + request item and no other certification requests are processed. + + + +Schaad & Myers Standards Track [Page 13] + +RFC 5272 CMC: Structures June 2008 + + + cmsSequence is a sequence of [CMS] message objects. See + Section 3.2.1.3 for more details. + + otherMsgSequence is a sequence of arbitrary data objects. Data + objects placed here are referred to by one or more controls. This + allows for controls to use large amounts of data without the data + being embedded in the control. See Section 3.2.1.4 for more + details. + + All certification requests encoded into a single PKIData SHOULD be + for the same identity. RAs that batch process (see Section 6.17) are + expected to place the PKI Requests received into the cmsSequence of a + PKIData. + + Processing of the PKIData by a recipient is as follows: + + 1. All controls should be examined and processed in an appropriate + manner. The appropriate processing is to complete processing at + this time, to ignore the control, or to place the control on a + to-do list for later processing. Controls can be processed in + any order; the order in the sequence is not significant. + + 2. Items in the reqSequence are not referenced by a control. These + items, which are certification requests, also need to be + processed. As with controls, the appropriate processing can be + either immediate processing or addition to a to-do list for later + processing. + + 3. Finally, the to-do list is processed. In many cases, the to-do + list will be ordered by grouping specific tasks together. + + No processing is required for cmsSequence or otherMsgSequence members + of PKIData if they are present and are not referenced by a control. + In this case, the cmsSequence and otherMsgSequence members are + ignored. + +3.2.1.1. Control Syntax + + The actions to be performed for a PKI Request/Response are based on + the included controls. Each control consists of an object identifier + and a value based on the object identifier. + + + + + + + + + + +Schaad & Myers Standards Track [Page 14] + +RFC 5272 CMC: Structures June 2008 + + + The syntax of a control is: + + TaggedAttribute ::= SEQUENCE { + bodyPartID BodyPartID, + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue + } + + AttributeValue ::= ANY + + The fields in TaggedAttribute have the following meaning: + + bodyPartID is a unique integer that identifies this control. + + attrType is the OID that identifies the control. + + attrValues is the data values used in processing the control. The + structure of the data is dependent on the specific + control. + + The final server MUST fail the processing of an entire PKIData if any + included control is not recognized, that control is not already + marked as processed by a Control Processed control (see Section 6.19) + and no other error is generated. The PKI Response MUST include a + CMCFailInfo value with the value badRequest and the bodyList MUST + contain the bodyPartID of the invalid or unrecognized control(s). A + server is the final server if and only if it is not passing the PKI + Request on to another server. A server is not considered to be the + final server if the server would have passed the PKI Request on, but + instead it returned a processing error. + + The controls defined by this document are found in Section 6. + +3.2.1.2. Certification Request Formats + + Certification Requests are based on PKCS #10, CRMF, or Other Request + formats. Section 3.2.1.2.1 specifies the requirements for clients + and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the + requirements for clients and servers dealing with CRMF. + Section 3.2.1.2.3 specifies the requirements for clients and servers + dealing with Other Request. + + + + + + + + + + +Schaad & Myers Standards Track [Page 15] + +RFC 5272 CMC: Structures June 2008 + + + TaggedRequest ::= CHOICE { + tcr [0] TaggedCertificationRequest, + crm [1] CertReqMsg, + orm [2] SEQUENCE { + bodyPartID BodyPartID, + requestMessageType OBJECT IDENTIFIER, + requestMessageValue ANY DEFINED BY requestMessageType + } + } + + The fields in TaggedRequest have the following meaning: + + tcr is a certification request that uses the PKCS #10 syntax. + Details on PKCS #10 are found in Section 3.2.1.2.1. + + crm is a certification request that uses the CRMF syntax. Details + on CRMF are found in Section 3.2.1.2.2. + + orm is an externally defined certification request. One example is + an attribute certification request. The fields of this structure + are: + + bodyPartID is the identifier number for this certification + request. Details on body part identifiers are found in + Section 3.2.2. + + requestMessageType identifies the other request type. These + values are defined outside of this document. + + requestMessageValue is the data associated with the other request + type. + +3.2.1.2.1. PKCS #10 Certification Syntax + + A certification request based on PKCS #10 uses the following ASN.1 + structure: + + TaggedCertificationRequest ::= SEQUENCE { + bodyPartID BodyPartID, + certificationRequest CertificationRequest + } + + The fields in TaggedCertificationRequest have the following meaning: + + bodyPartID is the identifier number for this certification request. + Details on body part identifiers are found in Section 3.2.2. + + + + + +Schaad & Myers Standards Track [Page 16] + +RFC 5272 CMC: Structures June 2008 + + + certificationRequest contains the PKCS-#10-based certification + request. Its fields are described in [PKCS10]. + + When producing a certification request based on PKCS #10, clients + MUST produce the certification request with a subject name and public + key. Some PKI products are operated using a central repository of + information to assign subject names upon receipt of a certification + request. To accommodate this mode of operation, the subject field in + a CertificationRequest MAY be NULL, but MUST be present. CAs that + receive a CertificationRequest with a NULL subject field MAY reject + such certification requests. If rejected and a PKI Response is + returned, the CA MUST return a PKI Response with the CMCFailInfo + value with the value badRequest. + +3.2.1.2.2. CRMF Certification Syntax + + A CRMF message uses the following ASN.1 structure (defined in [CRMF] + and included here for convenience): + + CertReqMsg ::= SEQUENCE { + certReq CertRequest, + popo ProofOfPossession OPTIONAL, + -- content depends upon key type + regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL } + + CertRequest ::= SEQUENCE { + certReqId INTEGER, -- ID for matching request and reply + certTemplate CertTemplate, --Selected fields of cert to be issued + controls Controls OPTIONAL } -- Attributes affecting issuance + + CertTemplate ::= SEQUENCE { + version [0] Version OPTIONAL, + serialNumber [1] INTEGER OPTIONAL, + signingAlg [2] AlgorithmIdentifier OPTIONAL, + issuer [3] Name OPTIONAL, + validity [4] OptionalValidity OPTIONAL, + subject [5] Name OPTIONAL, + publicKey [6] SubjectPublicKeyInfo OPTIONAL, + issuerUID [7] UniqueIdentifier OPTIONAL, + subjectUID [8] UniqueIdentifier OPTIONAL, + extensions [9] Extensions OPTIONAL } + + The fields in CertReqMsg are explained in [CRMF]. + + + + + + + + +Schaad & Myers Standards Track [Page 17] + +RFC 5272 CMC: Structures June 2008 + + + This document imposes the following additional restrictions on the + construction and processing of CRMF certification requests: + + When a Full PKI Request includes a CRMF certification request, + both the subject and publicKey fields in the CertTemplate MUST be + defined. The subject field can be encoded as NULL, but MUST be + present. + + When both CRMF and CMC controls exist with equivalent + functionality, the CMC control SHOULD be used. The CMC control + MUST override the CRMF control. + + The regInfo field MUST NOT be used on a CRMF certification + request. Equivalent functionality is provided in the CMC regInfo + control (Section 6.12). + + The indirect method of proving POP is not supported in this + protocol. One of the other methods (including the direct method + described in this document) MUST be used. The value of encrCert + in SubsequentMessage MUST NOT be used. + + Since the subject and publicKeyValues are always present, the + POPOSigningKeyInput MUST NOT be used when computing the value for + POPSigningKey. + + A server is not required to use all of the values suggested by the + client in the CRMF certification request. Servers MUST be able to + process all extensions defined, but not prohibited in [PKIXCERT]. + Servers are not required to be able to process other X.509v3 + extensions transmitted using this protocol, nor are they required to + be able to process private extensions. Servers are permitted to + modify client-requested extensions. Servers MUST NOT alter an + extension so as to invalidate the original intent of a client- + requested extension. (For example, change key usage from + keyAgreement to digitalSignature.) If a certification request is + denied due to the inability to handle a requested extension, the + server MUST respond with a Full PKI Response with a CMCFailInfo value + with the value of unsupportedExt. + +3.2.1.2.3. Other Certification Request + + This document allows for other certification request formats to be + defined and used as well. An example of an other certification + request format is one for Attribute Certificates. These other + certification request formats are defined by specifying an OID for + identification and the structure to contain the data to be passed. + + + + + +Schaad & Myers Standards Track [Page 18] + +RFC 5272 CMC: Structures June 2008 + + +3.2.1.3. Content Info Objects + + The cmsSequence field of the PKIData and PKIResponse messages + contains zero or more tagged content info objects. The syntax for + this structure is: + + TaggedContentInfo ::= SEQUENCE { + bodyPartID BodyPartID, + contentInfo ContentInfo + } + + The fields in TaggedContentInfo have the following meaning: + + bodyPartID is a unique integer that identifies this content info + object. + + contentInfo is a ContentInfo object (defined in [CMS]). + + The four content types used in cmsSequence are AuthenticatedData, + Data, EnvelopedData, and SignedData. All of these content types are + defined in [CMS]. + +3.2.1.3.1. Authenticated Data + + The AuthenticatedData content type provides a method of doing pre- + shared-secret-based validation of data being sent between two + parties. Unlike SignedData, it does not specify which party actually + generated the information. + + AuthenticatedData provides origination authentication in those + circumstances where a shared-secret exists, but a PKI-based trust has + not yet been established. No PKI-based trust may have been + established because a trust anchor has not been installed on the + client or no certificate exists for a signing key. + + AuthenticatedData content type is used by this document for: + + The id-cmc-authData control (Section 6.16), and + + The top-level wrapper in environments where an encryption-only key + is being certified. + + This content type can include both PKIData and PKIResponse as the + encapsulated content types. These embedded content types can contain + additional controls that need to be processed. + + + + + + +Schaad & Myers Standards Track [Page 19] + +RFC 5272 CMC: Structures June 2008 + + +3.2.1.3.2. Data + + The Data content type allows for general transport of unstructured + data. + + The Data content type is used by this document for: + + Holding the encrypted random value y for POP proof in the + encrypted POP control (see Section 6.7). + +3.2.1.3.3. Enveloped Data + + The EnvelopedData content type provides for shrouding of data. + + The EnvelopedData content type is the primary confidentiality method + for sensitive information in this protocol. EnvelopedData can + provide encryption of an entire PKI Request (see Section 5). + EnvelopedData can also be used to wrap private key material for key + archival. If the decryption on an EnvelopedData fails, a Full PKI + Response is returned with a CMCFailInfo value of badMessageCheck and + a bodyPartID of 0. + +3.2.1.3.4. Signed Data + + The SignedData content type provides for authentication and + integrity. + + The SignedData content type is used by this document for: + + The outer wrapper for a PKI Request. + + The outer wrapper for a PKI Response. + + As part of processing a PKI Request/Response, the signature(s) MUST + be verified. If the signature does not verify and the PKI Request/ + Response contains anything other than a CMC Status Info control, a + Full PKI Response containing a CMC Status Info control MUST be + returned using a CMCFailInfo with a value of badMessageCheck and a + bodyPartID of 0. + + For the PKI Response, SignedData allows the server to sign the + returning data, if any exists, and to carry the certificates and CRLs + corresponding to the PKI Request. If no data is being returned + beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo + fields are not populated. + + + + + + +Schaad & Myers Standards Track [Page 20] + +RFC 5272 CMC: Structures June 2008 + + +3.2.1.4. Other Message Bodies + + The otherMsgSequence field of the PKI Request/Response allows for + arbitrary data objects to be carried as part of a PKI Request/ + Response. This is intended to contain a data object that is not + already wrapped in a cmsSequence field (Section 3.2.1.3). The data + object is ignored unless a control references the data object by + bodyPartID. + + OtherMsg ::= SEQUENCE { + bodyPartID BodyPartID, + otherMsgType OBJECT IDENTIFIER, + otherMsgValue ANY DEFINED BY otherMsgType } + + The fields in OtherMsg have the following meaning: + + bodyPartID is the unique id identifying this data object. + + otherMsgType is the OID that defines the type of message body. + + otherMsgValue is the data. + +3.2.2. Body Part Identification + + Each element of a PKIData or PKIResponse has an associated body part + identifier. The body part identifier is a 4-octet integer using the + ASN.1 of: + + bodyIdMax INTEGER ::= 4294967295 + + BodyPartID ::= INTEGER(0..bodyIdMax) + + Body part identifiers are encoded in the certReqIds field for + CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of + the other objects. The body part identifier MUST be unique within a + single PKIData or PKIResponse. Body part identifiers can be + duplicated in different layers (for example, a PKIData embedded + within another). + + The bodyPartID value of 0 is reserved for use as the reference to the + current PKIData object. + + Some controls, such as the Add Extensions control (Section 6.5.2), + use the body part identifier in the pkiDataReference field to refer + to a PKI Request in the current PKIData. Some controls, such as the + Extended CMC Status Info control (Section 6.1.1), will also use body + part identifiers to refer to elements in the previous PKI Request/ + + + + +Schaad & Myers Standards Track [Page 21] + +RFC 5272 CMC: Structures June 2008 + + + Response. This allows an error to be explicit about the control or + PKI Request to which the error applies. + + A BodyPartList contains a list of body parts in a PKI Request/ + Response (i.e., the Batch Request control in Section 6.17). The + ASN.1 type BodyPartList is defined as: + + BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID + + A BodyPartPath contains a path of body part identifiers moving + through nesting (i.e., the Modify Certification Request control in + Section 6.5.1). The ASN.1 type BodyPartPath is defined as: + + BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID + +3.2.3. CMC Unsigned Data Attribute + + There is sometimes a need to include data in a PKI Request designed + to be removed by an RA during processing. An example of this is the + inclusion of an encrypted private key, where a Key Archive Agent + removes the encrypted private key before sending it on to the CA. + One side effect of this desire is that every RA that encapsulates + this information needs to move the data so that it is not covered by + that RA's signature. (A client PKI Request encapsulated by an RA + cannot have a signed control removed by the Key Archive Agent without + breaking the RA's signature.) The CMC Unsigned Data attribute + addresses this problem. + + The CMC Unsigned Data attribute contains information that is not + directly signed by a client. When an RA encounters this attribute in + the unsigned or unauthenticated attribute field of a request it is + aggregating, the CMC Unsigned Data attribute is removed from the + request prior to placing the request in a cmsSequence and placed in + the unsigned or unauthenticated attributes of the RA's signed or + authenticated data wrapper. + + The CMC Unsigned Data attribute is identified by: + + id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} + + The CMC Unsigned Data attribute has the ASN.1 definition: + + CMCUnsignedData ::= SEQUENCE { + bodyPartPath BodyPartPath, + identifier OBJECT IDENTIFIER, + content ANY DEFINED BY identifier + } + + + + +Schaad & Myers Standards Track [Page 22] + +RFC 5272 CMC: Structures June 2008 + + + The fields in CMCUnsignedData have the following meaning: + + bodyPartPath is the path pointing to the control associated with + this data. When an RA moves the control in an unsigned or + unauthenticated attribute up one level as part of wrapping the + data in a new SignedData or AuthenticatedData, the body part + identifier of the embedded item in the PKIData is prepended to the + bodyPartPath sequence. + + identifier is the OID that defines the associated data. + + content is the data. + + There MUST be at most one CMC Unsigned Data attribute in the + UnsignedAttribute sequence of a SignerInfo or in the + UnauthenticatedAttribute sequence of an AuthenticatedData. + UnsignedAttribute consists of a set of values; the attribute can have + any number of values greater than zero in that set. If the CMC + Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it + MUST appear with the same values(s) in all SignerInfo and + AuthenticatedData items. + +4. PKI Responses + + Two types of PKI Responses exist. This section gives the details on + both types. + +4.1. Simple PKI Response + + Clients MUST be able to process the Simple PKI Response. The Simple + PKI Response consists of a SignedData with no EncapsulatedContentInfo + and no SignerInfo. The certificates requested in the PKI Response + are returned in the certificate field of the SignedData. + + Clients MUST NOT assume the certificates are in any order. Servers + SHOULD include all intermediate certificates needed to form complete + certification paths to one or more trust anchors, not just the newly + issued certificate(s). The server MAY additionally return CRLs in + the CRL bag. Servers MAY include the self-signed certificates. + Clients MUST NOT implicitly trust included self-signed certificate(s) + merely due to its presence in the certificate bag. In the event + clients receive a new self-signed certificate from the server, + clients SHOULD provide a mechanism to enable the user to use the + certificate as a trust anchor. (The Publish Trust Anchors control + (Section 6.15) should be used in the event that the server intends + the client to accept one or more certificates as trust anchors. This + requires the use of the Full PKI Response message.) + + + + +Schaad & Myers Standards Track [Page 23] + +RFC 5272 CMC: Structures June 2008 + + +4.2. Full PKI Response + + Clients MUST be able to process a Full PKI Response. + + The Full PKI Response consists of a SignedData or AuthenticatedData + encapsulating a PKIResponse content type. The certificates issued in + a PKI Response are returned in the certificates field of the + immediately encapsulating SignedData. + + Clients MUST NOT assume the certificates are in any order. Servers + SHOULD include all intermediate certificates needed to form complete + chains to one or more trust anchors, not just the newly issued + certificate(s). The server MAY additionally return CRLs in the CRL + bag. Servers MAY include self-signed certificates. Clients MUST NOT + implicitly trust included self-signed certificate(s) merely due to + its presence in the certificate bag. In the event clients receive a + new self-signed certificate from the server, clients MAY provide a + mechanism to enable the user to explicitly use the certificate as a + trust anchor. (The Publish Trust Anchors control (Section 6.15) + exists for the purpose of allowing for distribution of trust anchor + certificates. If a trusted anchor publishes a new trusted anchor, + this is one case where automated trust of the new trust anchor could + be allowed.) + +4.2.1. PKIResponse Content Type + + The PKIResponse content type is used for the Full PKI Response. The + PKIResponse content type is identified by: + + id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } + + The ASN.1 structure corresponding to the PKIResponse content type is: + + PKIResponse ::= SEQUENCE { + controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, + cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, + otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg + } + + ReponseBody ::= PKIResponse + + Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has + been renamed to PKIResponse for clarity and the old name kept as a + synonym. + + + + + + + +Schaad & Myers Standards Track [Page 24] + +RFC 5272 CMC: Structures June 2008 + + + The fields in PKIResponse have the following meaning: + + controlSequence is a sequence of controls. The controls defined in + this document are found in Section 6. Controls can be defined by + other parties. Details on the TaggedAttribute structure are found + in Section 3.2.1.1. + + cmsSequence is a sequence of [CMS] message objects. See + Section 3.2.1.3 for more details. + + otherMsgSequence is a sequence of arbitrary data objects. Data + objects placed here are referred to by one or more controls. This + allows for controls to use large amounts of data without the data + being embedded in the control. See Section 3.2.1.4 for more + details. + + Processing of PKIResponse by a recipient is as follows: + + 1. All controls should be examined and processed in an appropriate + manner. The appropriate processing is to complete processing at + this time, to ignore the control, or to place the control on a + to-do list for later processing. + + 2. Additional processing of non-element items includes the saving of + certificates and CRLs present in wrapping layers. This type of + processing is based on the consumer of the element and should not + be relied on by generators. + + No processing is required for cmsSequence or otherMsgSequence members + of the PKIResponse, if items are present and are not referenced by a + control. In this case, the cmsSequence and otherMsgSequence members + are to be ignored. + +5. Application of Encryption to a PKI Request/Response + + There are occasions when a PKI Request or Response must be encrypted + in order to prevent disclosure of information in the PKI Request/ + Response from being accessible to unauthorized entities. This + section describes the means to encrypt Full PKI Requests and + Responses (Simple PKI Requests cannot be encrypted). Data portions + of PKI Requests and Responses that are placed in the cmsSequence + field can be encrypted separately. + + Confidentiality is provided by wrapping the PKI Request/Response (a + SignedData) in an EnvelopedData. The nested content type in the + EnvelopedData is id-SignedData. Note that this is different from + S/MIME where there is a MIME layer placed between the encrypted and + signed data. It is recommended that if an EnvelopedData layer is + + + +Schaad & Myers Standards Track [Page 25] + +RFC 5272 CMC: Structures June 2008 + + + applied to a PKI Request/Response, a second signature layer be placed + outside of the EnvelopedData layer. The following figure shows how + this nesting would be done: + + Normal Option 1 Option 2 + ------ -------- -------- + SignedData EnvelopedData SignedData + PKIData SignedData EnvelopedData + PKIData SignedData + PKIData + + Note: PKIResponse can be substituted for PKIData in the above figure. + + Options 1 and 2 prevent leakage of sensitive data by encrypting the + Full PKI Request/Response. An RA that receives a PKI Request that it + cannot decrypt MAY reject the PKI Request unless it can process the + PKI Request without knowledge of the contents (i.e., all it does is + amalgamate multiple PKI Requests and forward them to a server). + + After the RA removes the envelope and completes processing, it may + then apply a new EnvelopedData layer to protect PKI Requests for + transmission to the next processing agent. Section 7 contains more + information about RA processing. + + Full PKI Requests/Responses can be encrypted or transmitted in the + clear. Servers MUST provide support for all three options. + + Alternatively, an authenticated, secure channel could exist between + the parties that require confidentiality. Clients and servers MAY + use such channels instead of the technique described above to provide + secure, private communication of Simple and Full PKI Requests/ + Responses. + +6. Controls + + Controls are carried as part of both Full PKI Requests and Responses. + Each control is encoded as a unique OID followed by the data for the + control (see syntax in Section 3.2.1.1. The encoding of the data is + based on the control. Processing systems would first detect the OID + (TaggedAttribute attrType) and process the corresponding control + value (TaggedAttribute attrValues) prior to processing the message + body. + + + + + + + + + +Schaad & Myers Standards Track [Page 26] + +RFC 5272 CMC: Structures June 2008 + + + The OIDs are all defined under the following arc: + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 } + + The following table lists the names, OID, and syntactic structure for + each of the controls described in this document. + + Identifier Description OID ASN.1 Structure Section + -------------------------------------------------------------------- + id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2 + id-cmc-identification id-cmc 2 UTF8String 6.2.3 + id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2 + id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4 + id-cmc-transactionId id-cmc 5 INTEGER 6.6 + id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6 + id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6 + id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2 + id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7 + id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7 + id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8 + id-cmc-getCert id-cmc 15 GetCert 6.9 + id-cmc-getCRL id-cmc 16 GetCRL 6.10 + id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11 + id-cmc-regInfo id-cmc 18 OCTET STRING 6.12 + id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12 + id-cmc-queryPending id-cmc 21 OCTET STRING 6.13 + id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1 + id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1 + id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1 + id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14 + id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1 + id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15 + id-cmc-authData id-cmc 27 AuthPublish 6.16 + id-cmc-batchRequests id-cmc 28 BodyPartList 6.17 + id-cmc-batchResponses id-cmc 29 BodyPartList 6.17 + id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18 + id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1 + id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19 + id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1 + + Table 1: CMC Control Attributes + + + + + + + +Schaad & Myers Standards Track [Page 27] + +RFC 5272 CMC: Structures June 2008 + + +6.1. CMC Status Info Controls + + The CMC Status Info controls return information about the status of a + client/server request/response. Two controls are described in this + section. The Extended CMC Status Info control is the preferred + control; the CMC Status Info control is included for backwards + compatibility with RFC 2797. + + Servers MAY emit multiple CMC status info controls referring to a + single body part. Clients MUST be able to deal with multiple CMC + status info controls in a PKI Response. Servers MUST use the + Extended CMC Status Info control, but MAY additionally use the CMC + Status Info control. Clients MUST be able to process the Extended + + CMC Status Info control. + +6.1.1. Extended CMC Status Info Control + + The Extended CMC Status Info control is identified by the OID: + + id-cmc-statusInfoV2 ::= { id-cmc 25 } + + The Extended CMC Status Info control has the ASN.1 definition: + + CMCStatusInfoV2 ::= SEQUENCE { + cMCStatus CMCStatus, + bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference, + statusString UTF8String OPTIONAL, + otherInfo OtherStatusInfo OPTIONAL + } + + OtherStatusInfo ::= CHOICE { + failInfo CMCFailInfo, + pendInfo PendInfo, + extendedFailInfo ExtendedFailInfo + } + + PendInfo ::= SEQUENCE { + pendToken OCTET STRING, + pendTime GeneralizedTime + } + + ExtendedFailInfo ::= SEQUENCE { + failInfoOID OBJECT IDENTIFIER, + failInfoValue ANY DEFINED BY failInfoOID + } + + + + + +Schaad & Myers Standards Track [Page 28] + +RFC 5272 CMC: Structures June 2008 + + + BodyPartReference ::= CHOICE { + bodyPartID BodyPartID, + bodyPartPath BodyPartPath + } + + The fields in CMCStatusInfoV2 have the following meaning: + + cMCStatus contains the returned status value. Details are in + Section 6.1.3. + + bodyList identifies the controls or other elements to which the + status value applies. If an error is returned for a Simple PKI + Request, this field is the bodyPartID choice of BodyPartReference + with the single integer of value 1. + + statusString contains additional description information. This + string is human readable. + + otherInfo contains additional information that expands on the CMC + status code returned in the cMCStatus field. + + The fields in OtherStatusInfo have the following meaning: + + failInfo is described in Section 6.1.4. It provides an error code + that details what failure occurred. This choice is present only + if cMCStatus contains the value failed. + + pendInfo contains information about when and how the client should + request the result of this request. It is present when the + cMCStatus is either pending or partial. pendInfo uses the + structure PendInfo, which has the fields: + + pendToken is the token used in the Query Pending control + (Section 6.13). + + pendTime contains the suggested time the server wants to be + queried about the status of the certification request. + + extendedFailInfo includes application-dependent detailed error + information. This choice is present only if cMCStatus contains + the value failed. Caution should be used when defining new values + as they may not be correctly recognized by all clients and + servers. The CMCFailInfo value of internalCAError may be assumed + if the extended error is not recognized. This field uses the type + ExtendedFailInfo. ExtendedFailInfo has the fields: + + failInfoOID contains an OID that is associated with a set of + extended error values. + + + +Schaad & Myers Standards Track [Page 29] + +RFC 5272 CMC: Structures June 2008 + + + failInfoValue contains an extended error code from the defined + set of extended error codes. + + If the cMCStatus field is success, the Extended CMC Status Info + control MAY be omitted unless it is the only item in the response. + +6.1.2. CMC Status Info Control + + The CMC Status Info control is identified by the OID: + + id-cmc-statusInfo ::= { id-cmc 1 } + + The CMC Status Info control has the ASN.1 definition: + + CMCStatusInfo ::= SEQUENCE { + cMCStatus CMCStatus, + bodyList BodyPartList, + statusString UTF8String OPTIONAL, + otherInfo CHOICE { + failInfo CMCFailInfo, + pendInfo PendInfo } OPTIONAL + } + + The fields in CMCStatusInfo have the following meaning: + + cMCStatus contains the returned status value. Details are in + Section 6.1.3. + + bodyList contains the list of controls or other elements to which + the status value applies. If an error is being returned for a + Simple PKI Request, this field contains a single integer of value + 1. + + statusString contains additional description information. This + string is human readable. + + otherInfo provides additional information that expands on the CMC + status code returned in the cMCStatus field. + + failInfo is described in Section 6.1.4. It provides an error + code that details what failure occurred. This choice is + present only if cMCStatus is failed. + + pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It + contains information about when and how the client should + request results of this request. The pendInfo field MUST be + populated for a cMCStatus value of pending or partial. Further + + + + +Schaad & Myers Standards Track [Page 30] + +RFC 5272 CMC: Structures June 2008 + + + details can be found in Section 6.1.1 (Extended CMC Status Info + Control) and Section 6.13 (Query Pending Control ). + + If the cMCStatus field is success, the CMC Status Info control MAY be + omitted unless it is the only item in the response. If no status + exists for a Simple or Full PKI Request, then the value of success is + assumed. + +6.1.3. CMCStatus Values + + CMCStatus is a field in the Extended CMC Status Info and CMC Status + Info controls. This field contains a code representing the success + or failure of a specific operation. CMCStatus has the ASN.1 + structure: + + CMCStatus ::= INTEGER { + success (0), + -- reserved (1), + failed (2), + pending (3), + noSupport (4), + confirmRequired (5), + popRequired (6), + partial (7) + } + + The values of CMCStatus have the following meaning: + + success indicates the request was granted or the action was + completed. + + failed indicates the request was not granted or the action was not + completed. More information is included elsewhere in the + response. + + pending indicates the PKI Request has yet to be processed. The + requester is responsible to poll back on this Full PKI request. + pending may only be returned for certification request operations. + + noSupport indicates the requested operation is not supported. + + confirmRequired indicates a Confirm Certificate Acceptance control + (Section 6.14) must be returned before the certificate can be + used. + + popRequired indicates a direct POP operation is required + (Section 6.3.1.3). + + + + +Schaad & Myers Standards Track [Page 31] + +RFC 5272 CMC: Structures June 2008 + + + partial indicates a partial PKI Response is returned. The requester + is responsible to poll back for the unfulfilled portions of the + Full PKI Request. + +6.1.4. CMCFailInfo + + CMCFailInfo is a field in the Extended CMC Status Info and CMC Status + Info controls. CMCFailInfo conveys more detailed information + relevant to the interpretation of a failure condition. The + CMCFailInfo has the following ASN.1 structure: + + CMCFailInfo ::= INTEGER { + badAlg (0), + badMessageCheck (1), + badRequest (2), + badTime (3), + badCertId (4), + unsupportedExt (5), + mustArchiveKeys (6), + badIdentity (7), + popRequired (8), + popFailed (9), + noKeyReuse (10), + internalCAError (11), + tryLater (12), + authDataFail (13) + } + + The values of CMCFailInfo have the following meanings: + + badAlg indicates unrecognized or unsupported algorithm. + + badMessageCheck indicates integrity check failed. + + badRequest indicates transaction was not permitted or supported. + + badTime indicates message time field was not sufficiently close to + the system time. + + badCertId indicates no certificate could be identified matching the + provided criteria. + + unsupportedExt indicates a requested X.509 extension is not + supported by the recipient CA. + + mustArchiveKeys indicates private key material must be supplied. + + badIdentity indicates identification control failed to verify. + + + +Schaad & Myers Standards Track [Page 32] + +RFC 5272 CMC: Structures June 2008 + + + popRequired indicates server requires a POP proof before issuing + certificate. + + popFailed indicates POP processing failed. + + noKeyReuse indicates server policy does not allow key reuse. + + internalCAError indicates that the CA had an unknown internal + failure. + + tryLater indicates that the server is not accepting requests at this + time and the client should try at a later time. + + authDataFail indicates failure occurred during processing of + authenticated data. + + If additional failure reasons are needed, they SHOULD use the + ExtendedFailureInfo item in the Extended CMC Status Info control. + However, for closed environments they can be defined using this type. + Such codes MUST be in the range from 1000 to 1999. + +6.2. Identification and Identity Proof Controls + + Some CAs and RAs require that a proof-of-identity be included in a + certification request. Many different ways of doing this exist with + different degrees of security and reliability. Most are familiar + with a bank's request to provide your mother's maiden name as a form + of identity proof. The reasoning behind requiring a proof-of- + identity can be found in Appendix C of [CRMF]. + + CMC provides a method to prove the client's identity based on a + client/server shared-secret. If clients support the Full PKI + Request, clients MUST implement this method of identity proof + (Section 6.2.2). Servers MUST provide this method, but MAY + additionally support bilateral methods of similar strength. + + This document also provides an Identification control + (Section 6.2.3). This control is a simple method to allow a client + to state who they are to the server. Generally, a shared-secret AND + an identifier of that shared-secret are passed from the server to the + client. The identifier is placed in the Identification control, and + the shared-secret is used to compute the Identity Proof control. + +6.2.1. Identity Proof Version 2 Control + + The Identity Proof Version 2 control is identified by the OID: + + id-cmc-identityProofV2 ::= { id-cmc 34 } + + + +Schaad & Myers Standards Track [Page 33] + +RFC 5272 CMC: Structures June 2008 + + + The Identity Proof Version 2 control has the ASN.1 definition: + + IdentifyProofV2 ::= SEQUENCE { + hashAlgID AlgorithmIdentifier, + macAlgID AlgorithmIdentifier, + witness OCTET STRING + + } + + The fields of IdentityProofV2 have the following meaning: + + hashAlgID is the identifier and parameters for the hash algorithm + used to convert the shared-secret into a key for the MAC + algorithm. + + macAlgID is the identifier and the parameters for the message + authentication code algorithm used to compute the value of the + witness field. + + witness is the identity proof. + + The required method starts with an out-of-band transfer of a token + (the shared-secret). The shared-secret should be generated in a + random manner. The distribution of this token is beyond the scope of + this document. The client then uses this token for an identity proof + as follows: + + 1. The PKIData reqSequence field (encoded exactly as it appears in + the Full PKI Request including the sequence type and length) is + the value to be validated. + + 2. A hash of the shared-secret as a UTF8 string is computed using + hashAlgID. + + 3. A MAC is then computed using the value produced in Step 1 as the + message and the value from Step 2 as the key. + + 4. The result from Step 3 is then encoded as the witness value in + the Identity Proof Version 2 control. + + When the server verifies the Identity Proof Version 2 control, it + computes the MAC value in the same way and compares it to the witness + value contained in the PKI Request. + + If a server fails the verification of an Identity Proof Version 2 + control, the CMCFailInfo value MUST be present in the Full PKI + Response and MUST have a value of badIdentity. + + + + +Schaad & Myers Standards Track [Page 34] + +RFC 5272 CMC: Structures June 2008 + + + Reuse of the shared-secret on certification request retries allows + the client and server to maintain the same view of acceptable + identity proof values. However, reuse of the shared-secret can + potentially open the door for some types of attacks. + + Implementations MUST be able to support tokens at least 16 characters + long. Guidance on the amount of entropy actually obtained from a + given length token based on character sets can be found in Appendix A + of [PASSWORD]. + +6.2.2. Identity Proof Control + + The Identity Proof control is identified by the OID: + + id-cmc-identityProof ::= { id-cmc 3 } + + The Identity Proof control has the ASN.1 definition: + + IdentifyProof ::= OCTET STRING + + This control is processed in the same way as the Identity Proof + Version 2 control. In this case, the hash algorithm is fixed to + SHA-1 and the MAC algorithm is fixed to HMAC-SHA1. + +6.2.3. Identification Control + + Optionally, servers MAY require the inclusion of the unprotected + Identification control with an Identification Proof control. The + Identification control is intended to contain a text string that + assists the server in locating the shared-secret needed to validate + the contents of the Identity Proof control. If the Identification + control is included in the Full PKI Request, the derivation of the + key in Step 2 (from Section 6.2.1) is altered so that the hash of the + concatenation of the shared-secret and the UTF8 identity value + (without the type and length bytes) are hashed rather than just the + shared-secret. + + The Identification control is identified by the OID: + + id-cmc-identification ::= { id-cmc 2 } + + The Identification control has the ASN.1 definition: + + Identification ::= UTF8String + + + + + + + +Schaad & Myers Standards Track [Page 35] + +RFC 5272 CMC: Structures June 2008 + + +6.2.4. Hardware Shared-Secret Token Generation + + The shared-secret between the EE and the server is sometimes computed + using a hardware device that generates a series of tokens. The EE + can therefore prove its identity by transferring this token in plain + text along with a name string. The above protocol can be used with a + hardware shared-secret token generation device by the following + modifications: + + 1. The Identification control MUST be included and MUST contain the + hardware-generated token. + + 2. The shared-secret value used above is the same hardware-generated + token. + + 3. All certification requests MUST have a subject name, and the + subject name MUST contain the fields required to identify the + holder of the hardware token device. + + 4. The entire certification request MUST be shrouded in some fashion + to prevent eavesdropping. Although the token is time critical, + an active eavesdropper cannot be permitted to extract the token + and submit a different certification request with the same token + value. + +6.3. Linking Identity and POP Information + + In a Full PKI Request, identity information about the client is + carried in the signature of the SignedData containing all of the + certification requests. Proof-of-possession information for key + pairs, however, is carried separately for each PKCS #10 or CRMF + certification request. (For keys capable of generating a digital + signature, the POP is provided by the signature on the PKCS #10 or + CRMF request. For encryption-only keys, the controls described in + Section 6.7 are used.) In order to prevent substitution-style + attacks, the protocol must guarantee that the same entity generated + both the POP and proof-of-identity information. + + This section describes two mechanisms for linking identity and POP + information: witness values cryptographically derived from the + shared-secret (Section 6.3.1.3) and shared-secret/subject + distinguished name (DN) matching (Section 6.3.2). Clients and + servers MUST support the witness value technique. Clients and + servers MAY support shared-secret/subject DN matching or other + bilateral techniques of similar strength. The idea behind both + mechanisms is to force the client to sign some data into each + certification request that can be directly associated with the + + + + +Schaad & Myers Standards Track [Page 36] + +RFC 5272 CMC: Structures June 2008 + + + shared-secret; this will defeat attempts to include certification + requests from different entities in a single Full PKI Request. + +6.3.1. Cryptographic Linkage + + The first technique that links identity and POP information forces + the client to include a piece of information cryptographically + derived from the shared-secret as a signed extension within each + certification request (PKCS #10 or CRMF). + +6.3.1.1. POP Link Witness Version 2 Controls + + The POP Link Witness Version 2 control is identified by the OID: + + id-cmc-popLinkWitnessV2 ::= { id-cmc 33 } + + The POP Link Witness Version 2 control has the ASN.1 definition: + + PopLinkWitnessV2 ::= SEQUENCE { + keyGenAlgorithm AlgorithmIdentifier, + macAlgorithm AlgorithmIdentifier, + witness OCTET STRING + } + + The fields of PopLinkWitnessV2 have the following meanings: + + keyGenAlgorithm contains the algorithm used to generate the key for + the MAC algorithm. This will generally be a hash algorithm, but + could be a more complex algorithm. + + macAlgorithm contains the algorithm used to create the witness + value. + + witness contains the computed witness value. + + This technique is useful if null subject DNs are used (because, for + example, the server can generate the subject DN for the certificate + based only on the shared-secret). Processing begins when the client + receives the shared-secret out-of-band from the server. The client + then computes the following values: + + 1. The client generates a random byte-string, R, which SHOULD be at + least 512 bits in length. + + 2. The key is computed from the shared-secret using the algorithm in + keyGenAlgorithm. + + + + + +Schaad & Myers Standards Track [Page 37] + +RFC 5272 CMC: Structures June 2008 + + + 3. A MAC is then computed over the random value produced in Step 1, + using the key computed in Step 2. + + 4. The random value produced in Step 1 is encoded as the value of a + POP Link Random control. This control MUST be included in the + Full PKI Request. + + 5. The MAC value produced in Step 3 is placed in either the POP Link + Witness control or the witness field of the POP Link Witness V2 + control. + + * For CRMF, the POP Link Witness/POP Link Witness V2 control is + included in the controls field of the CertRequest structure. + + * For PKCS #10, the POP Link Witness/POP Link Witness V2 control + is included in the attributes field of the + CertificationRequestInfo structure. + + Upon receipt, servers MUST verify that each certification request + contains a copy of the POP Link Witness/POP Link Witness V2 control + and that its value was derived using the above method from the + shared-secret and the random string included in the POP Link Random + control. + + The Identification control (see Section 6.2.3) or the subject DN of a + certification request can be used to help identify which shared- + secret was used. + +6.3.1.2. POP Link Witness Control + + The POP Link Witness control is identified by the OID: + + id-cmc-popLinkWitness ::= { id-cmc 23 } + + The POP Link Witness control has the ASN.1 definition: + + PopLinkWitness ::= OCTET STRING + + For this control, SHA-1 is used as the key generation algorithm. + HMAC-SHA1 is used as the mac algorithm. + +6.3.1.3. POP Link Random Control + + The POP Link Random control is identified by the OID: + + id-cmc-popLinkRandom ::= { id-cmc 22 } + + + + + +Schaad & Myers Standards Track [Page 38] + +RFC 5272 CMC: Structures June 2008 + + + The POP Link Random control has the ASN.1 definition: + + PopLinkRandom ::= OCTET STRING + +6.3.2. Shared-Secret/Subject DN Linking + + The second technique to link identity and POP information is to link + a particular subject distinguished name (subject DN) to the shared- + secrets that are distributed out-of-band and to require that clients + using the shared-secret to prove identity include that exact subject + DN in every certification request. It is expected that many client- + server connections that use shared-secret-based proof-of-identity + will use this mechanism. (It is common not to omit the subject DN + information from the certification request.) + + When the shared-secret is generated and transferred out-of-band to + initiate the registration process (Section 6.2), a particular subject + DN is also associated with the shared-secret and communicated to the + client. (The subject DN generated MUST be unique per entity in + accordance with the CA policy; a null subject DN cannot be used. A + common practice could be to place the identification value as part of + the subject DN.) When the client generates the Full PKI Request, it + MUST use these two pieces of information as follows: + + 1. The client MUST include the specific subject DN that it received + along with the shared-secret as the subject name in every + certification request (PKCS #10 and/or CRMF) in the Full PKI + Request. The subject names in the certification requests MUST + NOT be null. + + 2. The client MUST include an Identity Proof control (Section 6.2.2) + or Identity Proof Version 2 control (Section 6.2.1), derived from + the shared-secret, in the Full PKI Request. + + The server receiving this message MUST (a) validate the Identity + Proof control and then, (b) check that the subject DN included in + each certification request matches that associated with the shared- + secret. If either of these checks fails, the certification request + MUST be rejected. + +6.3.3. Renewal and Rekey Messages + + When doing a renewal or rekey certification request, linking identity + and POP information is simple. The client copies the subject DN for + a current signing certificate into the subject name field of each + certification request that is made. The POP for each certification + request will now cover that information. The outermost signature + layer is created using the current signing certificate, which allows + + + +Schaad & Myers Standards Track [Page 39] + +RFC 5272 CMC: Structures June 2008 + + + the original identity to be associated with the certification + request. Since the name in the current signing certificate and the + names in the certification requests match, the necessary linking has + been achieved. + +6.4. Data Return Control + + The Data Return control allows clients to send arbitrary data + (usually some type of internal state information) to the server and + to have the data returned as part of the Full PKI Response. Data + placed in a Data Return control is considered to be opaque to the + server. The same control is used for both Full PKI Requests and + Responses. If the Data Return control appears in a Full PKI Request, + the server MUST return it as part of the PKI Response. + + In the event that the information in the Data Return control needs to + be confidential, it is expected that the client would apply some type + of encryption to the contained data, but the details of this are + outside the scope of this specification. + + The Data Return control is identified by the OID: + + id-cmc-dataReturn ::= { id-cmc 4 } + + The Data Return control has the ASN.1 definition: + + DataReturn ::= OCTET STRING + + A client could use this control to place an identifier marking the + exact source of the private key material. This might be the + identifier of a hardware device containing the private key. + +6.5. RA Certificate Modification Controls + + These controls exist for RAs to be able to modify the contents of a + certification request. Modifications might be necessary for various + reasons. These include addition of certificate extensions or + modification of subject and/or subject alternative names. + + Two controls exist for this purpose. The first control, Modify + Certification Request (Section 6.5.1), allows the RA to replace or + remove any field in the certificate. The second control, Add + Extensions (Section 6.5.2), only allows for the addition of + extensions. + + + + + + + +Schaad & Myers Standards Track [Page 40] + +RFC 5272 CMC: Structures June 2008 + + +6.5.1. Modify Certification Request Control + + The Modify Certification Request control is used by RAs to change + fields in a requested certificate. + + The Modify Certification Request control is identified by the OID: + + id-cmc-modCertTemplate ::= { id-cmc 31 } + + The Modify Certification Request has the ASN.1 definition: + + ModCertTemplate ::= SEQUENCE { + pkiDataReference BodyPartPath, + certReferences BodyPartList, + replace BOOLEAN DEFAULT TRUE, + certTemplate CertTemplate + } + + The fields in ModCertTemplate have the following meaning: + + pkiDataReference is the path to the PKI Request containing + certification request(s) to be modified. + + certReferences refers to one or more certification requests in the + PKI Request referenced by pkiDataReference to be modified. Each + BodyPartID of the certReferences sequence MUST be equal to either + the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the + certReqId of the CertRequest within a CertReqMsg (CRMF). By + definition, the certificate extensions included in the + certTemplate field are applied to every certification request + referenced in the certReferences sequence. If a request + corresponding to bodyPartID cannot be found, the CMCFailInfo with + a value of badRequest is returned that references this control. + + replace specifies if the target certification request is to be + modified by replacing or deleting fields. If the value is TRUE, + the data in this control replaces the data in the target + certification request. If the value is FALSE, the data in the + target certification request is deleted. The action is slightly + different for the extensions field of certTemplate; each extension + is treated individually rather than as a single unit. + + certTemplate is a certificate template object [CRMF]. If a field is + present and replace is TRUE, it replaces that field in the + certification request. If the field is present and replace is + FALSE, the field in the certification request is removed. If the + field is absent, no action is performed. Each extension is + treated as a single field. + + + +Schaad & Myers Standards Track [Page 41] + +RFC 5272 CMC: Structures June 2008 + + + Servers MUST be able to process all extensions defined, but not + prohibited, in [PKIXCERT]. Servers are not required to be able to + process every X.509v3 extension transmitted using this protocol, nor + are they required to be able to process other, private extensions. + Servers are not required to put all RA-requested extensions into a + certificate. Servers are permitted to modify RA-requested + extensions. Servers MUST NOT alter an extension so as to reverse the + meaning of a client-requested extension. If a certification request + is denied due to the inability to handle a requested extension and a + Full PKI Response is returned, the server MUST return a CMCFailInfo + value with the value of unsupportedExt. + + If a certification request is the target of multiple Modify + Certification Request controls, the behavior is: + + o If control A exists in a layer that contains the layer of control + B, control A MUST override control B. In other words, controls + should be applied from the innermost layer to the outermost layer. + + o If control A and control B are in the same PKIData (i.e., the same + wrapping layer), the order of application is non-determinate. + + The same order of application is used if a certification request is + the target of both a Modify Certification Request control and an Add + Extensions control. + +6.5.2. Add Extensions Control + + The Add Extensions control has been deprecated in favor of the Modify + Certification Request control. It was replaced so that fields in the + certification request other than extensions could be modified. + + The Add Extensions control is used by RAs to specify additional + extensions that are to be included in certificates. + + The Add Extensions control is identified by the OID: + + id-cmc-addExtensions ::= { id-cmc 8 } + + The Add Extensions control has the ASN.1 definition: + + AddExtensions ::= SEQUENCE { + pkiDataReference BodyPartID, + certReferences SEQUENCE OF BodyPartID, + extensions SEQUENCE OF Extension + } + + + + + +Schaad & Myers Standards Track [Page 42] + +RFC 5272 CMC: Structures June 2008 + + + The fields in AddExtensions have the following meaning: + + pkiDataReference contains the body part identity of the embedded + certification request. + + certReferences is a list of references to one or more of the + certification requests contained within a PKIData. Each body part + identifier of the certReferences sequence MUST be equal to either + the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the + certReqId of the CertRequest within a CertReqMsg (CRMF). By + definition, the listed extensions are to be applied to every + certification request referenced in the certReferences sequence. + If a certification request corresponding to bodyPartID cannot be + found, the CMCFailInfo with a value of badRequest is returned + referencing this control. + + extensions is a sequence of extensions to be applied to the + referenced certification requests. + + Servers MUST be able to process all extensions defined, but not + prohibited, in [PKIXCERT]. Servers are not required to be able to + process every X.509v3 extension transmitted using this protocol, nor + are they required to be able to process other, private extensions. + Servers are not required to put all RA-requested extensions into a + certificate. Servers are permitted to modify RA-requested + extensions. Servers MUST NOT alter an extension so as to reverse the + meaning of a client-requested extension. If a certification request + is denied due to the inability to handle a requested extension and a + response is returned, the server MUST return a CMCFailInfo with the + value of unsupportedExt. + + If multiple Add Extensions controls exist in a Full PKI Request, the + exact behavior is left up to the CA policy. However, it is + recommended that the following policy be used. These rules would be + applied to individual extensions within an Add Extensions control (as + opposed to an "all or nothing" approach). + + 1. If the conflict is within a single PKIData, the certification + request would be rejected with a CMCFailInfo value of badRequest. + + 2. If the conflict is between different PKIData, the outermost + version of the extension would be used (allowing an RA to + override the requested extension). + + + + + + + + +Schaad & Myers Standards Track [Page 43] + +RFC 5272 CMC: Structures June 2008 + + +6.6. Transaction Identifier Control and Sender and Recipient Nonce + Controls + + Transactions are identified and tracked with a transaction + identifier. If used, clients generate transaction identifiers and + retain their value until the server responds with a Full PKI Response + that completes the transaction. Servers correspondingly include + received transaction identifiers in the Full PKI Response. + + The Transaction Identifier control is identified by the OID: + + id-cmc-transactionId ::= { id-cmc 5 } + + The Transaction Identifier control has the ASN.1 definition: + + TransactionId ::= INTEGER + + The Transaction Identifier control identifies a given transaction. + It is used by client and server to manage the state of an operation. + Clients MAY include a Transaction Identifier control in a request. + If the original request contains a Transaction Identifier control, + all subsequent requests and responses MUST include the same + Transaction Identifier control. + + Replay protection is supported through the use of the Sender and + Recipient Nonce controls. If nonces are used, in the first message + of a transaction, a Recipient Nonce control is not transmitted; a + Sender Nonce control is included by the transaction originator and + retained for later reference. The recipient of a Sender Nonce + control reflects this value back to the originator as a Recipient + Nonce control and includes its own Sender Nonce control. Upon + receipt by the transaction originator of this response, the + transaction originator compares the value of Recipient Nonce control + to its retained value. If the values match, the message can be + accepted for further security processing. The received value for a + Sender Nonce control is also retained for inclusion in the next + message associated with the same transaction. + + The Sender Nonce and Recipient Nonce controls are identified by the + OIDs: + + id-cmc-senderNonce ::= { id-cmc 6 } + id-cmc-recipientNonce ::= { id-cmc 7 } + + The Sender Nonce control has the ASN.1 definition: + + SenderNonce ::= OCTET STRING + + + + +Schaad & Myers Standards Track [Page 44] + +RFC 5272 CMC: Structures June 2008 + + + The Recipient Nonce control has the ASN.1 definition: + + RecipientNonce ::= OCTET STRING + + Clients MAY include a Sender Nonce control in the initial PKI + Request. If a message includes a Sender Nonce control, the response + MUST include the transmitted value of the previously received Sender + Nonce control as a Recipient Nonce control and include a new value as + its Sender Nonce control. + +6.7. Encrypted and Decrypted POP Controls + + Servers MAY require that this POP method be used only if another POP + method is unavailable. Servers SHOULD reject all certification + requests contained within a PKIData if any required POP is missing + for any element within the PKIData. + + Many servers require proof that the entity that generated the + certification request actually possesses the corresponding private + component of the key pair. For keys that can be used as signature + keys, signing the certification request with the private key serves + as a POP on that key pair. With keys that can only be used for + encryption operations, POP MUST be performed by forcing the client to + decrypt a value. See Section 5 of [CRMF] for a detailed discussion + of POP. + + By necessity, POP for encryption-only keys cannot be done in one + round-trip, since there are four distinct steps: + + 1. Client tells the server about the public component of a new + encryption key pair. + + 2. Server sends the client a POP challenge, encrypted with the + presented public encryption key. + + 3. Client decrypts the POP challenge using the private key that + corresponds to the presented public key and sends the plaintext + back to the server. + + 4. Server validates the decrypted POP challenge and continues + processing the certification request. + + CMC defines two different controls. The first deals with the + encrypted challenge sent from the server to the user in Step 2. The + second deals with the decrypted challenge sent from the client to the + server in Step 3. + + + + + +Schaad & Myers Standards Track [Page 45] + +RFC 5272 CMC: Structures June 2008 + + + The Encrypted POP control is used to send the encrypted challenge + from the server to the client as part of the PKIResponse. (Note that + it is assumed that the message sent in Step 1 above is a Full PKI + Request and that the response in Step 2 is a Full PKI Response + including a CMCFailInfo specifying that a POP is explicitly required, + and providing the POP challenge in the encryptedPOP control.) + + The Encrypted POP control is identified by the OID: + + id-cmc-encryptedPOP ::= { id-cmc 9 } + + The Encrypted POP control has the ASN.1 definition: + + EncryptedPOP ::= SEQUENCE { + request TaggedRequest, + cms ContentInfo, + thePOPAlgID AlgorithmIdentifier, + witnessAlgID AlgorithmIdentifier, + witness OCTET STRING + } + + The Decrypted POP control is identified by the OID: + + id-cmc-decryptedPOP ::= { id-cmc 10 } + + The Decrypted POP control has the ASN.1 definition: + + DecryptedPOP ::= SEQUENCE { + bodyPartID BodyPartID, + thePOPAlgID AlgorithmIdentifier, + thePOP OCTET STRING + } + + The encrypted POP algorithm works as follows: + + 1. The server randomly generates the POP Proof Value and associates + it with the request. + + 2. The server returns the Encrypted POP control with the following + fields set: + + request is the original certification request (it is included + here so the client need not keep a copy of the request). + + cms is an EnvelopedData, the encapsulated content type being id- + data and the content being the POP Proof Value; this value + needs to be long enough that one cannot reverse the value from + the witness hash. If the certification request contains a + + + +Schaad & Myers Standards Track [Page 46] + +RFC 5272 CMC: Structures June 2008 + + + Subject Key Identifier (SKI) extension, then the recipient + identifier SHOULD be the SKI. If the issuerAndSerialNumber + form is used, the IssuerName MUST be encoded as NULL and the + SerialNumber as the bodyPartID of the certification request. + + thePOPAlgID identifies the algorithm to be used in computing the + return POP value. + + witnessAlgID identifies the hash algorithm used on the POP Proof + Value to create the field witness. + + witness is the hashed value of the POP Proof Value. + + 3. The client decrypts the cms field to obtain the POP Proof Value. + The client computes H(POP Proof Value) using the witnessAlgID and + compares to the value of witness. If the values do not compare + or the decryption is not successful, the client MUST abort the + enrollment process. The client aborts the process by sending a + request containing a CMC Status Info control with CMCFailInfo + value of popFailed. + + 4. The client creates the Decrypted POP control as part of a new + PKIData. The fields in the DecryptedPOP are: + + bodyPartID refers to the certification request in the new PKI + Request. + + thePOPAlgID is copied from the encryptedPOP. + + thePOP contains the possession proof. This value is computed by + thePOPAlgID using the POP Proof Value and the request. + + 5. The server then re-computes the value of thePOP from its cached + value and the request and compares to the value of thePOP. If + the values do not match, the server MUST NOT issue the + certificate. The server MAY re-issue a new challenge or MAY fail + the request altogether. + + When defining the algorithms for thePOPAlgID and witnessAlgID, care + must be taken to ensure that the result of witnessAlgID is not a + useful value to shortcut the computation with thePOPAlgID. The POP + Proof Value is used as the secret value in the HMAC algorithm and the + request is used as the data. If the POP Proof Value is greater than + 64 bytes, only the first 64 bytes of the POP Proof Value is used as + the secret. + + + + + + +Schaad & Myers Standards Track [Page 47] + +RFC 5272 CMC: Structures June 2008 + + + One potential problem with the algorithm above is the amount of state + that a CA needs to keep in order to verify the returned POP value. + The following describes one of many possible ways of addressing the + problem by reducing the amount of state kept on the CA to a single + (or small set) of values. + + 1. Server generates random seed x, constant across all requests. + (The value of x would normally be altered on a regular basis and + kept for a short time afterwards.) + + 2. For certification request R, server computes y = F(x,R). F can + be, for example, HMAC-SHA1(x,R). All that's important for + statelessness is that y be consistently computable with only + known state constant x and function F, other inputs coming from + the certification request structure. y should not be predictable + based on knowledge of R, thus the use of a one-way function like + HMAC-SHA1. + +6.8. RA POP Witness Control + + In a certification request scenario that involves an RA, the CA may + allow (or require) that the RA perform the POP protocol with the + entity that generated the certification request. In this case, the + RA needs a way to inform the CA that it has done the POP. The RA POP + Witness control addresses this issue. + + The RA POP Witness control is identified by the OID: + + id-cmc-lraPOPWitness ::= { id-cmc 11 } + + The RA POP Witness control has the ASN.1 definition: + + LraPopWitness ::= SEQUENCE { + pkiDataBodyid BodyPartID, + bodyIds SEQUENCE of BodyPartID + } + + The fields in LraPOPWitness have the following meaning: + + pkiDataBodyid contains the body part identifier of the nested + TaggedContentInfo containing the client's Full PKI Request. + pkiDataBodyid is set to 0 if the request is in the current + PKIData. + + bodyIds is a list of certification requests for which the RA has + performed an out-of-band authentication. The method of + authentication could be archival of private key material, + challenge-response, or other means. + + + +Schaad & Myers Standards Track [Page 48] + +RFC 5272 CMC: Structures June 2008 + + + If a certification server does not allow an RA to do the POP + verification, it returns a CMCFailInfo with the value of popFailed. + The CA MUST NOT start a challenge-response to re-verify the POP + itself. + +6.9. Get Certificate Control + + Everything described in this section is optional to implement. + + The Get Certificate control is used to retrieve a previously issued + certificate from a certificate repository. A CA, an RA, or an + independent service may provide this repository. The clients + expected to use this facility are those where a fully deployed + directory is either infeasible or undesirable. + + The Get Certificate control is identified by the OID: + + id-cmc-getCert ::= { id-cmc 15 } + + The Get Certificate control has the ASN.1 definition: + + GetCert ::= SEQUENCE { + issuerName GeneralName, + serialNumber INTEGER } + + The fields in GetCert have the following meaning: + + issuerName is the name of the certificate issuer. + + serialNumber identifies the certificate to be retrieved. + + The server that responds to this request places the requested + certificate in the certificates field of a SignedData. If the Get + Certificate control is the only control in a Full PKI Request, the + response should be a Simple PKI Response. + +6.10. Get CRL Control + + Everything described in this section is optional to implement. + + The Get CRL control is used to retrieve CRLs from a repository of + CRLs. A CA, an RA, or an independent service may provide this + repository. The clients expected to use this facility are those + where a fully deployed directory is either infeasible or undesirable. + + The Get CRL control is identified by the OID: + + id-cmc-getCRL ::= { id-cmc 16 } + + + +Schaad & Myers Standards Track [Page 49] + +RFC 5272 CMC: Structures June 2008 + + + The Get CRL control has the ASN.1 definition: + + GetCRL ::= SEQUENCE { + issuerName Name, + cRLName GeneralName OPTIONAL, + time GeneralizedTime OPTIONAL, + reasons ReasonFlags OPTIONAL } + + The fields in a GetCRL have the following meanings: + + issuerName is the name of the CRL issuer. + + cRLName may be the value of CRLDistributionPoints in the subject + certificate or equivalent value in the event the certificate does + not contain such a value. + + time is used by the client to specify from among potentially several + issues of CRL that one whose thisUpdate value is less than but + nearest to the specified time. In the absence of a time + component, the CA always returns with the most recent CRL. + + reasons is used to specify from among CRLs partitioned by revocation + reason. Implementers should bear in mind that while a specific + revocation request has a single CRLReason code -- and consequently + entries in the CRL would have a single CRLReason code value -- a + single CRL can aggregate information for one or more reasonFlags. + + A server responding to this request places the requested CRL in the + crls field of a SignedData. If the Get CRL control is the only + control in a Full PKI Request, the response should be a Simple PKI + Response. + +6.11. Revocation Request Control + + The Revocation Request control is used to request that a certificate + be revoked. + + The Revocation Request control is identified by the OID: + + id-cmc-revokeRequest ::= { id-cmc 17 } + + + + + + + + + + + +Schaad & Myers Standards Track [Page 50] + +RFC 5272 CMC: Structures June 2008 + + + The Revocation Request control has the ASN.1 definition: + + RevokeRequest ::= SEQUENCE { + issuerName Name, + serialNumber INTEGER, + reason CRLReason, + invalidityDate GeneralizedTime OPTIONAL, + sharedSecret OCTET STRING OPTIONAL, + comment UTF8string OPTIONAL } + + The fields of RevokeRequest have the following meaning: + + issuerName is the issuerName of the certificate to be revoked. + + serialNumber is the serial number of the certificate to be revoked. + + reason is the suggested CRLReason code for why the certificate is + being revoked. The CA can use this value at its discretion in + building the CRL. + + invalidityDate is the suggested value for the Invalidity Date CRL + Extension. The CA can use this value at its discretion in + building the CRL. + + sharedSecret is a secret value registered by the EE when the + certificate was obtained to allow for revocation of a certificate + in the event of key loss. + + comment is a human-readable comment. + + For a revocation request to be reliable in the event of a dispute, a + strong proof-of-origin is required. However, in the instance when an + EE has lost use of its signature private key, it is impossible for + the EE to produce a digital signature (prior to the certification of + a new signature key pair). The Revoke Request control allows the EE + to send the CA a shared-secret that may be used as an alternative + authenticator in the instance of loss of use of the EE's signature + private key. The acceptability of this practice is a matter of local + security policy. + + It is possible to sign the revocation for the lost certificate with a + different certificate in some circumstances. A client can sign a + revocation for an encryption key with a signing certificate if the + name information matches. Similarly, an administrator or RA can be + assigned the ability to revoke the certificate of a third party. + Acceptance of the revocation by the server depends on local policy in + these cases. + + + + +Schaad & Myers Standards Track [Page 51] + +RFC 5272 CMC: Structures June 2008 + + + Clients MUST provide the capability to produce a digitally signed + Revocation Request control. Clients SHOULD be capable of producing + an unsigned Revocation Request control containing the EE shared- + secret (the unsigned message consisting of a SignedData with no + signatures). If a client provides shared-secret-based self- + revocation, the client MUST be capable of producing a Revocation + Request control containing the shared-secret. Servers MUST be + capable of accepting both forms of revocation requests. + + The structure of an unsigned, shared-secret-based revocation request + is a matter of local implementation. The shared-secret does not need + to be encrypted when sent in a Revocation Request control. The + shared-secret has a one-time use (i.e., it is used to request + revocation of the certificate), and public knowledge of the shared- + secret after the certificate has been revoked is not a problem. + Clients need to inform users that the same shared-secret SHOULD NOT + be used for multiple certificates. + + A Full PKI Response MUST be returned for a revocation request. + +6.12. Registration and Response Information Controls + + The Registration Information control allows for clients to pass + additional information as part of a Full PKI Request. + + The Registration Information control is identified by the OID: + + id-cmc-regInfo ::= { id-cmc 18 } + + The Registration Information control has the ASN.1 definition: + + RegInfo ::= OCTET STRING + + The content of this data is based on bilateral agreement between the + client and server. + + The Response Information control allows a server to return additional + information as part of a Full PKI Response. + + The Response Information control is identified by the OID: + + id-cmc-responseInfo ::= { id-cmc 19 } + + The Response Information control has the ASN.1 definition: + + ResponseInfo ::= OCTET STRING + + + + + +Schaad & Myers Standards Track [Page 52] + +RFC 5272 CMC: Structures June 2008 + + + The content of this data is based on bilateral agreement between the + client and server. + +6.13. Query Pending Control + + In some environments, process requirements for manual intervention or + other identity checks can delay the return of the certificate. The + Query Pending control allows clients to query a server about the + state of a pending certification request. The server returns a + pendToken as part of the Extended CMC Status Info and the CMC Status + Info controls (in the otherInfo field). The client copies the + pendToken into the Query Pending control to identify the correct + certification request to the server. The server returns a suggested + time for the client to query for the state of a pending certification + request. + + The Query Pending control is identified by the OID: + + id-cmc-queryPending ::= { id-cmc 21 } + + The Query Pending control has the ASN.1 definition: + + QueryPending ::= OCTET STRING + + If a server returns a pending or partial CMCStatusInfo (the + transaction is still pending), the otherInfo MAY be omitted. If the + otherInfo is not omitted, the value of 'pendInfo' MUST be the same as + the original pendInfo value. + +6.14. Confirm Certificate Acceptance Control + + Some CAs require that clients give a positive confirmation that the + certificates issued to the EE are acceptable. The Confirm + Certificate Acceptance control is used for that purpose. If the CMC + Status Info on a PKI Response is confirmRequired, then the client + MUST return a Confirm Certificate Acceptance control contained in a + Full PKI Request. + + Clients SHOULD wait for the PKI Response from the server that the + confirmation has been received before using the certificate for any + purpose. + + The Confirm Certificate Acceptance control is identified by the OID: + + id-cmc-confirmCertAcceptance ::= { id-cmc 24 } + + + + + + +Schaad & Myers Standards Track [Page 53] + +RFC 5272 CMC: Structures June 2008 + + + The Confirm Certificate Acceptance control has the ASN.1 definition: + + CMCCertId ::= IssuerAndSerialNumber + + CMCCertId contains the issuer and serial number of the certificate + being accepted. + + Servers MUST return a Full PKI Response for a Confirm Certificate + Acceptance control. + + Note that if the CA includes this control, there will be two full + round-trips of messages. + + 1. The client sends the certification request to the CA. + + 2. The CA returns a Full PKI Response with the certificate and this + control. + + 3. The client sends a Full PKI Request to the CA with an Extended + CMC Status Info control accepting and a Confirm Certificate + Acceptance control or an Extended CMC Status Info control + rejecting the certificate. + + 4. The CA sends a Full PKI Response to the client with an Extended + CMC Status Info of success. + +6.15. Publish Trust Anchors Control + + The Publish Trust Anchors control allows for the distribution of set + trust anchors from a central authority to an EE. The same control is + also used to update the set of trust anchors. Trust anchors are + distributed in the form of certificates. These are expected, but not + required, to be self-signed certificates. Information is extracted + from these certificates to set the inputs to the certificates + validation algorithm in Section 6.1.1 of [PKIXCERT]. + + The Publish Trust Anchors control is identified by the OID: + + id-cmc-trustedAnchors ::= { id-cmc 26 } + + The Publish Trust Anchors control has the ASN.1 definition: + + PublishTrustAnchors ::= SEQUENCE { + seqNumber INTEGER, + hashAlgorithm AlgorithmIdentifier, + anchorHashes SEQUENCE OF OCTET STRING + } + + + + +Schaad & Myers Standards Track [Page 54] + +RFC 5272 CMC: Structures June 2008 + + + The fields in PublishTrustAnchors have the following meaning: + + seqNumber is an integer indicating the location within a sequence of + updates. + + hashAlgorithm is the identifier and parameters for the hash + algorithm that is used in computing the values of the anchorHashes + field. All implementations MUST implement SHA-1 for this field. + + anchorHashes are the hashes for the certificates that are to be + treated as trust anchors by the client. The actual certificates + are transported in the certificate bag of the containing + SignedData structure. + + While it is recommended that the sender place the certificates that + are to be trusted in the PKI Response, it is not required as the + certificates should be obtainable using normal discovery techniques. + + Prior to accepting the trust anchors changes, a client MUST at least + do the following: validate the signature on the PKI Response to a + current trusted anchor, check with policy to ensure that the signer + is permitted to use the control, validate that the authenticated + publish time in the signature is near to the current time, and + validate that the sequence number is greater than the previously used + one. + + In the event that multiple agents publish a set of trust anchors, it + is up to local policy to determine how the different trust anchors + should be combined. Clients SHOULD be able to handle the update of + multiple trust anchors independently. + + Note: Clients that handle this control must use extreme care in + validating that the operation is permissible. Incorrect handling of + this control allows for an attacker to change the set of trust + anchors on the client. + +6.16. Authenticated Data Control + + The Authenticated Data control allows a server to provide data back + to the client in an authenticated manner. This control uses the + Authenticated Data structure to allow for validation of the data. + This control is used where the client has a shared-secret and a + secret identifier with the server, but where a trust anchor has not + yet been downloaded onto the client so that a signing certificate for + the server cannot be validated. The specific case that this control + was created for use with is the Publish Trust Anchors control + (Section 6.15), but it may be used in other cases as well. + + + + +Schaad & Myers Standards Track [Page 55] + +RFC 5272 CMC: Structures June 2008 + + + The Authenticated Data control is identified by the OID: + + id-cmc-authData ::= { id-cmc 27 } + + The Authenticated Data control has the ASN.1 definition: + + AuthPublish ::= BodyPartID + + AuthPublish is a body part identifier that refers to a member of the + cmsSequence element for the current PKI Response or PKI Data. The + cmsSequence element is AuthenticatedData. The encapsulated content + is an id-cct-PKIData. The controls in the controlSequence need to be + processed if the authentication succeeds. (One example is the + Publish Trust Anchors control in Section 6.15.) + + If the authentication operation fails, the CMCFailInfo authDataFail + is returned. + +6.17. Batch Request and Response Controls + + These controls allow for an RA to collect multiple requests together + into a single Full PKI Request and forward it to a CA. The server + would then process the requests and return the results in a Full PKI + Response. + + The Batch Request control is identified by the OID: + + id-cmc-batchRequests ::= {id-cmc 28} + + The Batch Response control is identified by the OID: + + id-cmc-batchResponses ::= {id-cmc 29} + + Both the Batch Request and Batch Response controls have the ASN.1 + definition: + + BodyPartList ::= SEQUENCE of BodyPartID + + The data associated with these controls is a set of body part + identifiers. Each request/response is placed as an individual entry + in the cmcSequence of the new PKIData/PKIResponse. The body part + identifiers of these entries are then placed in the body part list + associated with the control. + + When a server processes a Batch Request control, it MAY return the + responses in one or more PKI Responses. A CMCStatus value of partial + is returned on all but the last PKI Response. The CMCStatus would be + success if the Batch Requests control was processed; the responses + + + +Schaad & Myers Standards Track [Page 56] + +RFC 5272 CMC: Structures June 2008 + + + are created with their own CMCStatus code. Errors on individual + requests are not propagated up to the top level. + + When a PKI Response with a CMCStatus value of partial is returned, + the Query Pending control (Section 6.13) is used to retrieve + additional results. The returned status includes a suggested time + after which the client should ask for the additional results. + +6.18. Publication Information Control + + The Publication Information control allows for modifying publication + of already issued certificates, both for publishing and removal from + publication. A common usage for this control is to remove an + existing certificate from publication during a rekey operation. This + control should always be processed after the issuance of new + certificates and revocation requests. This control should not be + processed if a certificate failed to be issued. + + The Publication Information control is identified by the OID: + + id-cmc-publishCert ::= { id-cmc 30 } + + The Publication Information control has the ASN.1 definition: + + CMCPublicationInfo ::= SEQUENCE { + hashAlg AlgorithmIdentifier, + certHashes SEQUENCE of OCTET STRING, + pubInfo PKIPublicationInfo + + PKIPublicationInfo ::= SEQUENCE { + action INTEGER { + dontPublish (0), + pleasePublish (1) }, + pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } + + -- pubInfos MUST NOT be present if action is "dontPublish" + -- (if action is "pleasePublish" and pubInfos is omitted, + -- "dontCare" is assumed) + + SinglePubInfo ::= SEQUENCE { + pubMethod INTEGER { + dontCare (0), + x500 (1), + web (2), + ldap (3) }, + pubLocation GeneralName OPTIONAL } + } + + + + +Schaad & Myers Standards Track [Page 57] + +RFC 5272 CMC: Structures June 2008 + + + The fields in CMCPublicationInfo have the following meaning: + + hashAlg is the algorithm identifier of the hash algorithm used to + compute the values in certHashes. + + certHashes are the hashes of the certificates for which publication + is to change. + + pubInfo is the information where and how the certificates should be + published. The fields in pubInfo (taken from [CRMF]) have the + following meanings: + + action indicates the action the service should take. It has two + values: + + dontPublish indicates that the PKI should not publish the + certificate (this may indicate that the requester intends to + publish the certificate him/herself). dontPublish has the + added connotation of removing from publication the + certificate if it is already published. + + pleasePublish indicates that the PKI MAY publish the + certificate using whatever means it chooses unless pubInfos + is present. Omission of the CMC Publication Info control + results in the same behavior. + + pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the + PKI SHOULD publish the certificate. + + A single certificate SHOULD NOT appear in more than one Publication + Information control. The behavior is undefined in the event that it + does. + +6.19. Control Processed Control + + The Control Processed control allows an RA to indicate to subsequent + control processors that a specific control has already been + processed. This permits an RA in the middle of a processing stream + to process a control defined either in a local context or in a + subsequent document. + + The Control Processed control is identified by the OID: + + id-cmc-controlProcessed ::= { id-cmc 32 } + + + + + + + +Schaad & Myers Standards Track [Page 58] + +RFC 5272 CMC: Structures June 2008 + + + The Control Processed control has the ASN.1 definition: + + ControlList ::= SEQUENCE { + bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference + } + + bodyList is a series of body part identifiers that form a path to + each of the controls that were processed by the RA. This control + is only needed for those controls that are not part of this + standard and thus would cause an error condition of a server + attempting to deal with a control not defined in this document. + No error status is needed since an error causes the RA to return + the request to the client with the error rather than passing the + request on to the next server in the processing list. + +7. Registration Authorities + + This specification permits the use of RAs. An RA sits between the EE + and the CA. From the EE's perspective, the RA appears to be the CA, + and from the server, the RA appears to be a client. RAs receive the + PKI Requests, perform local processing and then forward them onto + CAs. Some of the types of local processing that an RA can perform + include: + + o Batching multiple PKI Requests together, + + o Performing challenge/response POP proofs, + + o Adding private or standardized certificate extensions to all + certification requests, + + o Archiving private key material, + + o Routing requests to different CAs. + + When an RA receives a PKI Request, it has three options: it may + forward the PKI Request without modification, it may add a new + wrapping layer to the PKI Request, or it may remove one or more + existing layers and add a new wrapping layer. + + When an RA adds a new wrapping layer to a PKI Request, it creates a + new PKIData. The new layer contains any controls required (for + example, if the RA does the POP proof for an encryption key or the + Add Extension control to modify a PKI Request) and the client PKI + Request. The client PKI Request is placed in the cmsSequence if it + is a Full PKI Request and in the reqSequence if it is a Simple PKI + Request. If an RA is batching multiple client PKI Requests together, + + + + +Schaad & Myers Standards Track [Page 59] + +RFC 5272 CMC: Structures June 2008 + + + then each client PKI Request is placed into the appropriate location + in the RA's PKIData object along with all relevant controls. + + If multiple RAs are in the path between the EE and the CA, this will + lead to multiple wrapping layers on the request. + + In processing a PKI Request, an RA MUST NOT alter any certification + requests (PKCS #10 or CRMF) as any alteration would invalidate the + signature on the certification request and thus the POP for the + private key. + + An example of how this would look is illustrated by the following + figure: + + SignedData (by RA) + PKIData + controlSequence + RA added control statements + reqSequence + Zero or more Simple PKI Requests from clients + cmsSequence + Zero or more Full PKI Requests from clients + SignedData (signed by client) + PKIData + + Under some circumstances, an RA is required to remove wrapping + layers. The following sections look at the processing required if + encryption layers and signing layers need to be removed. + +7.1. Encryption Removal + + There are two cases that require an RA to remove or change encryption + in a PKI Request. In the first case, the encryption was applied for + the purposes of protecting the entire PKI Request from unauthorized + entities. If the CA does not have a Recipient Info entry in the + encryption layer, the RA MUST remove the encryption layer. The RA + MAY add a new encryption layer with or without adding a new signing + layer. + + The second change of encryption that may be required is to change the + encryption inside of a signing layer. In this case, the RA MUST + remove all signing layers containing the encryption. All control + statements MUST be merged according to local policy rules as each + signing layer is removed and the resulting merged controls MUST be + placed in a new signing layer provided by the RA. If the signing + layer provided by the EE needs to also be removed, the RA can also + remove this layer. + + + + +Schaad & Myers Standards Track [Page 60] + +RFC 5272 CMC: Structures June 2008 + + +7.2. Signature Layer Removal + + Only two instances exist where an RA should remove a signature layer + on a Full PKI Request: if an encryption layer needs to be modified + within the request, or if a CA will not accept secondary delegation + (i.e., multiple RA signatures). In all other situations, RAs SHOULD + NOT remove a signing layer from a PKI Request. + + If an RA removes a signing layer from a PKI Request, all control + statements MUST be merged according to local policy rules. The + resulting merged control statements MUST be placed in a new signing + layer provided by the RA. + +8. Security Considerations + + Mechanisms for thwarting replay attacks may be required in particular + implementations of this protocol depending on the operational + environment. In cases where the CA maintains significant state + information, replay attacks may be detectable without the inclusion + of the optional nonce mechanisms. Implementers of this protocol need + to carefully consider environmental conditions before choosing + whether or not to implement the senderNonce and recipientNonce + controls described in Section 6.6. Developers of state-constrained + PKI clients are strongly encouraged to incorporate the use of these + controls. + + Extreme care needs to be taken when archiving a signing key. The + holder of the archived key may have the ability to use the key to + generate forged signatures. There are however reasons why a signing + key should be archived. An archived CA signing key can be recovered + in the event of failure to continue to produced CRLs following a + disaster. + + Due care must be taken prior to archiving keys. Once a key is given + to an archiving entity, the archiving entity could use the keys in a + way not conducive to the archiving entity. Users should be made + especially aware that proper verification is made of the certificate + used to encrypt the private key material. + + Clients and servers need to do some checks on cryptographic + parameters prior to issuing certificates to make sure that weak + parameters are not used. A description of the small subgroup attack + is provided in [X942]. Methods of avoiding the small subgroup attack + can be found in [SMALL-GROUP]. CMC implementations ought to be aware + of this attack when doing parameter validations. + + + + + + +Schaad & Myers Standards Track [Page 61] + +RFC 5272 CMC: Structures June 2008 + + + When using a shared-secret for authentication purposes, the shared- + secret should be generated using good random number techniques + [RANDOM]. User selection of the secret allows for dictionary attacks + to be mounted. + + Extreme care must be used when processing the Publish Trust Anchors + control. Incorrect processing can lead to the practice of slamming + where an attacker changes the set of trusted anchors in order to + weaken security. + + One method of controlling the use of the Publish Trust Anchors + control is as follows. The client needs to associate with each trust + anchor accepted by the client the source of the trust anchor. + Additionally, the client should associate with each trust anchor the + types of messages for which the trust anchor is valid (i.e., is the + trust anchor used for validating S/MIME messages, TLS, or CMC + enrollment messages?). + + When a new message is received with a Publish Trust Anchors control, + the client would accept the set of new trust anchors for specific + applications only if the signature validates, the signer of the + message has the required policy approval for updating the trust + anchors, and local policy also would allow updating the trust + anchors. + + The CMS AuthenticatedData structure provides message integrity, it + does not provide message authentication in all cases. When using + MACs in this document the following restrictions need to be observed. + All messages should be for a single entity. If two entities are + placed in a single message, the entities can generate new messages + that have a valid MAC and might be assumed to be from the original + message sender. All entities that have access to the shared-secret + can generate messages that will have a successful MAC validation. + This means that care must be taken to keep this value secret. + Whenever possible, the SignedData structure should be used in + preference to the AuthenticatedData structure. + +9. IANA Considerations + + This document defines a number of control objects. These are + identified by Object Identifiers (OIDs). The objects are defined + from an arc delegated by IANA to the PKIX Working Group. No further + action by IANA is necessary for this document or any anticipated + updates. + + + + + + + +Schaad & Myers Standards Track [Page 62] + +RFC 5272 CMC: Structures June 2008 + + +10. Acknowledgments + + The authors and the PKIX Working Group are grateful for the + participation of Xiaoyi Liu and Jeff Weinstein in helping to author + the original versions of this document. + + The authors would like to thank Brian LaMacchia for his work in + developing and writing up many of the concepts presented in this + document. The authors would also like to thank Alex Deacon and Barb + Fox for their contributions. + +11. References + +11.1. Normative References + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + [CRMF] Schaad, J., "Internet X.509 Certification Request + Message Format", RFC 4211, January 2005. + + [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman + Proof-of-Possession Algorithms", RFC 2875, June 2000. + + [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax + v1.5", RFC 2314, October 1997. + + Note that this version of PKCS #10 is used for + compatibility with the use of 1988 ASN.1 syntax. An + effort is currently underway in the PKIX working group + to update to use 2003 ASN.1 syntax. + + [PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, + "Internet X.509 Public Key Infrastructure Certificate + and Certificate Revocation List (CRL) Profile", + RFC 3280, April 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + +11.2. Informative References + + [CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over + CMS (CMC): Transport Protocols", RFC 5273, June 2008. + + [CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management + Messages over CMS (CMC): Compliance Requirements", + RFC 5274, June 2008. + + + +Schaad & Myers Standards Track [Page 63] + +RFC 5272 CMC: Structures June 2008 + + + [PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic + Authentication Guideline", NIST SP 800-63, April 2006. + + [RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [SMALL-GROUP] Zuccherato, R., "Methods for Avoiding the "Small- + Subgroup" Attacks on the Diffie-Hellman Key Agreement + Method for S/MIME", RFC 2785, March 2000. + + [X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, + "Certificate Management Messages over CMS", RFC 2797, + April 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 64] + +RFC 5272 CMC: Structures June 2008 + + +Appendix A. ASN.1 Module + + EnrollmentMessageSyntax + { iso(1) identified-organization(3) dod(4) internet(1) + security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + -- EXPORTS All -- + -- The types and values defined in this module are exported for use + -- in the other ASN.1 modules. Other applications may use them for + -- their own purposes. + + IMPORTS + + -- PKIX Part 1 - Implicit From [PKIXCERT] + GeneralName, CRLReason, ReasonFlags + FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-implicit(19)} + + -- PKIX Part 1 - Explicit From [PKIXCERT] + AlgorithmIdentifier, Extension, Name, CertificateSerialNumber + FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-explicit(18)} + + -- Cryptographic Message Syntax FROM [CMS] + ContentInfo, Attribute, IssuerAndSerialNumber + FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + modules(0) cms-2004(24)} + + -- CRMF FROM [CRMF] + CertReqMsg, PKIPublicationInfo, CertTemplate + FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-crmf2005(36)}; + + -- Global Types + UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING + -- The content of this type conforms to RFC 2279. + + + + + + + + +Schaad & Myers Standards Track [Page 65] + +RFC 5272 CMC: Structures June 2008 + + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls + id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types + + -- The following controls have the type OCTET STRING + + id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3} + id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4} + id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18} + id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19} + id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21} + id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22} + id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23} + + -- The following controls have the type UTF8String + + id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} + + -- The following controls have the type INTEGER + + id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5} + + -- The following controls have the type OCTET STRING + + id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6} + id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7} + + -- This is the content type used for a request message in the protocol + + id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } + + PKIData ::= SEQUENCE { + controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, + reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest, + cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, + otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg + } + + bodyIdMax INTEGER ::= 4294967295 + + BodyPartID ::= INTEGER(0..bodyIdMax) + + + + + + + + +Schaad & Myers Standards Track [Page 66] + +RFC 5272 CMC: Structures June 2008 + + + TaggedAttribute ::= SEQUENCE { + bodyPartID BodyPartID, + attrType OBJECT IDENTIFIER, + attrValues SET OF AttributeValue + } + + AttributeValue ::= ANY + + TaggedRequest ::= CHOICE { + tcr [0] TaggedCertificationRequest, + crm [1] CertReqMsg, + orm [2] SEQUENCE { + bodyPartID BodyPartID, + requestMessageType OBJECT IDENTIFIER, + requestMessageValue ANY DEFINED BY requestMessageType + } + } + + TaggedCertificationRequest ::= SEQUENCE { + bodyPartID BodyPartID, + certificationRequest CertificationRequest + } + + CertificationRequest ::= SEQUENCE { + certificationRequestInfo SEQUENCE { + version INTEGER, + subject Name, + subjectPublicKeyInfo SEQUENCE { + algorithm AlgorithmIdentifier, + subjectPublicKey BIT STRING }, + attributes [0] IMPLICIT SET OF Attribute }, + signatureAlgorithm AlgorithmIdentifier, + signature BIT STRING + } + + TaggedContentInfo ::= SEQUENCE { + bodyPartID BodyPartID, + contentInfo ContentInfo + } + + OtherMsg ::= SEQUENCE { + bodyPartID BodyPartID, + otherMsgType OBJECT IDENTIFIER, + otherMsgValue ANY DEFINED BY otherMsgType } + + + + + + + +Schaad & Myers Standards Track [Page 67] + +RFC 5272 CMC: Structures June 2008 + + + -- This defines the response message in the protocol + id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 } + + ResponseBody ::= PKIResponse + + PKIResponse ::= SEQUENCE { + controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, + cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo, + otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg + + } + + -- Used to return status state in a response + + id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1} + + CMCStatusInfo ::= SEQUENCE { + cMCStatus CMCStatus, + bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, + statusString UTF8String OPTIONAL, + otherInfo CHOICE { + failInfo CMCFailInfo, + pendInfo PendInfo } OPTIONAL + } + + PendInfo ::= SEQUENCE { + pendToken OCTET STRING, + pendTime GeneralizedTime + } + + CMCStatus ::= INTEGER { + success (0), + failed (2), + pending (3), + noSupport (4), + confirmRequired (5), + popRequired (6), + partial (7) + } + + -- Note: + -- The spelling of unsupportedExt is corrected in this version. + -- In RFC 2797, it was unsuportedExt. + + + + + + + + +Schaad & Myers Standards Track [Page 68] + +RFC 5272 CMC: Structures June 2008 + + + CMCFailInfo ::= INTEGER { + badAlg (0), + badMessageCheck (1), + badRequest (2), + badTime (3), + badCertId (4), + unsupportedExt (5), + mustArchiveKeys (6), + badIdentity (7), + popRequired (8), + popFailed (9), + noKeyReuse (10), + internalCAError (11), + tryLater (12), + authDataFail (13) + } + + -- Used for RAs to add extensions to certification requests + id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8} + + AddExtensions ::= SEQUENCE { + pkiDataReference BodyPartID, + certReferences SEQUENCE OF BodyPartID, + extensions SEQUENCE OF Extension + } + + + id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} + id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10} + + EncryptedPOP ::= SEQUENCE { + request TaggedRequest, + cms ContentInfo, + thePOPAlgID AlgorithmIdentifier, + witnessAlgID AlgorithmIdentifier, + witness OCTET STRING + } + + DecryptedPOP ::= SEQUENCE { + bodyPartID BodyPartID, + thePOPAlgID AlgorithmIdentifier, + thePOP OCTET STRING + } + + id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} + + + + + + +Schaad & Myers Standards Track [Page 69] + +RFC 5272 CMC: Structures June 2008 + + + LraPopWitness ::= SEQUENCE { + pkiDataBodyid BodyPartID, + bodyIds SEQUENCE OF BodyPartID + } + + -- + id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15} + + GetCert ::= SEQUENCE { + issuerName GeneralName, + serialNumber INTEGER } + + id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} + + GetCRL ::= SEQUENCE { + issuerName Name, + cRLName GeneralName OPTIONAL, + time GeneralizedTime OPTIONAL, + reasons ReasonFlags OPTIONAL } + + id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} + + RevokeRequest ::= SEQUENCE { + issuerName Name, + serialNumber INTEGER, + reason CRLReason, + invalidityDate GeneralizedTime OPTIONAL, + passphrase OCTET STRING OPTIONAL, + comment UTF8String OPTIONAL } + + id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24} + + CMCCertId ::= IssuerAndSerialNumber + + -- The following is used to request V3 extensions be added to a + -- certificate + + id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) 14} + + ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension + + -- The following exists to allow Diffie-Hellman Certification Requests + -- Messages to be well-formed + + id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} + + NoSignatureValue ::= OCTET STRING + + + +Schaad & Myers Standards Track [Page 70] + +RFC 5272 CMC: Structures June 2008 + + + -- Unauthenticated attribute to carry removable data. + -- This could be used in an update of "CMC Extensions: Server Side + -- Key Generation and Key Escrow" (February 2005) and in other + -- documents. + + id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) + rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)} + id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34} + + CMCUnsignedData ::= SEQUENCE { + bodyPartPath BodyPartPath, + identifier OBJECT IDENTIFIER, + content ANY DEFINED BY identifier + } + + -- Replaces CMC Status Info + -- + + id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25} + + CMCStatusInfoV2 ::= SEQUENCE { + cMCStatus CMCStatus, + bodyList SEQUENCE SIZE (1..MAX) OF + BodyPartReference, + statusString UTF8String OPTIONAL, + otherInfo CHOICE { + failInfo CMCFailInfo, + pendInfo PendInfo, + extendedFailInfo SEQUENCE { + failInfoOID OBJECT IDENTIFIER, + failInfoValue AttributeValue + } + } OPTIONAL + } + + BodyPartReference ::= CHOICE { + bodyPartID BodyPartID, + bodyPartPath BodyPartPath + } + + BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID + + + + + + + + + + +Schaad & Myers Standards Track [Page 71] + +RFC 5272 CMC: Structures June 2008 + + + -- Allow for distribution of trust anchors + -- + + id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26} + + PublishTrustAnchors ::= SEQUENCE { + seqNumber INTEGER, + hashAlgorithm AlgorithmIdentifier, + anchorHashes SEQUENCE OF OCTET STRING + } + + id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27} + + AuthPublish ::= BodyPartID + + -- These two items use BodyPartList + id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28} + id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29} + + BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID + + -- + id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30} + + CMCPublicationInfo ::= SEQUENCE { + hashAlg AlgorithmIdentifier, + certHashes SEQUENCE OF OCTET STRING, + pubInfo PKIPublicationInfo + } + + id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31} + + ModCertTemplate ::= SEQUENCE { + pkiDataReference BodyPartPath, + certReferences BodyPartList, + replace BOOLEAN DEFAULT TRUE, + certTemplate CertTemplate + } + + -- Inform follow on servers that one or more controls have already been + -- processed + + id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32} + + ControlsProcessed ::= SEQUENCE { + bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference + } + + + + +Schaad & Myers Standards Track [Page 72] + +RFC 5272 CMC: Structures June 2008 + + + -- Identity Proof control w/ algorithm agility + + id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 } + + IdentifyProofV2 ::= SEQUENCE { + proofAlgID AlgorithmIdentifier, + macAlgId AlgorithmIdentifier, + witness OCTET STRING + } + + id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 } + PopLinkWitnessV2 ::= SEQUENCE { + keyGenAlgorithm AlgorithmIdentifier, + macAlgorithm AlgorithmIdentifier, + witness OCTET STRING + } + + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 73] + +RFC 5272 CMC: Structures June 2008 + + +Appendix B. Enrollment Message Flows + + This section is informational. The purpose of this section is to + present, in an abstracted version, the messages that would flow + between the client and server for several different common cases. + +B.1. Request of a Signing Certificate + + This section looks at the messages that would flow in the event that + an enrollment is occurring for a signing-only key. If the + certificate was designed for both signing and encryption, the only + difference would be the key usage extension in the certification + request. + + Message #2 from client to server: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIData + eContent + controlSequence + {102, id-cmc-identityProof, computed value} + {103, id-cmc-senderNonce, 10001} + reqSequence + certRequest + certReqId = 201 + certTemplate + subject = My Proposed DN + publicKey = My Public Key + extensions + {id-ce-subjectPublicKeyIdentifier, 1000} + {id-ce-keyUsage, digitalSignature} + SignedData.SignerInfos + SignerInfo + sid.subjectKeyIdentifier = 1000 + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 74] + +RFC 5272 CMC: Structures June 2008 + + + Response from server to client: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {102, id-cmc-statusInfoV2, {success, 201}} + {103, id-cmc-senderNonce, 10005} + {104, id-cmc-recipientNonce, 10001} + certificates + Newly issued certificate + Other certificates + SignedData.SignerInfos + Signed by CA + +B.2. Single Certification Request, But Modified by RA + + This section looks at the messages that would flow in the event that + an enrollment has one RA in the middle of the data flow. That RA + will modify the certification request before passing it on to the CA. + + Message from client to RA: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIData + eContent + controlSequence + {102, id-cmc-identityProof, computed value} + {103, id-cmc-senderNonce, 10001} + reqSequence + certRequest + certReqId = 201 + certTemplate + subject = My Proposed DN + publicKey = My Public Key + extensions + {id-ce-subjectPublicKeyIdentifier, 1000} + {id-ce-keyUsage, digitalSignature} + SignedData.SignerInfos + SignerInfo + sid.subjectKeyIdentifier = 1000 + + + + + + +Schaad & Myers Standards Track [Page 75] + +RFC 5272 CMC: Structures June 2008 + + + Message from RA to CA: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIData + eContent + controlSequence + { 102, id-cmc-batchRequests, { 1, 2} } + { 103, id-cmc-addExtensions, + { {1, 201, {id-ce-certificatePolicies, anyPolicy}} + {1, 201, {id-ce-subjectAltName, {extension data}} + {2, XXX, {id-ce-subjectAltName, {extension data}}} + The Value XXX is not known here; it would + reference into the second client request, + which is not displayed above. + cmsSequence + { 1, } + { 2, } + SignedData.SignerInfos + SignerInfo + sid = RA key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 76] + +RFC 5272 CMC: Structures June 2008 + + + Response from CA to RA: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {102, id-cmc-BatchResponse, {999, 998}} + + {103, id-cmc-statusInfoV2, {failed, 2, badIdentity}} + cmsSequence + { bodyPartID = 999 + contentInfo + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {102, id-cmc-statusInfoV2, {success, 201}} + certificates + Newly issued certificate + Other certificates + SignedData.SignerInfos + Signed by CA + } + { bodyPartID = 998, + contentInfo + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {102, id-cmc-statusInfoV2, {failure, badAlg}} + certificates + Newly issued certificate + Other certificates + SignedData.SignerInfos + Signed by CA + } + SignedData.SignerInfos + Signed by CA + + + + + + + +Schaad & Myers Standards Track [Page 77] + +RFC 5272 CMC: Structures June 2008 + + + Response from RA to client: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {102, id-cmc-statusInfoV2, {success, 201}} + certificates + Newly issued certificate + Other certificates + SignedData.SignerInfos + Signed by CA + +B.3. Direct POP for an RSA Certificate + + This section looks at the messages that would flow in the event that + an enrollment is done for an encryption only certificate using an + direct POP method. For simplicity, it is assumed that the + certification requester already has a signing-only certificate. + + The fact that a second round-trip is required is implicit rather than + explicit. The server determines this based on the fact that no other + POP exists for the certification request. + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 78] + +RFC 5272 CMC: Structures June 2008 + + + Message #1 from client to server: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIData + eContent + controlSequence + {102, id-cmc-transactionId, 10132985123483401} + {103, id-cmc-senderNonce, 10001} + {104, id-cmc-dataReturn, } + reqSequence + certRequest + certReqId = 201 + certTemplate + subject = + publicKey = My Public Key + extensions + {id-ce-keyUsage, keyEncipherment} + popo + keyEncipherment + subsequentMessage + SignedData.SignerInfos + SignerInfo + Signed by requester's signing cert + + Response #1 from server to client: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {101, id-cmc-statusInfoV2, {failed, 201, popRequired}} + {102, id-cmc-transactionId, 10132985123483401} + {103, id-cmc-senderNonce, 10005} + {104, id-cmc-recipientNonce, 10001} + {105, id-cmc-encryptedPOP, { + request { + certRequest + certReqId = 201 + certTemplate + subject = + publicKey = My Public Key + extensions + {id-ce-keyUsage, keyEncipherment} + + + +Schaad & Myers Standards Track [Page 79] + +RFC 5272 CMC: Structures June 2008 + + + popo + keyEncipherment + subsequentMessage + } + cms + contentType = id-envelopedData + content + recipientInfos.riid.issuerSerialNumber = + encryptedContentInfo + eContentType = id-data + eContent = + thePOPAlgID = HMAC-SHA1 + witnessAlgID = SHA-1 + witness }} + {106, id-cmc-dataReturn, } + certificates + Other certificates (optional) + SignedData.SignerInfos + Signed by CA + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIData + eContent + controlSequence + {102, id-cmc-transactionId, 10132985123483401} + {103, id-cmc-senderNonce, 100101} + {104, id-cmc-dataReturn, } + {105, id-cmc-recipientNonce, 10005} + {107, id-cmc-decryptedPOP, { + bodyPartID 201, + thePOPAlgID HMAC-SHA1, + thePOP }} + reqSequence + certRequest + certReqId = 201 + certTemplate + subject = + publicKey = My Public Key + extensions + {id-ce-keyUsage, keyEncipherment} + popo + keyEncipherment + subsequentMessage + + + + +Schaad & Myers Standards Track [Page 80] + +RFC 5272 CMC: Structures June 2008 + + + SignedData.SignerInfos + SignerInfo + Signed by requester's signing cert + + Response #2 from server to client: + + ContentInfo.contentType = id-signedData + ContentInfo.content + SignedData.encapContentInfo + eContentType = id-ct-PKIResponse + eContent + controlSequence + {101, id-cmc-transactionId, 10132985123483401} + {102, id-cmc-statusInfoV2, {success, 201}} + {103, id-cmc-senderNonce, 10019} + {104, id-cmc-recipientNonce, 100101} + {105, id-cmc-dataReturn, } + certificates + Newly issued certificate + Other certificates + SignedData.SignerInfos + Signed by CA + +Appendix C. Production of Diffie-Hellman Public Key Certification + Requests + + Part of a certification request is a signature over the request; + Diffie-Hellman is a key agreement algorithm and cannot be used to + directly produce the required signature object. [DH-POP] provides + two ways to produce the necessary signature value. This document + also defines a signature algorithm that does not provide a POP value, + but can be used to produce the necessary signature value. + +C.1. No-Signature Signature Mechanism + + Key management (encryption/decryption) private keys cannot always be + used to produce some type of signature value as they can be in a + decrypt-only device. Certification requests require that the + signature field be populated. This section provides a signature + algorithm specifically for that purposes. The following object + identifier and signature value are used to identify this signature + type: + + id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} + + NoSignatureValue ::= OCTET STRING + + + + +Schaad & Myers Standards Track [Page 81] + +RFC 5272 CMC: Structures June 2008 + + + The parameters for id-alg-noSignature MUST be present and MUST be + encoded as NULL. NoSignatureValue contains the hash of the + certification request. It is important to realize that there is no + security associated with this signature type. If this signature type + is on a certification request and the Certification Authority policy + requires proof-of-possession of the private key, the POP mechanism + defined in Section 6.7 MUST be used. + +Authors' Addresses + + Jim Schaad + Soaring Hawk Consulting + PO Box 675 + Gold Bar, WA 98251 + + Phone: (425) 785-1031 + EMail: jimsch@nwlink.com + + + Michael Myers + TraceRoute Security, Inc. + + EMail: mmyers@fastq.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 82] + +RFC 5272 CMC: Structures June 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Schaad & Myers Standards Track [Page 83] + -- cgit v1.2.3