One document matched: draft-ietf-pkix-2797-bis-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="7"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc ipr="full3978" docName="draft-ietf-pkix-2797-bis-06.txt">
<front>
<title abbrev="CMC: Structures">Certificate Management Messages over CMS</title>
<author initials="J." surname="Schaad" fullname="Jim Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<postal>
<street>PO Box 675</street>
<city>Gold Bar</city>
<region>WA</region>
<code>98251</code>
</postal>
<phone>(425) 785-1031</phone>
<email>jimsch@nwlink.com</email>
</address>
</author>
<author initials="M." surname="Myers" fullname="Michael Myers">
<organization>TraceRoute Security, Inc.</organization>
<address>
<email>mmyers@fastq.inc</email>
</address>
</author>
<date year="2007" month="December"/>
<abstract>
<t>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:</t>
<list style="numbers">
<t>The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and</t>
<t>The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t>
</list>
<t>CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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:</t>
<list style="numbers">
<t> The need for an interface to public key certification products and services based on CMS and PKCS #10, and</t>
<t>The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.</t>
</list>
<t>A small number of additional services are defined to supplement the core certification request service.</t>
<section title="Protocol Requirements">
<list style="empty">
<t>The protocol must be based as much as possible on the existing CMS, PKCS #10 <xref target="PKCS10"/> and CRMF (Certificate Request Message Format) <xref target="CRMF"/> specifications.</t>
<t>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.</t>
<t>The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.</t>
<t>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.</t>
<t>The protocol must be designed such that all key generation can occur on the client.</t>
<t>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.</t>
<t>The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round trip POP will be made if necessary.</t>
<t>The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.</t>
<t>The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs).</t>
</list>
</section>
<section title="Requirements Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Changes since RFC 2797">
<t>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 <xref target="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 <xref target="CMC-MUST"/>.</t>
<t>A number of new controls have been added in this version:</t>
<list type="empty">
<t>Extended CMC Status Info <xref target="c_statusInfoV2"/></t>
<t>Publish Trust Anchors <xref target="c_trustAnchors"/></t>
<t>Authenticate Data <xref target="c_authData"/></t>
<t>Batch Request and Response Processing <xref target="c_batchRequests"/></t>
<t>Publication Information <xref target="c_publishCert"/></t>
<t>Modify Certificate Request <xref target="c_modCertTemplate"/></t>
<t>Control Processed <xref target="c_controlProcessed"/></t>
<t>Identity Proof <xref target="c_identityProof"/></t>
<t>Identity POP Link Witness V2 <xref target="c_popLinkWitness2"/></t>
</list>
</section>
</section>
<section title="Protocol Overview">
<t>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 Responses, is then returned from the server to the client. In more complicated cases, such as delayed certificate issuance, more than one round trip is required.</t>
<t>This specification defines two PKI Request types and two PKI Response types.</t>
<t>PKI Requests are formed using either the PKCS #10 or CRMF structure. The two PKI Requests are:</t>
<list style="hanging">
<t hangText="Simple PKI Request:"> the bare PKCS #10 (in the event that no other services are needed), and</t>
<t hangText="Full PKI Request:"> one or more PKCS #10, CRMF or Other Request Messages structures wrapped in a CMS encapsulation as part of a PKIData.</t>
</list>
<t>PKI Responses are based on SignedData <xref target="CMS"/>. The two PKI Responses are</t>
<list style="hanging">
<t hangText="Simple PKI Response:">a "certs-only" SignedData (in the event no other services are needed), or</t>
<t hangText="Full PKI Response">a PKIResponse content-type wrapped in a SignedData.</t>
</list>
<t>No special services are provided for either renewal (i.e., a new certificate with the same key) or re-key (i.e., a new certificate with a new key) of client certificates. Instead renewal and re-key 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.)</t>
<t>No special services are provided to distinguish between a re-key request and a new certification request (generally for a new purpose). A control to unpublish a certificate would normally be included in a re-key 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.</t>
<t>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.</t>
<t>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 <xref target="CMC-TRANS"/>.</t>
<t>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.</t>
<section title="Terminology">
<t>There are several different terms, abbreviations and acronyms used in this document. These are defined here for convenience and consistency of usage in no particular order:</t>
<list style="hanging">
<t hangText="End-Entity"> (EE) refers to the entity that owns a key pair and for whom a certificate is issued.</t>
<t hangText="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.</t>
<t hangText="Certification Authority"> (CA) refers to the entity that issues certificates.</t>
<t hangText="Client"> refers to an entity that creates a PKI Request. In this document both RAs and EEs can be clients.</t>
<t hangText="Server"> refers to the entities that process PKI Requests and create PKI Responses. In this document both CAs and RAs can be servers.</t>
<t hangText="PKCS #10"> refers to the Public Key Cryptography Standard #10 <xref target="PKCS10"/>, which defines a certification request syntax.</t>
<t hangText="CRMF"> refers to the Certificate Request Message Format RFC <xref target="CRMF"/>. CMC uses this certification request syntax defined in this document as part of the protocol.</t>
<t hangText="CMS"> refers to the Cryptographic Message Syntax RFC <xref target="CMS"/>. This document provides for basic cryptographic services including encryption and signing with and without key management.</t>
<t hangText="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.</t>
<t hangText="Proof-Of-Identity"> refers to the client proving they are who they say that are to the server.</t>
<t hangText="Enrollment or certification request"> refers to the process of a client requesting a certificate. A certification request is a subset of the PKI Requests.</t>
<t hangText="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.</t>
<t hangText="Object IDentifier (OID)"> is a primitive type in Abstract Syntax Notation One (ASN.1).</t>
</list>
</section>
<section title="Protocol Request/Responses">
<t>Figure 1 shows the Simple PKI Requests and Responses. The contents of Simple PKI Request and Response are detailed in <xref target="s_SimpleRequest"/> and <xref target="s_SimpleResponse"/>.</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Responses are detailed in <xref target="s_FullRequest"/> and <xref target="s_FullResponse"/>.</t>
<figure>
<artwork>
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | 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
</artwork>
</figure>
</section>
</section>
<section title="PKI Requests" anchor="s_PKIRequests">
<t>Two types of PKI Requests exist. This section gives the details for both types.</t>
<section title="Simple PKI Request" anchor="s_SimpleRequest">
<t>A Simple PKI Request uses the PKCS #10 syntax CertificationRequest <xref target="PKCS10"/>.</t>
<t>When a server processes a Simple PKI Request, the PKI Response returned is:</t>
<list style="hanging">
<t hangText="Simple PKI Response"> on success.</t>
<t hangText="Full PKI Response"> on failure. The server MAY choose not to return a PKI Response in this case.</t>
</list>
<t>The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included.</t>
<t>The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature (i.e. DH keys can use the signature algorithms in <xref target="DH-POP"/> for production of the signature).</t>
<t>The Simple PKI Request cannot be used for any of the advanced services specified in this document.</t>
<t>The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq control. The ExtensionReq control is defined as:</t>
<figure>
<artwork>
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
</artwork>
</figure>
<t>where Extension is imported from <xref target="PKIXCERT"/> and ExtensionReq is identified by:</t>
<figure><artwork>
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
</artwork></figure>
<t>Servers MUST be able to process all extensions defined, but not prohibited, in <xref target="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.</t>
</section>
<section title="Full PKI Request" anchor="s_FullRequest">
<t>The Full PKI Request provides the most functionality and flexibility.</t>
<t>The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (<xref target="s_cct_PKIData"/>).</t>
<t>When a server process a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:</t>
<list style="hanging">
<t hangText="Simple PKI Response"> if the enrollment was successful and only certificates are returned. (A CMCStatusInfoV2 control with success is implied.)</t>
<t hangText="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.</t>
</list>
<t>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 used, then:</t>
<list style="letters">
<t>The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.</t>
<t>The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.</t>
<t>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.</t>
</list>
<t>If AuthenticatedData is used, then:</t>
<list style="letters">
<t>The Password Recipient Info option of RecipientInfo MUST be used.</t>
<t>A randomly generated key is used to compute the MAC value on the encapsulated content.</t>
<t>The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF8) and the shared-secret.</t>
</list>
<t>When creating a PKI Request to renew or rekey a certificate:</t>
<list style="letters">
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
</list>
<section title="PKIData content type" anchor="s_cct_PKIData">
<t>The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:</t>
<figure>
<artwork>
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
</artwork>
</figure>
<t>The ASN.1 structure corresponding to the PKIData content type is:</t>
<figure>
<artwork>
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
}
</artwork>
</figure>
<t>The fields in PKIData have the following meaning:</t>
<list style="hanging">
<t hangText="controlSequence"> is a sequence of controls. The controls defined in this document are found in <xref target="s_Controls"/>. Controls can be defined by other parties. Details on the TaggedAttribute structure can be found in <xref target="s_TaggedAttribute"/>.</t>
<t hangText="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 <xref target="s_RequestFormats"/>. 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 request are processed.</t>
<t hangText="cmsSequence"> is a sequence of <xref target="CMS"/> message objects. See <xref target="s_ContentInfo"/> for more details.</t>
<t hangText="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 <xref target="s_OtherMsg"/> for more details.</t>
</list>
<t>All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see <xref target="c_batchRequests"/>) are expected to place the PKI Requests received into the cmsSequence of a PKIData.</t>
<t>Processing of the PKIData by a recipient is as follows:</t>
<list style="numbers">
<t>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.</t>
<t> 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.</t>
<t>Finally the to-do list is processed. In many cases the to-do list will be ordered by grouping specific tasks together.</t>
</list>
<t>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.</t>
<section title="Control Syntax" anchor="s_TaggedAttribute">
<t>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.</t>
<t>The syntax of a control is:</t>
<figure>
<artwork>
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
</artwork>
</figure>
<t>The fields in TaggedAttribute have the following meaning:</t>
<list style="hanging">
<t hangText="bodyPartID"> is a unique integer that identifies this control.</t>
<t hangText="attrType"> is the OID that identifies the control.</t>
<t hangText="attrValues"> is the data values used in processing the control. The structure of the data is dependent on the specific control.</t>
</list>
<t>
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 <xref target="c_controlProcessed"/>) 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.</t>
<t>The controls defined by this document are found in <xref target="s_Controls"/>.</t>
</section>
<section title="Certification Request Formats" anchor="s_RequestFormats">
<t>Certification Requests are based on PKCS #10, CRMF or Other Request formats. <xref target="s_ReqPKCS10"/> specifies the requirements for clients and servers dealing with PKCS #10. <xref target="s_ReqCRMF"/> specifies the requirements for clients and servers dealing with CRMF. <xref target="s_ReqOther"/> specifies the requirements for clients and servers dealing with Other Request.</t>
<figure><artwork>
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
</artwork></figure>
<t>The fields in TaggedRequest have the following meaning:</t>
<list style="hanging">
<t hangText="tcr"> is a certification request that uses the PKCS #10 syntax. Details on PKCS #10 are found in <xref target="s_ReqPKCS10"/>.</t>
<t hangText="crm"> is a certification request that uses the CRMF syntax. Details on CRMF are found in <xref target="s_ReqCRMF"/>.</t>
<t hangText="orm"> is an externally defined certification request. One example is an attribute certification request. The fields of this structure are:</t>
<list style="hanging">
<t hangText="bodyPartID"> is the identifier number for this certification request. Details on body part identifiers are found in <xref target="s_BodyPartID"/>.</t>
<t hangText="requestMessageType"> identifies the other request type. These values are defined outside of this document.</t>
<t hangText="requestMessageValue"> is the data associated with the other request type.</t>
</list>
</list>
<section title="PKCS #10 Certification Syntax" anchor="s_ReqPKCS10">
<t>A certification request based on PKCS #10 uses the following ASN.1 structure:</t>
<figure><artwork>
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
</artwork></figure>
<t>The fields in TaggedCertificationRequest have the following meaning:</t>
<list style="hanging">
<t hangText="bodyPartID"> is the identifier number for this certification request. Details on body part identifiers are found in <xref target="s_BodyPartID"/>.</t>
<t hangText="certificationRequest"> contains the PKCS #10 based certification request. Its fields are described in <xref target="PKCS10"/>.</t>
</list>
<t>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.</t>
</section>
<section title="CRMF Certification Syntax" anchor="s_ReqCRMF">
<t>A CRMF message uses the following ASN.1 structure (defined in [CRMF] and included here for convenience):</t>
<figure><artwork>
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 }
</artwork></figure>
<t>The fields in CertReqMsg are explained in [CRMF].</t>
<t>This document imposes the following additional restrictions on the construction and processing of CRMF certification requests:</t>
<list style="empty">
<t>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.</t>
<t>When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control.</t>
<t>The regInfo field MUST NOT be used on a CRMF certification request. Equivalent functionality is provided in the CMC regInfo control (<xref target="c_regInfo"/>).</t>
<t>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 instead if POP is desired. The value of encrCert in SubsequentMessage MUST NOT be used.</t>
<t>Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.</t>
</list>
<t>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 <xref target="PKIXCERT"/>. Servers are not required to be able to process other X.509v3 extension 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.</t>
</section>
<section title="Other Certification Request" anchor="s_ReqOther">
<t>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.</t>
</section>
</section>
<section title="Content Info Objects" anchor="s_ContentInfo">
<t>The cmsSequence field of the PKIData and PKIResponse messages contains zero or more tagged content info objects. The syntax for this structure is:</t>
<figure>
<artwork>
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
</artwork>
</figure>
<t>The fields in TaggedContentInfo have the following meaning:</t>
<list style="hanging">
<t hangText="bodyPartID"> is a unique integer that identifies this content info object.</t>
<t hangText="contentInfo"> is a ContentInfo object (defined in <xref target="CMS"/>).</t>
</list>
<t>The four content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData and SignedData. All of these content types are defined in <xref target="CMS"/>.</t>
<section title="Authenticated Data">
<t>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.</t>
<t>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 anchors has not been installed on the client or no certificate exists for a signing key.</t>
<t>AuthenticatedData content type is used by this document for:</t>
<list type="empty">
<t>The id-cmc-authData control (<xref target="c_authData"/>), and</t>
<t>As the top-level wrapper in environments where an encryption only key is being certified.</t>
</list>
<t>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.</t>
</section>
<section title="Data">
<t>The Data content type allows for general transport of unstructured data.</t>
<t>The Data content type is used by this document for:</t>
<list type="empty">
<t>Holding the encrypted random value y for POP proof in the encrypted POP control (see <xref target="c_encryptedPOP"/>).</t>
</list>
</section>
<section title="Enveloped Data">
<t>The EnvelopedData content type provides for shrouding of data.</t>
<t>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 <xref target="s_PKI_Encrypt"/>). EnvelopedData can also be used to wrap private key material for key archival. If the decryption on an EnvelopedData fails, the Full PKI Response with a CMCFailInfo value with a value of badMessageCheck and a bodyPartId of 0.</t>
</section>
<section title="Signed Data">
<t>The SignedData content type provides for authentication and integrity.</t>
<t>The SignedData content type is used by this document for:</t>
<list type="empty">
<t>The outer wrapper for a PKI Request.</t>
<t>The outer wrapper for a PKI Response.</t>
</list>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Other Message Bodies" anchor="s_OtherMsg">
<t>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 <xref target="s_ContentInfo"/>. The data object is ignored unless a control references the data object by bodyPartID.</t>
<figure>
<artwork>
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
</artwork>
</figure>
<t>The fields in OtherMsg have the following meaning:</t>
<list style="hanging">
<t hangText="bodyPartID"> is the unique id identifying this data object.</t>
<t hangText="otherMsgType"> is the OID that defines the type of message body</t>
<t hangText="otherMsgValue"> is the data.</t>
</list>
</section>
</section>
<section title="Body Part Identification" anchor="s_BodyPartID">
<t>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:</t>
<figure><artwork>
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
</artwork></figure>
<t>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).</t>
<t>The bodyPartId value of 0 is reserved for use as the reference to the current PKIData object.</t>
<t>Some controls, such as the Add Extensions control (<xref target="c_addExtensions"/>) 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 (<xref target="c_statusInfoV2"/>), will also use body part identifiers to refer to elements in the previous PKI Request/Response. This allows an error to be explicit about the control or PKI Request to which the error applies.</t>
<t>A BodyPartList contains a list of body parts in a PKI Request/Response (i.e. the Batch Request control in <xref target="c_batchRequests"/>). The ASN.1 type BodyPartList is defined as:</t>
<figure><artwork>
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
</artwork></figure>
<t>A BodyPartPath contains a path of body part identifiers moving through nesting (i.e. the Modify Certificate Request control in <xref target="c_modCertTemplate"/>). The ASN.1 type BodyPartPath is defined as:</t>
<figure><artwork>
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
</artwork></figure>
</section>
<section title="CMC Unsigned Data Attribute">
<t>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 which 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.</t>
<t>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 it in a cmsSequence and placed in the unsigned or unauthenticated attributes of the RA's signed or authenticated data wrapper.</t>
<t> The CMC Unsigned Data attribute is identified by:</t>
<figure>
<artwork>
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
</artwork></figure>
<t>The CMC Unsigned Data attribute has the ASN.1 definition:</t>
<figure><artwork>
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
</artwork>
</figure>
<t>The fields in CMCUnsignedData have the following meaning:</t>
<list style="hanging">
<t hangText="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 pre-pended to the bodyPartPath sequence.</t>
<t hangText="identifier">is the OID that defines the associated data.</t>
<t hangText="content"> is the data.</t>
</list>
<t>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.</t>
</section>
</section>
</section>
<section title="PKI Responses" anchor="s_PKIResponse">
<t>Two types of PKI Responses exist. This section gives the details on both types.</t>
<section title="Simple PKI Response" anchor="s_SimpleResponse">
<t>
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.</t>
<t>
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 <xref target="c_trustAnchors"/> 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.)
</t>
</section>
<section title="Full PKI Response" anchor="s_FullResponse">
<t>Clients MUST be able to process a Full PKI Response.</t>
<t>The Full PKI Response consists of a SignedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.</t>
<t>
Clients MUST NOT assume the certificates are in any order.
Servers SHOULD include all intermediate certificates needed to form complete chains 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 <xref target="c_trustAnchors"/> 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.)</t>
<section title="PKIResponse Content Type">
<t>The PKIResponse content type is used for the Full PKI Response. The PKIResponse content type is identified by:</t>
<figure>
<artwork>
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
</artwork>
</figure>
<t>The ASN.1 structure corresponding to the PKIResponse content type is:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Note: In <xref target="RFC2797"/>, this ASN.1 type was named ResponseBody. It has been renamed to PKIResponse for clarity and the old name kept as a synonym.</t>
<t>The fields in PKIResponse have the following meaning:</t>
<list style="hanging">
<t hangText="controlSequence"> is a sequence of controls. The controls defined in this document are found in <xref target="s_Controls"/>. Controls can be defined by other parties. Details on the TaggedAttribute structure are found in <xref target="s_TaggedAttribute"/>.</t>
<t hangText="cmsSequence"> is a sequence of <xref target="CMS"/> message objects. See <xref target="s_ContentInfo"/> for more details.</t>
<t hangText="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 <xref target="s_OtherMsg"/> for more details.</t>
</list>
<t>Processing of PKIResponse by a recipient is as follows:</t>
<list style="numbers">
<t> 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.</t>
<t> 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.</t>
</list>
<t>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.</t>
</section>
</section>
</section>
<section title="Application of Encryption to a PKI Request/Response" anchor="s_PKI_Encrypt">
<t>
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.
</t>
<t>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 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:</t>
<figure>
<artwork>
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
</artwork>
</figure>
<t>Note: PKIResponse can be substituted for PKIData in the above figure.</t>
<t>
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 forwards 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.
<xref target="s_RA_Processing"/> contains more information about RA processing.</t>
<t>Full PKI Requests/Responses can be encrypted or transmitted in the clear. Servers MUST provided support for all three options.</t>
<t>
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.</t>
</section>
<section title="Controls" anchor="s_Controls">
<t>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 <xref target="s_TaggedAttribute"/>. 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.</t>
<t>The OIDs are all defined under the following arc:</t>
<figure>
<artwork>
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 }
</artwork>
</figure>
<texttable anchor="control_table" title="CMC Control Attributes">
<preamble>The following table lists the names, OID and syntactic structure for each of the controls described in this document.</preamble>
<ttcol align="left">Control Identifier</ttcol>
<ttcol align="left">OID</ttcol>
<ttcol align="left">Syntax</ttcol>
<ttcol align="left">Section</ttcol>
<c> id-cmc-statusInfo </c>
<c> id-cmc 1 </c>
<c> CMCStatusInfo </c>
<c>
<xref target="c_statusInfo"/>
</c>
<c> id-cmc-identification </c>
<c> id-cmc 2 </c>
<c> UTF8String </c>
<c>
<xref target="c_identification"/>
</c>
<c> id-cmc-identityProof </c>
<c> id-cmc 3 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_identityProof"/>
</c>
<c> id-cmc-dataReturn </c>
<c> id-cmc 4 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_dataReturn"/>
</c>
<c> id-cmc-transactionId </c>
<c> id-cmc 5 </c>
<c> INTEGER </c>
<c>
<xref target="c_transactionId"/>
</c>
<c> id-cmc-senderNonce </c>
<c> id-cmc 6 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_transactionId"/>
</c>
<c> id-cmc-recipientNonce </c>
<c> id-cmc 7 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_transactionId"/>
</c>
<c> id-cmc-addExtensions </c>
<c> id-cmc 8 </c>
<c> AddExtensions </c>
<c>
<xref target="c_addExtensions"/>
</c>
<c> id-cmc-encryptedPOP </c>
<c> id-cmc 9 </c>
<c> EncryptedPOP </c>
<c>
<xref target="c_encryptedPOP"/>
</c>
<c> id-cmc-decryptedPOP </c>
<c> id-cmc 10 </c>
<c> DecryptedPOP </c>
<c>
<xref target="c_encryptedPOP"/>
</c>
<c> id-cmc-lraPOPWitness </c>
<c> id-cmc 11 </c>
<c> LraPOPWitness </c>
<c>
<xref target="c_lraPOPWitness"/>
</c>
<c> id-cmc-getCert </c>
<c> id-cmc 15 </c>
<c> GetCert </c>
<c>
<xref target="c_getCert"/>
</c>
<c> id-cmc-getCRL </c>
<c> id-cmc 16 </c>
<c> GetCRL </c>
<c>
<xref target="c_getCRL"/>
</c>
<c> id-cmc-revokeRequest </c>
<c> id-cmc 17 </c>
<c> RevokeRequest </c>
<c>
<xref target="c_revokeRequest"/>
</c>
<c> id-cmc-regInfo </c>
<c> id-cmc 18 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_regInfo"/>
</c>
<c> id-cmc-responseInfo </c>
<c> id-cmc 19 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_regInfo"/>
</c>
<c> id-cmc-queryPending </c>
<c> id-cmc 21 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_queryPending"/>
</c>
<c> id-cmc-popLinkRandom </c>
<c> id-cmc 22 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_popLinkRandom"/>
</c>
<c> id-cmc-popLinkWitness </c>
<c> id-cmc 23 </c>
<c> OCTET STRING </c>
<c>
<xref target="c_popLinkWitness"/>
</c>
<c>id-cmc-popLinkWitnessV2</c>
<c> id-cmc 33 </c>
<c>OCTET STRING</c>
<c><xref target="c_popLinkWitness2"/></c>
<c> id-cmc-confirmCertAcceptance </c>
<c> id-cmc 24 </c>
<c> CMCCertId </c>
<c>
<xref target="c_confirmCertAcceptance"/>
</c>
<c> id-cmc-statusInfoV2 </c>
<c> id-cmc 25 </c>
<c> CMCStatusInfoV2 </c>
<c>
<xref target="c_statusInfoV2"/>
</c>
<c> id-cmc-trustedAnchors </c>
<c> id-cmc 26 </c>
<c> PublishTrustAnchors </c>
<c>
<xref target="c_trustAnchors"/>
</c>
<c> id-cmc-authData </c>
<c> id-cmc 27 </c>
<c> AuthPublish </c>
<c>
<xref target="c_authData"/>
</c>
<c> id-cmc-batchRequests </c>
<c> id-cmc 28 </c>
<c> BodyPartList </c>
<c>
<xref target="c_batchRequests"/>
</c>
<c> id-cmc-batchResponses </c>
<c> id-cmc 29 </c>
<c> BodyPartList </c>
<c>
<xref target="c_batchRequests"/>
</c>
<c> id-cmc-publishCert </c>
<c> id-cmc 30 </c>
<c> CMCPublicationInfo </c>
<c>
<xref target="c_publishCert"/>
</c>
<c> id-cmc-modCertTemplate </c>
<c> id-cmc 31 </c>
<c> ModCertTemplate </c>
<c>
<xref target="c_modCertTemplate"/>
</c>
<c> id-cmc-controlProcessed </c>
<c> id-cmc 32 </c>
<c> ControlsProcessed </c>
<c>
<xref target="c_controlProcessed"/>
</c>
<c> id-cmc-identityProof </c>
<c> id-cmc 34 </c>
<c> IdentityProofV2 </c>
<c>
<xref target="c_identityProof"/>
</c>
</texttable>
<section title="CMC Status Info Controls">
<t>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.</t>
<t>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.</t>
<section title="Extended CMC Status Info Control" anchor="c_statusInfoV2">
<t>The Extended CMC Status Info control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-statusInfoV2 ::= { id-cmc 25 }
</artwork>
</figure>
<t>The Extended CMC Status Info control has the ASN.1 definition:</t>
<figure>
<artwork>
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
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
</artwork>
</figure>
<t>The fields in CMCStatusInfoV2 have the following meaning:</t>
<list style="hanging">
<t hangText="cMCStatus"> contains the returned status value. Details are in <xref target="s_CMC_Status"/>.</t>
<t hangText="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.
</t>
<t hangText="statusString"> contains additional description information. This string is human readable.</t>
<t hangText="otherInfo"> contains additional information that expands on the CMC status code returned in the cMCStatus field. </t>
</list>
<t>The fields in OtherStatusInfo have the following meaning:</t>
<list style="hanging">
<t hangText="failInfo"> is described in <xref target="s_CMC_FailInfo"/>. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.</t>
<t hangText="pendInfo"> contains information about when and how the client should request for 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:</t>
<list style="hanging">
<t hangText="pendToken"> is the token used in the Query Pending control <xref target="c_queryPending"/>.</t>
<t hangText="pendTime"> contains the suggested time the server wants to be queried about the status of the certification request.</t>
</list>
<t hangText="extendedFailInfo"> includes application dependent detail 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:
</t>
<list style="hanging">
<t hangText="failInfoOID">contains an OID that is associated with a set of extended error values.</t>
<t hangText="failInfoValue">contains an extended error code from the defined set of extended error codes.</t>
</list>
</list>
<t>If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.</t>
</section>
<section title="CMC Status Info Control" anchor="c_statusInfo">
<t>The CMC Status Info control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-statusInfo ::= { id-cmc 1 }
</artwork>
</figure>
<t>The CMC Status Info control has the ASN.1 definition:</t>
<figure>
<artwork>
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
</artwork>
</figure>
<t> The fields in CMCStatusInfo have the following meaning:</t>
<list style="hanging">
<t hangText="cMCStatus"> contains the returned status value. Details are in <xref target="s_CMC_Status"/>.</t>
<t hangText="bodyList"> contains the list of controls or other element 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.</t>
<t hangText="statusString"> contains additional description information. This string is human readable.</t>
<t hangText="otherInfo"> provides additional information that expands on the CMC status code returned in the cMCStatus field.</t>
<list style="hanging">
<t hangText="failInfo"> is described in <xref target="s_CMC_FailInfo"/>. It provides an error code that details what failure occurred. This choice is present only if cMCStatus is failed.</t>
<t hangText="pendInfo"> uses the PendInfo ASN.1 structure in <xref target="c_statusInfoV2"/>. It contains information about when and how the client should request for results on this request. The pendInfo field MUST be populated for a cMCStatus value of pending or partial. Further details can be found in <xref target="c_statusInfoV2"/> (Extended CMC Status Info Control) and <xref target="c_queryPending"/> (Query Pending Control).</t>
</list>
</list>
<t>If the cMCStatus field is success, the CMC Status Info control MAY be omitted if 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.</t>
</section>
<section title="CMCStatus values" anchor="s_CMC_Status">
<t>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:</t>
<figure>
<artwork>
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
</artwork>
</figure>
<t>The values of CMCStatus have the following meaning:</t>
<list style="hanging">
<t hangText="success"> indicates the request was granted or the action was completed.</t>
<t hangText="failed"> indicates the request was not granted or the action was not completed. More information is included elsewhere in the response.</t>
<t hangText="pending">indicates the PKI Request has yet to be processed. The requestor is responsible to poll back on this Full PKI request. pending may only be returned for a certification request operations.</t>
<t hangText="noSupport">indicates the requested operation is not supported.</t>
<t hangText="confirmRequired">indicates a Confirm Certificate Acceptance control <xref target="c_confirmCertAcceptance"/> must be returned before the certificate can be used.</t>
<t hangText="popRequired">indicates an indirect POP operation is required <xref target="c_popLinkRandom"/>.</t>
<t hangText="partial">indicates a partial PKI Response is returned. The requestor is responsible to poll back for the unfulfilled portions of the Full PKI Request.</t>
</list>
</section>
<section title=" CMCFailInfo" anchor="s_CMC_FailInfo">
<t>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:</t>
<figure>
<artwork>
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsuportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
</artwork>
</figure>
<t>The values of CMCFailInfo have the following meanings:</t>
<list style="hanging">
<t hangText="badAlg">indicates unrecognized or unsupported algorithm.</t>
<t hangText="badMessageCheck">indicates integrity check failed.</t>
<t hangText="badRequest">indicates transaction not permitted or supported.</t>
<t hangText="badTime">indicates message time field was not sufficiently close to the system time.</t>
<t hangText="badCertId">indicates no certificate could be identified matching the provided criteria.</t>
<t hangText="unsuportedExt">indicates a requested X.509 extension is not supported by the recipient CA.</t>
<t hangText="mustArchiveKeys">indicates private key material must be supplied.</t>
<t hangText="badIdentity">indicates identification control failed to verify.</t>
<t hangText="popRequired">indicates server requires a POP proof before issuing certificate.</t>
<t hangText="popFailed">indicates POP processing failed.</t>
<t hangText="noKeyReuse">indicates server policy does not allow key reuse.</t>
<t hangText="internalCAError">indicates that the CA had an unknown internal failure.</t>
<t hangText="tryLater">indicates that the server is not accepting requests at this time and the client should try at a later time.</t>
<t hangText="authDataFail">indicates failure occurred during processing of authenticated data</t>
</list>
<t>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.</t>
</section>
</section>
<section title="Identification and Identity Proof Controls" anchor="s_IdProof">
<t>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 <xref target="CRMF"/>.</t>
<t>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 (<xref target="c_identityProof"/>). Servers MUST provide this method, but MAY additionally support bilateral methods of similar strength.</t>
<t>This document also provides an Identification control (<xref target="c_identification"/>). 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 is passed from the server to the client. The identifier is placed in the Identification control and the shared-secret is to compute the Identity Proof control.</t>
<section title="Identity Proof Version 2 Control" anchor="c_identityProofV2">
<t>The Identity Proof Version 2 control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-identityProofV2 ::= { id-cmc 34 }
</artwork>
</figure>
<t>The Identity Proof Version 2 control has the ASN.1 definition:</t>
<figure>
<artwork>
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}
</artwork>
</figure>
<t>The fields of IdentityProofV2 have the following meaning:</t>
<list style="hanging">
<t hangText="hashAlgID"> is the identifier and parameters for the hash algorithm used to convert the shared-secret into a key for the MAC algorithm.</t>
<t hangText="macAlgID">is the identifier and the parameters for the message authentication code algorithm used to compute the value of the witness field.</t>
<t hangText="witness">is the identity proof.</t>
</list>
<t>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:</t>
<list style="numbers">
<t>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.</t>
<t>A hash of the shared-secret as a UTF8 string is computed using hashAlgID.</t>
<t>A MAC is then computed using the value produced in Step 1 as the message and the value from Step 2 as the key.</t>
<t>The result from Step 3 is then encoded as the witness value in the Identity Proof Version 2 control.</t>
</list>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="PASSWORD"/>.</t>
</section>
<section title="Identity Proof Control" anchor="c_identityProof" >
<t>The Identity Proof control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-identityProof ::= { id-cmc 3 }
</artwork>
</figure>
<t>The Identity Proof control has the ASN.1 definition:</t>
<figure>
<artwork>
IdentifyProof ::= OCTET STRING
</artwork>
</figure>
<t>This control is process 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.</t>
</section>
<section title="Identification Control" anchor="c_identification">
<t>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 which 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 <xref target="c_identityProofV2"/> 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.</t>
<t >The Identification control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-identification ::= { id-cmc 2 }
</artwork>
</figure>
<t>The Identification control has the ASN.1 definition:</t>
<figure>
<artwork>
Identification ::= UTF8String
</artwork>
</figure>
</section>
<section title="Hardware Shared-Secret Token Generation" anchor="s_hardwareToken">
<t>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 their 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:</t>
<list style="numbers">
<t> The Identification control MUST be included and MUST contain the hardware-generated token.</t>
<t> The shared-secret value used above is the same hardware-generated token.</t>
<t> 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.</t>
<t> 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.</t>
</list>
</section>
</section>
<section title="Linking Identity and POP Information">
<t>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 <xref target="c_encryptedPOP"/> 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.</t>
<t>This section describes two mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (<xref target="c_popLinkRandom"/>) and shared-secret/subject DN matching (<xref target="c_LinkSecret"/>). 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 shared-secret; this will defeat attempts to include certification requests from different entities in a single Full PKI Request.</t>
<section title="Cryptographic Linkage">
<t>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).</t>
<section title="POP Link Witness Version 2 Controls" anchor="c_popLinkWitness2">
<t>The POP Link Witness Version 2 control is identified by the OIDs:</t>
<figure>
<artwork>
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
</artwork>
</figure>
<t>The POP Link Witness Version 2 control has the ASN.1 definition:</t>
<figure><artwork>
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
</artwork></figure>
<t>The fields of PopLinkWitnessV2 have the meaning:</t>
<list style="hanging">
<t hangText="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.</t>
<t hangText="macAlgorithm">contains the algorithm used to create the witness value.</t>
<t hangText="witness">contains the computed witness value.</t>
</list>
<t>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:</t>
<list style="numbers">
<t> The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.</t>
<t> The key is computed from the shared-secret using the algorithm in keyGenAlgorithm.</t>
<t> A MAC is then computed over the random value produced in Step 1, using the key computed in Step 2.</t>
<t> 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.</t>
<t> 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.</t>
<list style="symbols">
<t>For CRMF, the POP Link Witness/POP Link Witness V2 control is included in the controls field of the CertRequest structure.</t>
<t>For PKCS #10, the POP Link Witness/POP Link Witness V2 control is included in the attributes field of the CertificationRequestInfo structure.</t>
</list>
</list>
<t>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.</t>
<t>The Identification control (see <xref target="c_identification"/>) or the subject DN of a certification request can be used to help identify which shared-secret was used.</t>
</section>
<section title="POP Link Witness Control" anchor="c_popLinkWitness">
<t>The POP Link Witness control is identified by the OIDs:</t>
<figure>
<artwork>
id-cmc-popLinkWitness ::= { id-cmc 23 }
</artwork>
</figure>
<t>The POP Link Witness control has the ASN.1 definition:</t>
<figure>
<artwork>
PopLinkWitness ::= OCTET STRING
</artwork>
</figure>
<t>For this control, SHA-1 is used as the key generation algorithm. HMAC-SHA1 is used as the mac algorithm.</t>
</section>
<section title="POP Link Random Control" anchor="c_popLinkRandom">
<t>The POP Link Random control is identified by the OIDs:</t>
<t>The POP Link Random and POP Link Witness controls are identified by the OIDs:</t>
<figure>
<artwork>
id-cmc-popLinkRandom ::= { id-cmc 22 }
</artwork>
</figure>
<t>The POP Link Random control has the ASN.1 definition:</t>
<figure>
<artwork>
PopLinkRandom ::= OCTET STRING
</artwork>
</figure>
</section>
</section>
<section title="Shared-secret/subject DN linking" anchor="c_LinkSecret">
<t>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.)</t>
<t>When the shared-secret is generated and transferred out-of-band to initiate the registration process (<xref target="s_IdProof"/>), 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:</t>
<list style="numbers">
<t> 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.</t>
<t> The client MUST include an Identity Proof control or Identity Proof Version 2(<xref target="c_identityProof"/>), derived from the shared-secret, in the Full PKI Request.</t>
</list>
<t>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.</t>
</section>
<section title="Renewal and Re-Key Messages">
<t>When doing a renewal or re-key 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 the each certification request will now cover that information. The outmost signature layer is created using the current signing certificate, which allows 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.</t>
</section>
</section>
<section title="Data Return Control" anchor="c_dataReturn">
<t>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.</t>
<t>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.</t>
<t>The Data Return control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-dataReturn ::= { id-cmc 4 }
</artwork>
</figure>
<t>The Data Return control has the ASN.1 definition:</t>
<figure>
<artwork>
DataReturn ::= OCTET STRING
</artwork>
</figure>
<t>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.</t>
</section>
<section title="RA Certificate Modification Controls">
<t>These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons include: addition of certificate extensions or modification of subject and/or subject alternative names.</t>
<t>Two controls exist for this purpose. The first control, Modify Certificate Request (<xref target="c_modCertTemplate"/>), allows the RA to replace or remove of any field in the certificate. The second control, Add Extensions (<xref target="c_addExtensions"/>), only allows for the addition of extensions.</t>
<section title="Modify Certificate Request Control" anchor="c_modCertTemplate">
<t>The Modify Certificate Request control is used by RAs to change fields in a requested certificate.</t>
<t>The Modify Certificate Request control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-modCertTemplate ::= { id-cmc 31 }
</artwork>
</figure>
<t>The Modify Certificate Request has the ASN.1 definition:</t>
<figure>
<artwork>
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
</artwork>
</figure>
<t>The fields in ModCertTemplate have the following meaning:</t>
<list style="hanging">
<t hangText="pkiDataReference"> is the path to the PKI Request containing certification request(s) to be modified.</t>
<t hangText="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.</t>
<t hangText="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.
</t>
<t hangText="certTemplate"> is a certificate template object <xref target="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.</t>
</list>
<t>Servers MUST be able to process all extensions defined, but not prohibited, in <xref target="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.</t>
<t>If a certification request is the target of multiple Modify Certificate Request controls, the behavior is:</t>
<list style="symbols">
<t>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.</t>
<t>If control A and control B are in the same PKIData (i.e. the same wrapping layer), the order of application is non-determinate.</t>
</list>
<t>The same order of application is used if a certification request is the target of both a Modify Certificate Request control and an Add Extensions control.</t>
</section>
<section title="Add Extensions Control" anchor="c_addExtensions">
<t>The Add Extensions control has been deprecated in favor of the Modify Certificate Request control. It was replaced so that fields in the certification request other than extensions could be modified.</t>
<t>The Add Extensions control is used by RAs to specify additional extensions that are to be included in certificates.</t>
<t>The Add Extensions control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-addExtensions ::= { id-cmc 8 }
</artwork>
</figure>
<t>The Add Extensions control has the ASN.1 definition:</t>
<figure>
<artwork>
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
</artwork>
</figure>
<t>The fields in AddExtensions have the following meaning:</t>
<list style="hanging">
<t hangText="pkiDataReference"> contains the body part identity of the embedded certification request.</t>
<t hangText="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.</t>
<t hangText="extensions"> is a sequence of extensions to be applied to the referenced certification requests.</t>
</list>
<t>Servers MUST be able to process all extensions defined, but not prohibited, in <xref target="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.</t>
<t>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).</t>
<list style="numbers">
<t> If the conflict is within a single PKIData, the certification request would be rejected with a CMCFailInfo value of badRequest.</t>
<t> If the conflict is between different PKIData, the outermost version of the extension would be used (allowing an RA to override the requested extension).</t>
</list>
</section>
</section>
<section title="Transaction Identifier, Sender and Recipient Nonce Controls" anchor="c_transactionId">
<t>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.</t>
<t>The Transaction Identifier control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-transactionId ::= { id-cmc 5 }
</artwork>
</figure>
<t>The Transaction Identifier control has the ASN.1 definition:</t>
<figure>
<artwork>
TransactionId ::= INTEGER
</artwork>
</figure>
<t>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 request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.</t>
<t>Replay protection is supported through the use of the Sender and Recipient Nonces 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.</t>
<t anchor="c_senderNonce">The Sender Nonce and Recipient controls are identified by the OIDs:</t>
<figure>
<artwork>
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
</artwork>
</figure>
<t>The Sender Nonce control has the ASN.1 definition:</t>
<figure>
<artwork>
SenderNonce ::= OCTET STRING
</artwork>
</figure>
<t anchor="c_recipientNonce">The Recipient Nonce control has the ASN.1 definition:</t>
<figure>
<artwork>
RecepientNonce ::= OCTET STRING
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Encrypted and Decrypted POP Controls" anchor="c_encryptedPOP">
<t>Servers MAY require 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.</t>
<t>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 <xref target="CRMF"/> for a detailed discussion of POP.</t>
<t>By necessity, POP for encryption-only keys cannot be done in one round-trip, since there are four distinct steps:</t>
<list style="numbers">
<t> Client tells the server about the public component of a new encryption key pair.</t>
<t> Server sends the client a POP challenge, encrypted with the presented public encryption key.</t>
<t> Client decrypts the POP challenge using the private key that corresponds to the presented public key and sends the plaintext back to the server.</t>
<t> Server validates the decrypted POP challenge and continues processing the certification request.</t>
</list>
<t>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.</t>
<t>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.)</t>
<t>The Encrypted POP control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-encryptedPOP ::= { id-cmc 9 }
</artwork>
</figure>
<t>The Encrypted POP control has the ASN.1 definition:</t>
<figure>
<artwork>
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
</artwork>
</figure>
<t anchor="c_decryptedPOP">The Decrypted POP control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-decryptedPOP ::= { id-cmc 10 }
</artwork>
</figure>
<t>The Decrypted POP control has the ASN.1 definition:</t>
<figure>
<artwork>
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
</artwork>
</figure>
<t>The encrypted POP algorithm works as follows:</t>
<list style="numbers">
<t> The server generates a random value y and associates it with the request.</t>
<t> The server returns the Encrypted POP control with the following fields set:</t>
<list style="hanging">
<t hangText="request"> is the original certification request (it is included here so the client need not key a copy of the request),</t>
<t hangText="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 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,</t>
<t hangText="thePOPAlgID"> identifies the algorithm to be used in computing the return POP value,</t>
<t hangText="witnessAlgID"> identifies the hash algorithm used on y to create the field witness,</t>
<t hangText="witness"> is the hashed value of POP proof value.</t>
</list>
<t> The client decrypts the cms field to obtain 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.</t>
<t> The client creates the a Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:</t>
<list style="hanging">
<t anchor="i_bpid" hangText="bodyPartID"> refers to the certification request in the new PKI Request,</t>
<t hangText="thePOPAlgID"> is copied from the encryptedPOP,</t>
<t hangText="thePOP"> contains the possession proof.
This value is computed by thePOPAlgID using the value y and the request.</t>
</list>
<t> The server then re-computes the value of thePOP from its cached value of y 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.</t>
</list>
<t>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 value of y is used as the secret value in the HMAC algorithm and the request is used as the data. If y is greater than 64 bytes, only the first 64 bytes of y are used as the secret.</t>
<t>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.</t>
<list style="numbers">
<t> 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.)</t>
<t> 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.</t>
</list>
</section>
<section title="RA POP Witness Control " anchor="c_lraPOPWitness">
<t>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 it has done the POP. The RA POP Witness control addresses this issue.</t>
<t>The RA POP Witness control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-lraPOPWitness ::= { id-cmc 11 }
</artwork>
</figure>
<t>The RA POP Witness control has the ASN.1 definition:</t>
<figure>
<artwork>
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
</artwork>
</figure>
<t>The fields in LraPOPWitness have the following meaning:</t>
<list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
</list>
<t>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.</t>
</section>
<section title="Get Certificate Control" anchor="c_getCert">
<t>Everything described in this section is optional to implement.</t>
<t>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.</t>
<t>The Get Certificate control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-getCert ::= { id-cmc 15 }
</artwork>
</figure>
<t>The Get Certificate control has the ASN.1 definition:</t>
<figure>
<artwork>
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
</artwork>
</figure>
<t>The fields in GetCert have the following meaning:</t>
<list style="hanging">
<t hangText="issuerName">is the name of the certificate issuer.</t>
<t hangText="serialNumber">identifies the certificate to be retrieved.</t>
</list>
<t>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.</t>
</section>
<section title="Get CRL Control" anchor="c_getCRL">
<t>Everything described in this section is optional to implement.</t>
<t>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.</t>
<t>The Get CRL control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-getCRL ::= { id-cmc 16 }
</artwork>
</figure>
<t>The Get CRL control has the ASN.1 definition:</t>
<figure>
<artwork>
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
</artwork>
</figure>
<t>The fields in a GetCRL have the following meanings:</t>
<list style="hanging">
<t hangText="issuerName"> is the name of the CRL issuer.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
<t>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.</t>
</section>
<section title="Revocation Request Control " anchor="c_revokeRequest">
<t>The Revocation Request control is used to request that a certificate be revoked.</t>
<t>The Revocation Request control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-revokeRequest ::= { id-cmc 17 }
</artwork>
</figure>
<t>The Revocation Request control has the ASN.1 definition:</t>
<figure>
<artwork>
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
</artwork>
</figure>
<t>The fields of RevokeRequest have the following meaning:</t>
<list style="hanging">
<t hangText="issuerName"> is the issuerName of the certificate to be revoked.</t>
<t hangText="serialNumber"> is the serial number of the certificate to be revoked.</t>
<t hangText="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.</t>
<t hangText="invalidityDate"> is the suggested value for the Invalidity Date CRL Extension. The CA can use this value at its discretion in building the CRL.</t>
<t hangText="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.</t>
<t hangText="comment"> is a human readable comment.</t>
</list>
<t>
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.</t>
<t>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.</t>
<t>
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.</t>
<t>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.</t>
<t>A Full PKI Response MUST be returned for a revocation request.</t>
</section>
<section title="Registration and Response Information Controls" anchor="c_regInfo" >
<t>The Registration Information control allows for clients to pass additional information as part a Full PKI Request.</t>
<t>The Registration Information control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-regInfo ::= { id-cmc 18 }
</artwork>
</figure>
<t>The Registration Information control has the ASN.1 definition:</t>
<figure>
<artwork>
RegInfo ::= OCTET STRING
</artwork>
</figure>
<t>The content of this data is based on bilateral agreement between the client and server.</t>
<t>The Response Information control allows a server to return additional information as part of a Full PKI Response.</t>
<t>The Response Information control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-responseInfo ::= { id-cmc 19 }
</artwork>
</figure>
<t anchor="c_responseInfo">The Response Information control has the ASN.1 definition:</t>
<figure>
<artwork>
ResponseInfo ::= OCTET STRING
</artwork>
</figure>
<t>The content of this data is based on bilateral agreement between the client and the server.</t>
</section>
<section title="Query Pending Control " anchor="c_queryPending">
<t>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.</t>
<t>The Query Pending control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-queryPending ::= { id-cmc 21 }
</artwork>
</figure>
<t>The Query Pending control has the ASN.1 definition:</t>
<figure>
<artwork>
QueryPending ::= OCTET STRING
</artwork>
</figure>
<t>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.</t>
</section>
<section title="Confirm Certificate Acceptance Control" anchor="c_confirmCertAcceptance">
<t>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.</t>
<t>Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.</t>
<t>The Confirm Certificate Acceptance control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
</artwork>
</figure>
<t>The Confirm Control Acceptance control has the ASN.1 definition:</t>
<figure>
<artwork>
CMCCertId ::= IssuerAndSerialNumber
</artwork>
</figure>
<t>CMCCertId contains the issuer and serial number of the certificate being accepted.</t>
<t>Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.</t>
<t>Note that if the CA includes this control, there will be two full round trips of messages.</t>
<list style="numbers">
<t> The client sends the certification request to the CA. </t>
<t> The CA returns a Full PKI Response with the certificate and this control.</t>
<t> 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.</t>
<t> The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.</t>
</list>
</section>
<section title="Publish Trust Anchors Control" anchor="c_trustAnchors">
<t>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 <xref target="PKIXCERT"/>.</t>
<t>The Publish Trust Anchors control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-trustedAnchors ::= { id-cmc 26 }
</artwork>
</figure>
<t>The Publish Trust Anchors control has the ASN.1 definition:</t>
<figure>
<artwork>
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
</artwork>
</figure>
<t>The fields in PublishTrustAnchors have the following meaning:</t>
<list style="hanging">
<t hangText="seqNumber"> is an integer indicating the location within a sequence of updates.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>
<t>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.</t>
<t>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 the sequence number is greater than the previously used one.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Authenticated Data Control" anchor="c_authData">
<t>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 the Publish Trust Anchors control <xref target="c_trustAnchors"/>, but may be used in other cases as well.</t>
<t>The Authenticated Data control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-authData ::= { id-cmc 27 }
</artwork>
</figure>
<t>The Authenticated Data control has the ASN.1 definition:</t>
<figure>
<artwork>
AuthPublish ::= BodyPartID
</artwork>
</figure>
<t>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, there will then be controls in the controlSequence that would need to be processed (one example being the Publish Trust Anchors control <xref target="c_trustAnchors"/>).</t>
<t>If the authentication operation fails, the CMCFailInfo authDataFail is returned.</t>
</section>
<section title="Batch Request and Response Controls" anchor="c_batchRequests">
<t>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.</t>
<t>The Batch Request control is identified by the OID:</t>
<figure><artwork>
id-cmc-batchRequests ::= {id-cmc 28}
</artwork></figure>
<t anchor="c_batchResponses">The Batch Response control is identified by the OID:</t>
<figure><artwork>
id-cmc-batchResponses ::= {id-cmc 29}
</artwork></figure>
<t>Both the Batch Request and Batch Response controls have the ASN.1 definition:</t>
<figure><artwork>
BodyPartList ::= SEQUENCE of BodyPartID
</artwork></figure>
<t>The data associated with these controls is a set of body part identifiers. The collection of requests/responses are individually placed in the cmsSequence of the PKIData/PKIResponse. The body part identifiers of these elements are then placed in the body part list.</t>
<t>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 are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.</t>
</section>
<section title="Publication Information Control" anchor="c_publishCert">
<t>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 re-key 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.</t>
<t>The Publication Information control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-publishCert ::= { id-cmc 30 }
</artwork>
</figure>
<t>The Publication Information control has the ASN.1 definition:</t>
<figure>
<artwork>
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 }
}
</artwork>
</figure>
<t>The fields in CMCPublicationInfo have the following meaning:</t>
<list style="hanging">
<t hangText="hashAlg"> is the algorithm identifier of the hash algorithm used to compute the values in certHashes.</t>
<t hangText="certHashes"> are the hashes of the certificates for which publication is to change.</t>
<t hangText="pubInfo"> is the information where and how the certificates should be published. The fields in pubInfo (taken from <xref target="CRMF"/>) have the following meanings:</t>
<list style="hanging">
<t hangText="action"> indicates the action the service should take. It has two values:</t>
<list style="hanging">
<t hangText="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.</t>
<t hangText="pleasePublish"> indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the the CMC Publication Info control results in the same behavior.</t>
</list>
<t hangText="pubInfos">pubInfos indicates how (e.g., X500, Web, IP Address) the PKI SHOULD publish the certificate.</t>
</list>
</list>
<t>A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.</t>
</section>
<section title="Control Processed Control" anchor="c_controlProcessed">
<t>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.</t>
<t>The Control Processed control is identified by the OID:</t>
<figure>
<artwork>
id-cmc-controlProcessed ::= { id-cmc 32 }
</artwork>
</figure>
<t>The Control Processed control has the ASN.1 definition:</t>
<figure>
<artwork>
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
</artwork>
</figure>
<list style="hanging">
<t hangText="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 which are not part of this standard and thus would cause an error condition of a server attempting to deal with a control which is 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.
</t>
</list>
</section>
</section>
<section title="Registration Authorities" anchor="s_RA_Processing">
<t>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:</t>
<list style="symbols">
<t> Batching multiple PKI Requests together, </t>
<t> Performing challenge/response POP proofs,</t>
<t> Adding private or standardized certificate extensions to all certification requests,</t>
<t> Archiving private key material,</t>
<t> Routing requests to different CAs.</t>
</list>
<t>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.</t>
<t>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, then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls.</t>
<t>If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request.</t>
<t>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.</t>
<t>An example of how this would look is illustrated by the following figure:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>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.</t>
<section title="Encryption Removal">
<t>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.</t>
<t>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.</t>
</section>
<section title="Signature Layer Removal">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="Security Considerations">
<t>Initiation of a secure communications channel between an end-entity and a CA or RA (and, similarly, between an RA and another RA or CA) necessarily requires an out-of-band trust initiation mechanism. For example, a secure channel may be constructed between the end-entity and the CA via IPsec <xref target="IPsec"/> or TLS <xref target="TLS"/>. Many such schemes exist and the choice of any particular scheme for trust initiation is outside the scope of this document. Implementers of this protocol are strongly encouraged to consider generally accepted principles of secure key management when integrating this capability within an overall security architecture.</t>
<t>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 <xref target="c_transactionId"/>. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="X942"/>. Methods of avoiding the small subgroup attack can be found in <xref target="SMALL-GROUP"/>. CMC implementations ought to be aware of this attack when doing parameter validations.</t>
<t>When using a shared-secret for authentication purposes, the shared-secret should be generated using good random number techniques <xref target="RANDOM"/>. User selection of the secret allows for dictionary attacks to be mounted.</t>
<t>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.</t>
<t>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 that the trust anchor is valid for. (I.e., is the trust anchor used for validating S/MIME messages, TLS or CMC enrollment messages.)</t>
<t>When a new message is received with a Publish Trust Anchor 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.</t>
</section>
<section title="IANA Considerations">
<t>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.</t>
</section>
<section title="Acknowledgments">
<t>The authors and the PKIX Working Group are grateful for the participation of Xiaoui Lui and Jeff Weinstein in helping to author the original versions of this document. </t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="CMS">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley"/>
<date month="July" year="2004"/>
</front>
<seriesInfo name="RFC" value="3852"/>
</reference>
<reference anchor="CRMF">
<front>
<title>Internet X.509 Certification Request Message Format</title>
<author initials="J." surname="Schaad"/>
<date year="2005" month="January"/>
</front>
<seriesInfo name="RFC" value="4211"/>
</reference>
<reference anchor="DH-POP">
<front>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title>
<author initials="H." surname="Prafullchandra"/>
<author initials="J." surname="Schaad"/>
<date month="June" year="2000"/>
</front>
<seriesInfo name="RFC" value="2875"/>
</reference>
<reference anchor="HMAC">
<front>
<title>Diffie-Hellman Proof-of-Possession Algorithms</title>
<author initials="H." surname="Krawczyk"/>
<author initials="M." surname="Bellare"/>
<author initials="R." surname="Canetti"/>
<date month="February" year="1997"/>
</front>
<seriesInfo name="RFC" value="2104"/>
</reference>
<reference anchor="PKCS10">
<front>
<title>PKCS #10: Certification Request Syntax v1.5</title>
<author initials="B." surname="Kaliski"/>
<date year="1997" month="October"/>
</front>
<seriesInfo name="RFC" value="2314"/>
</reference>
<reference anchor="PKIXCERT">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials="R." surname="Housley"/>
<author initials="W." surname="Ford"/>
<author initials="W." surname="Polk"/>
<author initials="D." surname="Solo"/>
<date year="2002" month="April"/>
</front>
<seriesInfo name="RFC" value="3280"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
</reference>
</references>
<references title="Informational References">
<reference anchor="CMC-TRANS">
<front>
<title>CMC Transport</title>
<author initials="J." surname="Schaad"/>
<author initials="M." surname="Myers" fullname="Michael Myers"/>
<date month="December" year="2004"/>
</front>
<seriesInfo name="draft-ietf-pkix-cmc-trans-00.txt" value=""/>
</reference>
<reference anchor="CMC-MUST">
<front>
<title>CMC Compliance</title>
<author initials="J." surname="Schaad"/>
<author initials="M." surname="Myers" fullname="Michael Myers"/>
<date month="December" year="2004"/>
</front>
<seriesInfo name="draft-ietf-pkix-cmc-must-00.txt" value=""/>
</reference>
<reference anchor="DH">
<front>
<title> PKCS 3: Diffie-Hellman Key Agreement v1.4</title>
<author initials="B." surname="Kaliski"/>
<date year="1900" month="Lost"/>
</front>
</reference>
<reference anchor="IPsec">
<front><title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent"/>
<author initials="K." surname="Seo"/>
<date year="2005" month="December"/>
</front><seriesInfo name="RFC" value="4301"/>
</reference>
<reference anchor="PASSWORD">
<front><title>Electronic Authentication Guideline</title>
<author initials="W." surname="Burr"/>
<author initials="D." surname="Dodson"/>
<author initials="W." surname="Polk"/>
<date year="2006" month="April"/>
</front>
<seriesInfo name="NIST" value="SP 800-63"/>
</reference>
<reference anchor="PKCS1">
<front>
<title>PKCS #1: RSA Encryption, Version 1.5</title>
<author initials="B." surname="Kaliski"/>
<date year="1998" month="March"/>
</front>
<seriesInfo name="PKCS" value="#1"/>
</reference>
<reference anchor="PKCS7">
<front>
<title>PKCS #7: Cryptographic Message Syntax v1.5</title>
<author initials="B." surname="Kaliski"/>
<date year="1997" month="October"/>
</front>
<seriesInfo name="RFC" value="2315"/>
</reference>
<reference anchor="PKCS8">
<front>
<title>PKCS#8: Private-Key Information Syntax Standard, Version 1.2</title>
<author initials="RSA" surname="Laboratories"/>
<date year="1993" month="November"/>
</front>
</reference>
<reference anchor="RANDOM">
<front><title>"Randomness Requirements for Security</title>
<author initials="D." surname="Eastlake, 3rd"/>
<author initials="J." surname="Schiller"/>
<author initials="S." surname="Crocker"/>
<date year="2005" month="June"/>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
</reference>
<reference anchor="SMALL-GROUP">
<front>
<title>Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME</title>
<author initials="R." surname="Zuccherato"/>
<date month="March" year="2000"/>
</front>
<seriesInfo name="RFC" value="2785"/>
</reference>
<reference anchor="SMIMEV2">
<front>
<title>S/MIME Version 2 Message Specification</title>
<author initials="S." surname="Dusse"/>
<author initials="P." surname="Hoffman"/>
<author initials="B." surname="Ramsdell"/>
<author initials="L." surname="Lundblade"/>
<author initials="L." surname="Repka"/>
<date year="1998" month="March"/>
</front>
<seriesInfo name="RFC" value="2311"/>
</reference>
<reference anchor="SMIMEV3">
<front>
<title>S/MIME Version 3 Message Specification</title>
<author initials="B." surname="Ramsdell"/>
<date year="2004" month="July"/>
</front>
<seriesInfo name="RFC" value="3851"/>
</reference>
<reference anchor="TLS">
<front><title>The Transport Layer Security (TLS) Protocol Version 1.1</title>
<author initials="T." surname="Dierks"/>
<author initials="E." surname="Rescorla"/>
<date year="2006" month="April"/>
</front>
<seriesInfo name="RFC" value="4346"/>
</reference>
<reference anchor="X942">
<front>
<title>Diffie-Hellman Key Agreement Method</title>
<author initials="E." surname="Rescorla"/>
<date year="1999" month="June"/>
</front>
<seriesInfo name="RFC" value="2631"/>
</reference>
<reference anchor="RFC2797">
<front>
<title>Certificate Management Messages over CMS</title>
<author initials="M." surname="Myers"/>
<author initials="X." surname="Liu"/>
<author initials="J." surname="Schaad"/>
<author initials="J." surname="Weinstein"/>
<date year="2000" month="April"/>
</front>
<seriesInfo name="RFC" value="2797"/>
</reference>
</references>
<appendix title="ASN.1 Module">
<figure>
<artwork>
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.
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)
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 }
-- 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)
}
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsuportedExt (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}
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
-- Unauthenticated attribute to carry removable data.
-- This will be used in the key archive draft among others.
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
-- 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
}
-- 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
</artwork>
</figure>
</appendix>
<appendix title="Enrollment Message Flows">
<t>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.</t>
<appendix title="Request of a Signing Certificate">
<t>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.</t>
<t>Message from client to server:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Response from server to client:</t>
<figure>
<artwork>
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
</artwork>
</figure>
</appendix>
<appendix title="Single Certification Request, But Modified by RA">
<t>This section looks at the messages that would flow in the event that an enrollment is has one RA in the middle of the data flow. That RA will modify the certification request before passing it on the CA.</t>
<t>Message from client to RA:</t>
<figure>
<artwork>
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
</artwork>
</figure>
<t>Message from RA to CA:</t>
<figure>
<artwork>
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}}}
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
</artwork>
</figure>
<t>Response from the CA to the RA:</t>
<figure>
<artwork>
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-BatchResponse, {999, 998}}
{102, 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
</artwork>
</figure>
<t>Response from RA to client:</t>
<figure>
<artwork>
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
</artwork>
</figure>
</appendix>
<appendix title="Indirect POP for an RSA certificate">
<t>This section looks at the messages that would flow in the event that an enrollment is done for an encryption only certificate using an indirect POP method. For simplicity it is assumed that the certification requestor already has a signing only certificate</t>
<t>The fact that a second round trip is required is implicit rather than explicit. The server determines this based on fact that no other POP exists for the certification request.</t>
<t>Message #1 from client to server:</t>
<figure>
<artwork>
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, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requestor's signing cert
</artwork>
</figure>
<t>Response #1 from server to client:</t>
<figure>
<artwork>
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 = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipipentInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
</artwork>
</figure>
<figure>
<artwork>
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, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requestor's signing cert
</artwork>
</figure>
<t>Response from server to client:</t>
<figure>
<artwork>
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}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
</artwork>
</figure>
</appendix>
</appendix>
<appendix title="Production of Diffie-Hellman Public Key Certification Requests">
<t>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. <xref target="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.</t>
<appendix title=" No-Signature Signature Mechanism">
<t>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:</t>
<figure>
<artwork>
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
</artwork>
</figure>
<t>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 <xref target="c_encryptedPOP"/> MUST be used.</t>
</appendix>
</appendix>
<appendix title="Change History">
<t>RFC Editor - please remove this appendix prior to publishing.</t>
<t>RFC 27XX to -00</t>
<list style="numbers">
<t> Addition of Extended CMC Status Info</t>
</list>
<t>From -00 to -01</t>
<list style="numbers">
<t> Removal of Transport section to a new document.</t>
<t> Removal of Compliance section to a new document.</t>
</list>
<t>From -01 to -02</t>
<list style="numbers">
<t> Add processing rules for PKIData and PKIResponse processing.</t>
<t> Add unsigned attribute for holding data (to be used by key archival).</t>
<t> Add trust root identification control.</t>
<t> Add Server to Client identity proof method.</t>
<t> Add controls to identify batch processing, needed by rules added in item 1.</t>
</list>
<t>From -02 to -03</t>
<list style="numbers">
<t> Add unpublish control</t>
<t> Added use of AuthenticatedData structure from CMS</t>
<t> Insert Appendix B - Enrollment Message Flows</t>
<t> Add Modify Certification Request control</t>
</list>
<t>From -03 to -04</t>
<list style="numbers">
<t>Change author list.</t>
<t>Add IANA Considerations section</t>
<t>Correct module names in ASN.1</t>
<t>Add id-cmc-controlProcessed control with associated changes.</t>
</list>
<t>From -04 to -05</t>
<list style="numbers">
<t>Change Trust Root to Trust Anchor.</t>
</list>
</appendix>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:44:31 |