RFC 10002: Certificate Management over CMS (CMC)

1.1. Protocol Requirements

As much as possible, the protocol must be based on the existing CMS [CMS] [CMS-AE], PKCS #10 [PKCS10], and CRMF (Certificate Request Message Format) [CRMF] specifications.¶

The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS #7 "certs-only" response as a subset of the protocol.¶

The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.¶

The protocol must supply a way of doing all enrollment operations in a single round trip. When this is not possible, the number of round trips is to be minimized.¶

The protocol must be designed such that all key generation can occur on the client.¶

Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents.¶

The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.¶

The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate.¶

1.2. Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.3. Changes Since RFC 2797

[CMC-PROTv1] was a major overhaul on the layout of [RFC2797]. This included two different steps. Primarily, the removal of some sections from the document to be moved to two other documents:¶

• Information on how to transport messages is now found in [CMC-TRANS].¶
• Information on which controls and sections of this document must be implemented along with which algorithms are required can now be found in [CMC-COMPL].¶

A number of new controls were added in [CMC-PROTv1]:¶

• "Extended CMC Status Info Control" (Section 6.1.1)¶
• "Publish Trust Anchors Control (Section 6.15)¶
• "Authenticated Data Control (Section 6.16)¶
• "Batch Request and Response Controls (Section 6.17)¶
• "Publication Information Control (Section 6.18)¶
• "Modify Certification Request Control (Section 6.5.1)¶
• "Control Processed Control (Section 6.19)¶
• "Identity Proof Control (Section 6.2.2)¶
• "POP Link Witness Version 2 Controls (Section 6.3.1.1)¶

1.4. Updates Made by RFC 6402

[CMC-Updates] includes changes to [CMC-PROTv1] that are noted in this section.¶

Two added controls:¶

• Registration Authority (RA) Identity Witness allows for an RA to perform identity checking using the identity and shared-secret, and tell any following servers that the identity check was successfully performed.¶
• Response Body allows for an RA to identify a nested response for an End-Entity (EE) to process.¶

[CMC-Updates] also:¶

• Creates the Change Subject Name attribute, which allows a client to request a change in the subject field and Subject Alternative Name extension in a certificate.¶
• Adds Extended Key Usages (EKUs) for CMC to distinguish server types.¶
• Defines a new Subject Information Access extension to hold locations to contact the CMC server.¶
• Clarifies that the use of a preexisting certificate is not limited to just renewal and rekey messages and is required for support. This formalizes a requirement for the ability to do renewal and rekey that previously was implicit.¶

1.5. Changes Since RFC 6402

This document introduces changes to [CMC-PROTv1] that are noted in this section.¶

• Merged [CMC-Updates] text.¶
• Included updates inspired by the following errata reports: [Err8385], [Err8137], [Err8027], [Err7629], [Err7628], [Err7627], [Err7379], [Err6571], [Err5931], [Err4775], [Err2731], [Err2063], and [Err3943] (for [CMC-Updates]).¶
• To support adopting SHA-256 and HMAC-SHA256, maca-hMAC-SHA256 was added to POPAlgs and mda-sha256 was added to WitnessAlgs. Both were included in the example in Appendix B.¶
• Updated the "Encrypted and Decrypted POP Controls" section (Section 6.7) to use HMAC-SHA256.¶
• Updated the ASN.1 module to import from the 2008 ASN.1 module from [ADD-ASN1].¶
• Modified the ASN.1 module in Appendix A.1 to import Password-Based Key Derivation Function 2 (PBKDF2) Pseudorandom Functions (PRFs) from Appendix A.2.¶
• Added a direct POP example to address management of Key Encapsulation Mechanism (KEM) certificates.¶
• Added id-ce-subjectKeyIdentifier to examples.¶
• Clarified that the subjectKeyIdentifier choice must be used with id-alg-noSignature.¶
• Updated the CMC Control Attribute Table (see Table 1) to include raIdentityWitness and responseBody from [CMC-Updates].¶
• Added support for AuthEnvelopedData.¶

2.1. Terminology

There are several different terms, abbreviations, and acronyms used in this document. These are defined here, in no particular order, for convenience and consistency of usage:¶

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 EE. The different types of POP are:¶

• Signature provides the required POP by a signature operation over some data.¶

• Direct provides the required POP operation by an encrypted challenge-response mechanism.¶

• Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.)¶

• Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.)¶

• Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods.¶

2.2. Protocol Requests/Responses

Figure 1 shows the Simple PKI Requests and Responses. The contents of the Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.¶

Figure 2 shows the Full PKI Requests and Responses. The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.¶

3.1. Simple PKI Request

A Simple PKI Request uses the PKCS #10 syntax CertificationRequest [PKCS10].¶

When a server processes a Simple PKI Request, the PKI Response returned is:¶

• Simple PKI Response on success.¶

• Full PKI Response on failure. The server MAY choose not to return a PKI Response in this case.¶

The Simple PKI Request MUST NOT be used if a Proof-of-Identity needs to be included.¶

The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature.¶

The Simple PKI Request cannot be used for any of the advanced services specified in this document.¶

The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:¶

 ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension

where Extension is imported from [PKIXCERT] [ADD-ASN1] and ExtensionReq is identified by:¶

 id-ExtensionReq OBJECT IDENTIFIER ::= { iso(1) member-body(2)
 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14 }

Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, changing key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt.¶

3.2. Full PKI Request

The Full PKI Request provides the most functionality and flexibility.¶

The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).¶

When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:¶

• Simple PKI Response if the enrollment was successful and only certificates are returned. (An Extended CMC Status Info V2 control with success is implied.)¶

• Full PKI Response if the enrollment was successful and information is returned in addition to certificates, if the enrollment is pending, or if the enrollment failed.¶

If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (i.e., included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:¶

1. The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.¶

2. The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.¶

3. The value of the subjectKeyIdentifier form of SignerInfo MUST be the Subject Key Identifier specified in the corresponding certification request. (The subjectKeyIdentifier form of SignerInfo is used here because no certificates have yet been issued for the signing key.) If the request key is used for signing, there MUST be only one SignerInfo in the SignedData.¶

If AuthenticatedData is used, then:¶

1. The Password Recipient Info option of RecipientInfo MUST be used.¶

2. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.¶

3. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF-8) and the shared-secret.¶

When creating a PKI Request to renew or rekey a certificate:¶

1. 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 they could have a common operator.¶

2. 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.¶

3. 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.¶

 id-cct-PKIData OBJECT IDENTIFIER ::= { id-pkix id-cct(12) 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
 }

 TaggedAttribute ::= SEQUENCE {
 bodyPartID BodyPartID,
 attrType CMC-CONTROL.&id({Cmc-Control-Set}),
 attrValues SET OF CMC-CONTROL.
 &Type({Cmc-Control-Set}{@attrType})
 }

 TaggedRequest ::= CHOICE {
 tcr [0] TaggedCertificationRequest,
 crm [1] CertReqMsg,
 orm [2] SEQUENCE {
 bodyPartID BodyPartID,
 requestMessageType OTHER-REQUEST.&id({OtherRequests}),
 requestMessageValue OTHER-REQUEST.&Type({OtherRequests}
 {@.requestMessageType})
 }
 }

 TaggedCertificationRequest ::= SEQUENCE {
 bodyPartID BodyPartID,
 certificationRequest CertificationRequest
 }

 CertReqMsg ::= SEQUENCE {
 certReq CertRequest,
 popo ProofOfPossession OPTIONAL,
 -- content depends upon key type
 regInfo SEQUENCE SIZE (1..MAX) OF
 SingleAttribute{{RegInfoSet}} 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{SIGNATURE-ALGORITHM,
 {SignatureAlgorithms}} 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{{CertExtensions}} OPTIONAL }

 TaggedContentInfo ::= SEQUENCE {
 bodyPartID BodyPartID,
 contentInfo ContentInfo
 }

 OtherMsg ::= SEQUENCE {
 bodyPartID BodyPartID,
 otherMsgType OTHER-MSG.&id({OtherMsgSet}),
 otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }

 bodyIdMax INTEGER ::= 4294967295

 BodyPartID ::= INTEGER(0..bodyIdMax)

 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= { id-aa 34 }

 CMCUnsignedData ::= SEQUENCE {
 bodyPartPath BodyPartPath,
 identifier TYPE-IDENTIFIER.&id,
 content TYPE-IDENTIFIER.&Type
 }

4.1. Simple PKI Response

Clients MUST be able to process the Simple PKI Response. The Simple PKI Response consists of a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response are returned in the certificate field of the SignedData.¶

Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete certification paths to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the crls field. Servers MAY include the self-signed certificates. Clients MUST NOT implicitly trust an included self-signed certificate(s) merely due to its presence in the certificates field. 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.¶

4.2. Full PKI Response

Clients MUST be able to process a Full PKI Response.¶

The Full PKI Response consists of a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response are returned in the certificates field of the immediately encapsulating SignedData.¶

Clients MUST NOT assume the certificates are in any order. Servers SHOULD include all intermediate certificates needed to form complete chains to one or more trust anchors, not just the newly issued certificate(s). The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust an included self-signed certificate(s) merely due to its presence in the certificates field. 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.¶

 id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-pkix id-cct(12) 3 }

 PKIResponse ::= SEQUENCE {
 controlSequence SEQUENCE SIZE (0..MAX) OF TaggedAttribute,
 cmsSequence SEQUENCE SIZE (0..MAX) OF TaggedContentInfo,
 otherMsgSequence SEQUENCE SIZE (0..MAX) OF OtherMsg
 }

 ResponseBody ::= PKIResponse

6.1. CMC Status Info Controls

The CMC Status Info controls return information about the status of a client/server request/response. Two controls are described in this section. The Extended CMC Status Info control is the preferred control; the CMC Status Info control is included for backward compatibility with [RFC2797].¶

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 they MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended CMC Status Info control.¶

 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 [1] SEQUENCE {
 failInfoOID TYPE-IDENTIFIER.&id
 ({ExtendedFailures}),
 failInfoValue TYPE-IDENTIFIER.&Type
 ({ExtendedFailures}
 {@.failInfoOID})
 }
 } OPTIONAL
 }

 PendInfo ::= SEQUENCE {
 pendToken OCTET STRING,
 pendTime GeneralizedTime
 }

 BodyPartReference ::= CHOICE {
 bodyPartID BodyPartID,
 bodyPartPath BodyPartPath
 }

 id-cmc-statusInfo OBJECT IDENTIFIER ::= { id-cmc 1 }

 CMCStatusInfo ::= SEQUENCE {
 cMCStatus CMCStatus,
 bodyList BodyPartList,
 statusString UTF8String OPTIONAL,
 otherInfo CHOICE {
 failInfo CMCFailInfo,
 pendInfo PendInfo } OPTIONAL
 }

 CMCStatus ::= INTEGER {
 success (0),
 -- reserved (1),
 failed (2),
 pending (3),
 noSupport (4),
 confirmRequired (5),
 popRequired (6),
 partial (7)
 }

 CMCFailInfo ::= INTEGER {
 badAlg (0),
 badMessageCheck (1),
 badRequest (2),
 badTime (3),
 badCertId (4),
 unsupportedExt (5),
 mustArchiveKeys (6),
 badIdentity (7),
 popRequired (8),
 popFailed (9),
 noKeyReuse (10),
 internalCAError (11),
 tryLater (12),
 authDataFail (13)
 }

6.2. Identification and Identity Proof Controls

Some CAs and RAs require that a Proof-of-Identity be included in a certification request. Many different ways of doing this exist with different degrees of security and reliability. Most are familiar with a bank's request to provide your mother's maiden name as a form of Proof-of-Identity. The reasoning behind requiring a Proof-of-Identity can be found in Appendix C of [CRMF].¶

CMC provides a method to prove the client's identity based on a client/server shared-secret. If clients support the Full PKI Request, clients MUST implement this method of Proof-of-Identity (Section 6.2.1). Servers MUST provide this method, but they MAY additionally support bilateral methods of similar strength.¶

This document also provides an Identification control (Section 6.2.3). This control is a simple method to allow a client to state who they are to the server. Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier is placed in the Identification control, and the shared-secret is used to compute the Identity Proof or Identity Proof v2 control.¶

 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }

 IdentityProofV2 ::= SEQUENCE {
 proofAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
 {WitnessAlgs}},
 macAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witness OCTET STRING
 }

 id-cmc-identityProof OBJECT IDENTIFIER ::= { id-cmc 3 }

 IdentityProof ::= OCTET STRING

 id-cmc-identification OBJECT IDENTIFIER ::= { id-cmc 2 }

 Identification ::= UTF8String

6.3. Linking Identity and POP Information

In a CMC Full PKI Request, Proof-of-Identity information about the client is carried in the certificate associated with the signature of the SignedData containing the certification requests, one of the two Identity Proof controls, or the MAC computed for the AuthenticatedData containing the certification requests. POP information for key pairs, however, is carried separately for each PKCS #10 or CRMF. (For keys capable of generating a digital signature, the POP is provided by the signature on the PKCS #10 or CRMF. For encryption-only keys, the controls described in Section 6.7 are used.) In order to prevent substitution-style attacks, the protocol must guarantee that the same entity supplied both the POP and Proof-of-Identity information.¶

We describe three mechanisms for linking identity and POP information: witness values cryptographically derived from a shared-secret (Section 6.3.1), shared-secret/subject name matching (Section 6.3.2), and subject name matching to an existing certificate (Section 6.3.3). Clients and servers MUST support the witness value and the certificate-linking techniques. Clients and servers MAY support shared-secret/name matching or MAY support other bilateral techniques of similar strength. The idea behind the first two 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.¶

 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }

 PopLinkWitnessV2 ::= SEQUENCE {
 keyGenAlgorithm AlgorithmIdentifier{KEY-DERIVATION,
 {KeyDevAlgs}},
 macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witness OCTET STRING
 }

 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= { id-cmc 23 }

 PopLinkWitness ::= OCTET STRING

 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= { id-cmc 22 }

 PopLinkRandom ::= OCTET STRING

6.4. Data Return Control

The Data Return control allows clients to send arbitrary data (usually some type of internal state information) to the server and to have the data returned as part of the Full PKI Response. Data placed in a Data Return control is considered to be opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response.¶

In the event that the information in the Data Return control needs to be confidential, it is expected that the client would apply some type of encryption to the contained data, but the details of this are outside the scope of this specification.¶

The Data Return control is identified by the OID:¶

 id-cmc-dataReturn OBJECT IDENTIFIER ::= { id-cmc 4 }

The Data Return control has the ASN.1 definition:¶

 DataReturn ::= OCTET STRING

A client could use this control to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key.¶

6.5. RA Certificate Modification Controls

These controls exist for RAs to be able to modify the contents of a certification request. Modifications might be necessary for various reasons. These include addition of certificate extensions or modification of subject and/or subject alternative names.¶

Two controls exist for this purpose. The first control, Modify Certification Request (Section 6.5.1), allows the RA to replace or remove any field in the certificate. The second control, Add Extensions (Section 6.5.2), only allows for the addition of extensions.¶

 id-cmc-modCertTemplate OBJECT IDENTIFIER ::= { id-cmc 31 }

 ModCertTemplate ::= SEQUENCE {
 pkiDataReference BodyPartPath,
 certReferences BodyPartList,
 replace BOOLEAN DEFAULT TRUE,
 certTemplate CertTemplate
 }

id-cmc-addExtensions OBJECT IDENTIFIER ::= { id-cmc 8 }

 AddExtensions ::= SEQUENCE {
 pkiDataReference BodyPartID,
 certReferences SEQUENCE OF BodyPartID,
 extensions SEQUENCE OF Extension{{CertExtensions}}
 }

6.6. Transaction Identifier Control and Sender and Recipient Nonce Controls

Transactions are identified and tracked with a transaction identifier. If used, clients generate transaction identifiers and retain their value until the server responds with a Full PKI Response that completes the transaction. Servers correspondingly include received transaction identifiers in the Full PKI Response.¶

The Transaction Identifier control is identified by the OID:¶

 id-cmc-transactionId OBJECT IDENTIFIER ::= { id-cmc 5 }

The Transaction Identifier control has the ASN.1 definition:¶

 TransactionId ::= INTEGER

The Transaction Identifier control identifies a given transaction. It is used by client and server to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control.¶

Replay protection is supported through the use of the Sender and Recipient Nonce controls. If nonces are used, in the first message of a transaction, a Recipient Nonce control is not transmitted; a Sender Nonce control is included by the transaction originator and retained for later reference. The recipient of a Sender Nonce control reflects this value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. Upon receipt by the transaction originator of this response, the transaction originator compares the value of Recipient Nonce control to its retained value. If the values match, the message can be accepted for further security processing. The received value for a Sender Nonce control is also retained for inclusion in the next message associated with the same transaction.¶

The Sender Nonce and Recipient Nonce controls are identified by the OIDs:¶

 id-cmc-senderNonce OBJECT IDENTIFIER ::= { id-cmc 6 }
 id-cmc-recipientNonce OBJECT IDENTIFIER ::= { id-cmc 7 }

The Sender Nonce control has the ASN.1 definition:¶

 SenderNonce ::= OCTET STRING

The Recipient Nonce control has the ASN.1 definition:¶

 RecipientNonce ::= OCTET STRING

Clients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control and include a new value as its Sender Nonce control.¶

6.7. Encrypted and Decrypted POP Controls

Servers MAY require that this POP method be used only if another POP method is unavailable. Servers SHOULD reject all certification requests contained within a PKIData if any required POP is missing for any element within the PKIData.¶

Many servers require proof that the entity that generated the certification request actually possesses the corresponding private component of the key pair. For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair. With keys that can only be used for encryption operations, POP MUST be performed by forcing the client to decrypt a value. See Section 5 of [CRMF] for a detailed discussion of POP.¶

By necessity, POP for encryption-only keys cannot be done in one round trip, since there are four distinct steps:¶

1. Client tells the server about the public component of a new encryption key pair.¶

2. Server sends the client a POP challenge, encrypted with the presented public encryption key.¶

3. Client decrypts the POP challenge using the private key that corresponds to the presented public key and uses it for computing a keyed hash value sent back to the server.¶

4. Server validates the decrypted POP challenge and continues processing the certification request.¶

CMC defines two different controls. The first deals with the encrypted challenge sent from the server to the user in Step 2. The second deals with the value derived from the decrypted challenge sent by the client to the server in Step 3.¶

The Encrypted POP control is used to send the encrypted challenge from the server to the client as part of the PKIResponse.¶

The Encrypted POP control is identified by the OID:¶

 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= { id-cmc 9 }

The Encrypted POP control has the ASN.1 definition:¶

 EncryptedPOP ::= SEQUENCE {
 request TaggedRequest,
 cms ContentInfo,
 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witnessAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
 {WitnessAlgs}},
 witness OCTET STRING
 }

The Decrypted POP control is identified by the OID:¶

 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= { id-cmc 10 }

The Decrypted POP control has the ASN.1 definition:¶

 DecryptedPOP ::= SEQUENCE {
 bodyPartID BodyPartID,
 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 thePOP OCTET STRING
 }

The encrypted POP algorithm works as follows:¶

1. The server randomly generates the POP Proof Value and associates it with the request.¶

2. The server returns the Encrypted POP control with the following fields set:¶

   • request is the original certification request (it is included here so the client need not keep a copy of the request).¶

   • cms is an EnvelopedData or AuthEnvelopedData, 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.¶

   • thePOPAlgID identifies the algorithm to be used in computing the return POP value.¶

   • witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.¶

   • witness is the hashed value of the POP Proof Value.¶

3. The client decrypts the cms field to obtain the POP Proof Value. The client computes H(POP Proof Value) using the witnessAlgID and compares to the value of witness. If the values do not compare or the decryption is not successful, the client MUST abort the enrollment process. The client aborts the process by sending a request containing an Extended CMC Status Info or a CMC Status Info control with CMCFailInfo value of popFailed.¶

4. The client creates the Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:¶

   • bodyPartID refers to the certification request in the new PKI Request.¶

   • thePOPAlgID is copied from the encryptedPOP.¶

   • thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.¶

5. The server then re-computes the value of thePOP from its cached value and the request and compares to the value of thePOP. If the values do not match, the server MUST NOT issue the certificate. The server MAY reissue a new challenge or MAY fail the request altogether.¶

When defining the algorithms for thePOPAlgID and witnessAlgID, care must be taken to ensure that the result of witnessAlgID is not a useful value to shortcut the computation with thePOPAlgID. The POP Proof Value is used as the secret value in the HMAC algorithm and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value is used as the secret.¶

One potential problem with the algorithm above is the amount of state that a CA needs to keep in order to verify the returned POP value. The following describes one of many possible ways of addressing the problem by reducing the amount of state kept on the CA to a single (or small set) of values.¶

1. Server generates random seed x, constant across all requests. (The value of x would normally be altered on a regular basis and kept for a short time afterwards.)¶

2. For certification request R, server computes y = F(x,R). F can be, for example, HMAC-SHA256(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-SHA256.¶

6.8. RA POP Witness Control

In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request. In this case, the RA needs a way to inform the CA that it has done the POP. The RA POP Witness control addresses this issue.¶

The RA POP Witness control is identified by the OID:¶

 id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= { id-cmc 11 }

The RA POP Witness control has the ASN.1 definition:¶

 LraPopWitness ::= SEQUENCE {
 pkiDataBodyid BodyPartID,
 bodyIds SEQUENCE OF BodyPartID
 }

The fields in LraPopWitness have the following meaning:¶

• pkiDataBodyid contains the body part identifier of the nested TaggedContentInfo containing the client's Full PKI Request. pkiDataBodyid is set to 0 if the request is in the current PKIData.¶

• bodyIds is a list of certification requests for which the RA has performed an out-of-band authentication. The method of authentication could be archival of private key material, challenge-response, or other means.¶

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 reverify the POP itself.¶

6.9. Get Certificate Control

Everything described in this section is optional to implement.¶

The Get Certificate control is used to retrieve a previously issued certificate from a certificate repository. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.¶

The Get Certificate control is identified by the OID:¶

 id-cmc-getCert OBJECT IDENTIFIER ::= { id-cmc 15 }

The Get Certificate control has the ASN.1 definition:¶

 GetCert ::= SEQUENCE {
 issuerName GeneralName,
 serialNumber INTEGER }

The fields in GetCert have the following meaning:¶

• issuerName is the name of the certificate issuer.¶

• serialNumber identifies the certificate to be retrieved.¶

The server that responds to this request places the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response.¶

6.10. Get CRL Control

Everything described in this section is optional to implement.¶

The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, or an independent service may provide this repository. The clients expected to use this facility are those where a fully deployed directory is either infeasible or undesirable.¶

The Get CRL control is identified by the OID:¶

 id-cmc-getCRL OBJECT IDENTIFIER ::= { id-cmc 16 }

The Get CRL control has the ASN.1 definition:¶

 GetCRL ::= SEQUENCE {
 issuerName Name,
 cRLName GeneralName OPTIONAL,
 time GeneralizedTime OPTIONAL,
 reasons ReasonFlags OPTIONAL }

The fields in a GetCRL have the following meanings:¶

• issuerName is the name of the CRL issuer.¶

• cRLName may be the value of CRLDistributionPoints in the subject certificate or equivalent value in the event the certificate does not contain such a value.¶

• time is used by the client to specify from among potentially several issues of CRL that one whose thisUpdate value is less than but nearest to the specified time. In the absence of a time component, the CA always returns with the most recent CRL.¶

• reasons is used to specify from among CRLs partitioned by revocation reason. Implementers should bear in mind that while a specific revocation request has a single CRLReason code -- and consequently entries in the CRL would have a single CRLReason code value -- a single CRL can aggregate information for one or more reasonFlags.¶

A server responding to this request places the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response.¶

6.11. Revocation Request Control

The Revocation Request control is used to request that a certificate be revoked.¶

The Revocation Request control is identified by the OID:¶

 id-cmc-revokeRequest OBJECT IDENTIFIER ::= { id-cmc 17 }

The Revocation Request control has the ASN.1 definition:¶

 RevokeRequest ::= SEQUENCE {
 issuerName Name,
 serialNumber INTEGER,
 reason CRLReason,
 invalidityDate GeneralizedTime OPTIONAL,
 sharedSecret OCTET STRING OPTIONAL,
 comment UTF8string OPTIONAL }

The fields of RevokeRequest have the following meaning:¶

• issuerName is the name of the certificate issuer.¶

• serialNumber is the serial number of the certificate to be revoked.¶

• reason is the suggested CRLReason code for why the certificate is being revoked. The CA can use this value at its discretion in building the CRL.¶

• invalidityDate is the suggested value for the Invalidity Date CRL Extension. The CA can use this value at its discretion in building the CRL.¶

• sharedSecret is a secret value registered by the EE when the certificate was obtained to allow for revocation of a certificate in the event of key loss.¶

• comment is a human-readable comment.¶

For a revocation request to be reliable in the event of a dispute, a strong proof-of-origin is required. However, in the instance when an EE has lost use of its signature private key, it is impossible for the EE to produce a digital signature (prior to the certification of a new signature key pair). The Revoke Request control allows the EE to send the CA a shared-secret that may be used as an alternative authenticator in the instance of loss of use of the EE's signature private key. The acceptability of this practice is a matter of local security policy.¶

It is possible to sign the revocation for the lost certificate with a different certificate in some circumstances. A client can sign a revocation for an encryption key with a signing certificate if the name information matches. Similarly, an administrator or RA can be assigned the ability to revoke the certificate of a third party. Acceptance of the revocation by the server depends on local policy in these cases.¶

Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared-secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self-revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests.¶

The structure of an unsigned, shared-secret-based revocation request is a matter of local implementation. The shared-secret does not need to be encrypted when sent in a Revocation Request control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), and public knowledge of the shared-secret after the certificate has been revoked is not a problem. Clients need to inform users that the same shared-secret SHOULD NOT be used for multiple certificates.¶

A Full PKI Response MUST be returned for a revocation request.¶

6.12. Registration and Response Information Controls

The Registration Information control allows for clients to pass additional information as part of a Full PKI Request.¶

The Registration Information control is identified by the OID:¶

 id-cmc-regInfo OBJECT IDENTIFIER ::= { id-cmc 18 }

The Registration Information control has the ASN.1 definition:¶

 RegInfo ::= OCTET STRING

The content of this data is based on bilateral agreement between the client and server.¶

The Response Information control allows a server to return additional information as part of a Full PKI Response.¶

The Response Information control is identified by the OID:¶

 id-cmc-responseInfo OBJECT IDENTIFIER ::= { id-cmc 19 }

The Response Information control has the ASN.1 definition:¶

 ResponseInfo ::= OCTET STRING

The content of this data is based on bilateral agreement between the client and server.¶

6.13. Query Pending Control

In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request.¶

The Query Pending control is identified by the OID:¶

 id-cmc-queryPending OBJECT IDENTIFIER ::= { id-cmc 21 }

The Query Pending control has the ASN.1 definition:¶

 QueryPending ::= OCTET STRING

If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of pendInfo MUST be the same as the original pendInfo value.¶

6.14. Confirm Certificate Acceptance Control

Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.¶

Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose.¶

The Confirm Certificate Acceptance control is identified by the OID:¶

 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= { id-cmc 24 }

The Confirm Certificate Acceptance control has the ASN.1 definition:¶

 CMCCertId ::= IssuerAndSerialNumber

CMCCertId contains the issuer and serial number of the certificate being accepted.¶

Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.¶

Note that if the CA includes this control, there will be two full round trips of messages, as follows:¶

1. The client sends the certification request to the CA.¶

2. The CA returns a Full PKI Response with the certificate and this control.¶

3. The client sends a Full PKI Request to the CA with an Extended CMC Status Info or a CMC Status Info control accepting and a Confirm Certificate Acceptance control or an Extended CMC Status Info or a CMC Status Info control rejecting the certificate.¶

4. The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.¶

6.15. Publish Trust Anchors Control

The Publish Trust Anchors control allows for the distribution of set trust anchors from a central authority to an EE. The same control is also used to update the set of trust anchors. Trust anchors are distributed in the form of certificates. These are expected, but not required, to be self-signed certificates. Information is extracted from these certificates to set the inputs to the certificates validation algorithm in Section 6.1.1 of [PKIXCERT].¶

The Publish Trust Anchors control is identified by the OID:¶

 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= { id-cmc 26 }

The Publish Trust Anchors control has the ASN.1 definition:¶

 PublishTrustAnchors ::= SEQUENCE {
 seqNumber INTEGER,
 hashAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM,
 {HashAlgorithms}},
 anchorHashes SEQUENCE OF OCTET STRING
 }

The fields in PublishTrustAnchors have the following meaning:¶

• seqNumber is an integer indicating the location within a sequence of updates.¶

• hashAlgorithm is the identifier and parameters for the hash algorithm that is used in computing the values of the anchorHashes field. All implementations MUST implement SHA-256 for this field.¶

• anchorHashes are the hashes for the certificates that are to be treated as trust anchors by the client. The actual certificates are transported in the certificates field of the containing SignedData structure.¶

While it is recommended that the sender place the certificates that are to be trusted in the PKI Response, it is not required as the certificates should be obtainable using normal discovery techniques.¶

Prior to accepting the trust anchor's changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to ensure that the signer is permitted to use the control, validate that the authenticated publish time in the signature is near to the current time, and validate that the sequence number is greater than the previously used one.¶

In the event that multiple agents publish a set of trust anchors, it is up to local policy to determine how the different trust anchors should be combined. Clients SHOULD be able to handle the update of multiple trust anchors independently.¶

6.16. Authenticated Data Control

The Authenticated Data control allows a server to provide data back to the client in an authenticated manner. This control uses the Authenticated Data structure to allow for validation of the data. This control is used where the client has a shared-secret and a secret identifier with the server, but where a trust anchor has not yet been downloaded onto the client so that a signing certificate for the server cannot be validated. The specific case that this control was created for use with is the Publish Trust Anchors control (Section 6.15), but it may be used in other cases as well.¶

The Authenticated Data control is identified by the OID:¶

 id-cmc-authData OBJECT IDENTIFIER ::= { id-cmc 27 }

The Authenticated Data control has the ASN.1 definition:¶

 AuthPublish ::= BodyPartID

AuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData. The encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds.¶

If the authentication operation fails, the CMCFailInfo authDataFail is returned.¶

6.17. Batch Request and Response Controls

These controls allow for an RA to collect multiple requests together into a single Full PKI Request and forward it to a CA. The server would then process the requests and return the results in a Full PKI Response.¶

The Batch Request control is identified by the OID:¶

 id-cmc-batchRequests OBJECT IDENTIFIER ::= { id-cmc 28 }

The Batch Response control is identified by the OID:¶

 id-cmc-batchResponses OBJECT IDENTIFIER ::= { id-cmc 29 }

Both the Batch Request and Batch Response controls have the ASN.1 definition:¶

 BodyPartList ::= SEQUENCE OF BodyPartID

The data associated with these controls is a set of body part identifiers. Each request/response is placed as an individual entry in the cmcSequence of the new PKIData/PKIResponse. The body part identifiers of these entries are then placed in the body part list associated with the control.¶

When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. A CMCStatus value of partial is returned on all but the last PKI Response. The CMCStatus would be success if the Batch Request control was processed; the responses are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level.¶

When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.¶

6.18. Publication Information Control

The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued.¶

The Publication Information control is identified by the OID:¶

 id-cmc-publishCert OBJECT IDENTIFIER ::= { id-cmc 30 }

The Publication Information control has the ASN.1 definition:¶

 CMCPublicationInfo ::= SEQUENCE {
 hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM,
 {HashAlgorithms}},
 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 }
 }

The fields in CMCPublicationInfo have the following meaning:¶

• hashAlg is the algorithm identifier of the hash algorithm used to compute the values in certHashes.¶

• certHashes are the hashes of the certificates for which publication is to change.¶

• pubInfo is the information where and how the certificates should be published. The fields in pubInfo (taken from [CRMF][ADD-ASN1]) have the following meanings:¶

  • action indicates the action the service should take. It has two values:¶

    • dontPublish indicates that the PKI should not publish the certificate (this may indicate that the requester intends to publish the certificate themselves). dontPublish has the added connotation of removing from publication the certificate if it is already published.¶

    • pleasePublish indicates that the PKI MAY publish the certificate using whatever means it chooses unless pubInfos is present. Omission of the CMC Publication Info control results in the same behavior.¶

  • pubInfos indicates how (e.g., X.500, Web, IP Address) the PKI SHOULD publish the certificate.¶

A single certificate SHOULD NOT appear in more than one Publication Information control. The behavior is undefined in the event that it does.¶

6.19. Control Processed Control

The Control Processed control allows an RA to indicate to subsequent control processors that a specific control has already been processed. This permits an RA in the middle of a processing stream to process a control defined either in a local context or in a subsequent document.¶

The Control Processed control is identified by the OID:¶

 id-cmc-controlProcessed OBJECT IDENTIFIER ::= { id-cmc 32 }

The Control Processed control has the ASN.1 definition:¶

 ControlList ::= SEQUENCE {
 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
 }

• bodyList is a series of body part identifiers that form a path to each of the controls that were processed by the RA. This control is only needed for those controls that are not part of this standard and thus would cause an error condition of a server attempting to deal with a control not defined in this document. No error status is needed since an error causes the RA to return the request to the client with the error rather than passing the request on to the next server in the processing list.¶

6.20. RA Identity Proof Witness Control

The RA Identity Proof Witness control allows an RA to indicate to subsequent control processors that all of the Proof-of-Identity requirements have been met. This permits the Proof-of-Identity to be performed at a location closer to the EE. For example, the Proof-of-Identity could be done at multiple physical locations, while the CA could operate on a company-wide basis. The RA performs the Proof-of-Identity, and potentially other tasks that require the secret to be used, while the CA is prevented from knowing the secret. If checks related to Proof-of-Identity fail, then the RA returns an error to the client denoting that fact.¶

The RA Identity Proof Witness control is identified by the OID:¶

 id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= { id-cmc 35 }

The RA Identity Proof Witness control has the ASN.1 definition:¶

 cmc-raIdentityWitness CMC-CONTROL ::=
 { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }

• cmc-raIdentityWitness is a CMC-CONTROL associating the OID id-cmc-raIdentityWitness and the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. The control is permitted to appear only in the control sequence of a PKIData object. It MUST NOT appear in the control sequence of a PKIResponse. The control is permitted to be used only by an RA. The control may appear multiple times in a control sequence with each occurrence pointing to a different object.¶

• id-cmc-raIdentityWitness is the OID used to identify this CMC control.¶

• BodyPartPath is the type structure associated with the control. The syntax of BodyPartPath is defined in Section 3.2.2. The path contains a sequence of body part identifiers leading to one of the following items:¶

  • Identity Proof control if the RA verified the Proof-of-Identity in this control.¶

  • Identity Proof Version 2 control if the RA verified the Proof-of-Identity in this control.¶

  • Full PKI Request if the RA performed an out-of-band identity proof for this request. The request SHOULD NOT contain either Identity Proof control.¶

  • Simple PKI Request if the RA performed an out-of-band identity proof for this request.¶

The RA Identity Proof Witness control will frequently be associated with a Modify Certification Request control, which changes the name fields in the associated certification requests. This is because the RA knows the actual name to be assigned to the entity requesting the certificate, and the EE does not yet have the details of the name.¶

When this control is placed in a message, it is RECOMMENDED that the Control Processed control be placed in the body sequence as well. Using the explicit new control rather than implicitly relying on the Control Processed control is important due to the need to know explicitly which Proof-of-Identity have been performed. The new control also allows an RA to state that out-of-band Proof-of-Identity have been performed.¶

When the Proof-of-Identity is performed by an RA, the RA also MUST validate the linking between the Proof-of-Identity and the name information wrapped inside of the key proof-of-possession.¶

6.21. Response Body Control

The Response Body control is designed to enable an RA to inform an EE that there is an embedded response message that MUST be processed as part of the processing of this message. This control is designed to be used in a couple of different cases where an RA has done some additional processing for the certification request, e.g., as key generation. When an RA performs key generation on behalf of an EE, the RA MUST respond with both the original response message from the certificate issuer (containing the certificate issuance) as part of the response generated by the RA (containing the new key). Another case where this is useful is when the secret is shared between the RA and the EE (rather than between the CA and the EE) and the RA returns the Publish Trust Anchors control (to populate the correct trust points).¶

The Response Body control is identified by the OID:¶

 id-cmc-responseBody OBJECT IDENTIFIER ::= { id-cmc 37 }

The Response Body control has the ASN.1 definition:¶

 cmc-responseBody CMC-CONTROL ::=
 { BodyPartPath IDENTIFIED BY id-cmc-responseBody }

• cmc-responseBody is a CMC-CONTROL associating the OID id-cmc-responseBody with the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. The control is permitted to appear only in the control sequence of a PKIResponse. The control MUST NOT appear in the control sequence of a PKIData. It is expected that only an intermediary RA will use this control; a CA generally does not need the control as it is creating the original innermost message.¶

• id-cmc-responseBody is the OID used to identify this CMC control.¶

• BodyPartPath is the type structure associated with the control. The syntax of BodyPartPath is defined in Section 3.2.2. The path contains a sequence of body part identifiers leading to a cmsSequence item, which contains a PKIResponse within it.¶

7.1. Change Subject Name Attribute

The Client Name Change Request attribute is designed for a client to ask for a change in its name as part of a certification request. Because of security issues, this cannot be done in the simple way of just changing the requested subject's name in the certificate template. The name in the certification request MUST match the name in the certificate used to verify the request, in order for identity and possession proofs to be correctly applied.¶

The relevant ASN.1 for the Client Name Change Request attribute is as follows:¶

 at-cmc-changeSubjectName ATTRIBUTE ::= {
 TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }

 id-cmc-changeSubjectName OBJECT IDENTIFIER ::= { id-cmc 36 }

 ChangeSubjectName ::= SEQUENCE {
 subject Name OPTIONAL,
 subjectAlt [1] GeneralNames OPTIONAL
 }
 (WITH COMPONENTS {..., subject PRESENT} |
 WITH COMPONENTS {..., subjectAlt PRESENT} )

The attribute is designed to be used as an ATTRIBUTE object. As such, the attribute is placed in one of the following two places:¶

• The attributes field in a CertificationRequest.¶

• The controls field of a CertRequest for a CRMF.¶

The control is identified by the OID id-cmc-changeSubjectName.¶

The ASN.1 type associated with control is ChangeSubjectName. The fields of the structure are configured as follows:¶

• subject contains the requested subject name for the new certificate.¶

• subjectAlt contains the requested subject alternative name for the new certificate.¶

At least one of the fields in the sequence MUST be present when encoding the structure.¶

When the CA processes this attribute in a certification request, it will do the following:¶

1. If present, the subject field is copied to the name field of the template. If the subject field is absent, the name field of the template will be set to an empty sequence.¶

2. If present, the subjectAlt field is used as the content of a Subject Alternative Name extension in the certificate. If the subjectAlt field is absent, the Subject Alternative Name extension is removed from the certificate template.¶

8.1. Encryption Removal

There are two cases that require an RA to remove or change encryption in a PKI Request; both cases are true regardless of whether EnvelopedData or AuthEnvelopedData is used. 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 RecipientInfo entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer with or without adding a new signing layer.¶

The second change of encryption that may be required is to change the encryption inside of a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed and the resulting merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.¶

8.2. Signature Layer Removal

Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request.¶

If an RA removes a signing layer from a PKI Request, all control statements MUST be merged according to local policy rules. The resulting merged control statements MUST be placed in a new signing layer provided by the RA.¶

9.1. Extended Key Usage

The EKU extension is used to restrict the use of a certificate to specific applications. We define three different EKUs in this document. The ASN.1 to define these EKUs is:¶

 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
 id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }

The usage description for each of the EKUs is as follows:¶

• CMC CAs are identified by the id-kp-cmcCA EKU. The certificate may be the same as or different than the CA certificate. If a different certificate is used, the certificates containing the id-kp-cmcCA EKU SHOULD have the same name as the certificate used for issuing the certificates. (Using a separate key pair for CMC protocol operations and for issuing certificates and CRLs decreases the number of operations for which the private key used to sign certificates and CRLs would be used.)¶

• CMC Registration Authorities are identified by the id-kp-cmcRA EKU. This usage is placed into RA certificates.¶

• CMC Archive Servers are identified by the id-kp-cmcArchive EKU. CMC Archive Servers and the associated protocol are to be defined in a future document.¶

9.2. Subject Information Access

The Subject Information Access extension indicates how to access information and services for the subject of the certificate. This document defines a value for use in this extension, to identify the different locations that CMC services will be available. If this value is placed in a certificate, an appropriate EKU defined in Section 9.1 MUST be included in the certificate as well.¶

The id-ad-cmc OID is used when the subject offers certification services using the CMC protocol. If the CMC services are available via HTTP or FTP (see Section 2 of [CMC-TRANS] and Section 4 of [CMC-TRANS]), accessLocation MUST be a uniformResourceIdentifier. If the CMC services are available via electronic mail (see Section 3 of [CMC-TRANS]), accessLocation MUST be an rfc822Name. If CMC services are available using TCP/IP (see Section 5 of [CMC-TRANS]), the dNSName or iPAddress name forms MUST be used. Since the GeneralName data structure does not permit the inclusion of a port number, in the absence of other external configuration information, the value of 5318 should be used. (The port registration is in Section 7 of [CMC-TRANS].) The semantics of other name forms of accessLocation (when accessMethod is id-ad-cmc) are not defined by this specification.¶

The ASN.1 type for this extension is GeneralName (see Section 4.2.1.8 of [PKIXCERT]).¶

 id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }

12.1. Normative References

12.2. Informative References

A.1. ASN.1 Module for CMC

<CODE BEGINS>
EnrollmentMessageSyntax-2025
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-enrollMsgSyntax-2025(124) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

 EXPORTS ALL;

 IMPORTS

 AttributeSet{}, Extension{}, EXTENSION, ATTRIBUTE
 FROM PKIX-CommonTypes-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-pkixCommon-02(57) }

 AlgorithmIdentifier{}, DIGEST-ALGORITHM, KEY-WRAP, KEY-DERIVATION,
 MAC-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
 FROM AlgorithmInformation-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-algorithmInformation-02(58) }

 CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags,
 CertExtensions, GeneralNames
 FROM PKIX1Implicit-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-pkix1-implicit-02(59) }

 Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad,
 id-kp
 FROM PKIX1Explicit-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-pkix1-explicit-02(51) }

 ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE
 FROM CryptographicMessageSyntax-2010
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

 CertReqMsg, PKIPublicationInfo, CertTemplate
 FROM PKIXCRMF-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-crmf2005-02(55) }

 mda-sha1
 FROM PKIXAlgs-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-pkix1-algorithms2008-02(56) }

 maca-hMAC-SHA1
 FROM CryptographicMessageSyntaxAlgorithms-2009
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }

 mda-sha256
 FROM PKIX1-PSS-OAEP-Algorithms-2009
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-pkix1-rsa-pkalgs-02(54) }

 maca-hMAC-SHA256
 FROM HMAC-2010
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) }

 kda-PBKDF2
 FROM PBKDF2-PRFs-2025
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 pkcs-9(9) smime(16) modules(0)
 id-mod-pbkdf2-prfs-2025(125) } ;

 -- CMS content types defined in this document

 CMC-ContentTypes CONTENT-TYPE ::= {
 ct-PKIData | ct-PKIResponse, ... }

 -- Signature Algorithms defined in this document

 SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-noSignature }

 -- CMS Unsigned Attributes

 CMC-UnsignedAtts ATTRIBUTE ::= { aa-cmc-unsignedData }

 id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 } -- CMC controls
 id-cct OBJECT IDENTIFIER ::= { id-pkix 12 } -- CMC content types

 -- This is the content type for a request message in the protocol

 ct-PKIData CONTENT-TYPE ::=
 { TYPE PKIData IDENTIFIED BY id-cct-PKIData }

 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
 }

 BodyPartID ::= INTEGER(0..4294967295)

 TaggedAttribute ::= SEQUENCE {
 bodyPartID BodyPartID,
 attrType CMC-CONTROL.&id({Cmc-Control-Set}),
 attrValues SET OF CMC-CONTROL.
 &Type({Cmc-Control-Set}{@attrType})
 }

 Cmc-Control-Set CMC-CONTROL ::= {
 cmc-identityProof | cmc-dataReturn | cmc-regInfo |
 cmc-responseInfo | cmc-queryPending | cmc-popLinkRandom |
 cmc-popLinkWitness | cmc-identification | cmc-transactionId |
 cmc-senderNonce | cmc-recipientNonce | cmc-statusInfo |
 cmc-addExtensions | cmc-encryptedPOP | cmc-decryptedPOP |
 cmc-lraPOPWitness | cmc-getCert | cmc-getCRL |
 cmc-revokeRequest | cmc-confirmCertAcceptance |
 cmc-statusInfoV2 | cmc-trustedAnchors | cmc-authData |
 cmc-batchRequests | cmc-batchResponses | cmc-publishCert |
 cmc-modCertTemplate | cmc-controlProcessed |
 cmc-identityProofV2 | cmc-popLinkWitnessV2 |
 cmc-raIdentityWitness | cmc-responseBody, ... }

 OTHER-REQUEST ::= TYPE-IDENTIFIER

 -- We do not define any other requests in this document.
 -- Examples might be attribute certification requests.

 OtherRequests OTHER-REQUEST ::= {...}

 TaggedRequest ::= CHOICE {
 tcr [0] TaggedCertificationRequest,
 crm [1] CertReqMsg,
 orm [2] SEQUENCE {
 bodyPartID BodyPartID,
 requestMessageType OTHER-REQUEST.&id({OtherRequests}),
 requestMessageValue OTHER-REQUEST.&Type({OtherRequests}
 {@.requestMessageType})
 }
 }

 TaggedCertificationRequest ::= SEQUENCE {
 bodyPartID BodyPartID,
 certificationRequest CertificationRequest
 }

 AttributeList ATTRIBUTE ::= {
 at-extension-req | at-cmc-changeSubjectName, ... }

 CertificationRequest ::= SEQUENCE {
 certificationRequestInfo SEQUENCE {
 version INTEGER,
 subject Name,
 subjectPublicKeyInfo SEQUENCE {
 algorithm AlgorithmIdentifier{PUBLIC-KEY,
 {PublicKeyAlgorithms}},
 subjectPublicKey BIT STRING
 },
 attributes [0] IMPLICIT SET OF
 AttributeSet{{AttributeList}}
 },
 signatureAlgorithm AlgorithmIdentifier
 {SIGNATURE-ALGORITHM,
 {SignatureAlgorithms}},
 signature BIT STRING
 }

 TaggedContentInfo ::= SEQUENCE {
 bodyPartID BodyPartID,
 contentInfo ContentInfo
 }

 OTHER-MSG ::= TYPE-IDENTIFIER

 -- No other messages currently defined

 OtherMsgSet OTHER-MSG ::= {...}

 OtherMsg ::= SEQUENCE {
 bodyPartID BodyPartID,
 otherMsgType OTHER-MSG.&id({OtherMsgSet}),
 otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }

 -- This defines the response message in the protocol

 ct-PKIResponse CONTENT-TYPE ::=
 { TYPE PKIResponse IDENTIFIED BY id-cct-PKIResponse }

 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
 }

 CMC-CONTROL ::= TYPE-IDENTIFIER

 -- The following controls have the type OCTET STRING

 cmc-identityProof CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-identityProof }

 id-cmc-identityProof OBJECT IDENTIFIER ::= { id-cmc 3 }

 cmc-dataReturn CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-dataReturn }

 id-cmc-dataReturn OBJECT IDENTIFIER ::= { id-cmc 4 }

 cmc-regInfo CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-regInfo }

 id-cmc-regInfo OBJECT IDENTIFIER ::= { id-cmc 18 }

 cmc-responseInfo CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-responseInfo }

 id-cmc-responseInfo OBJECT IDENTIFIER ::= { id-cmc 19 }

 cmc-queryPending CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-queryPending }

 id-cmc-queryPending OBJECT IDENTIFIER ::= { id-cmc 21 }

 cmc-popLinkRandom CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-popLinkRandom }

 id-cmc-popLinkRandom OBJECT IDENTIFIER ::= { id-cmc 22 }

 cmc-popLinkWitness CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-popLinkWitness }

 id-cmc-popLinkWitness OBJECT IDENTIFIER ::= { id-cmc 23 }

 -- The following controls have the type UTF8String

 cmc-identification CMC-CONTROL ::=
 { UTF8String IDENTIFIED BY id-cmc-identification }

 id-cmc-identification OBJECT IDENTIFIER ::= { id-cmc 2 }

 -- The following controls have the type INTEGER

 cmc-transactionId CMC-CONTROL ::=
 { INTEGER IDENTIFIED BY id-cmc-transactionId }

 id-cmc-transactionId OBJECT IDENTIFIER ::= { id-cmc 5 }

 -- The following controls have the type OCTET STRING

 cmc-senderNonce CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-senderNonce }

 id-cmc-senderNonce OBJECT IDENTIFIER ::= { id-cmc 6 }

 cmc-recipientNonce CMC-CONTROL ::=
 { OCTET STRING IDENTIFIED BY id-cmc-recipientNonce }

 id-cmc-recipientNonce OBJECT IDENTIFIER ::= { id-cmc 7 }

 -- Used to return status in a response

 cmc-statusInfo CMC-CONTROL ::=
 { CMCStatusInfo IDENTIFIED BY id-cmc-statusInfo }

 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

 cmc-addExtensions CMC-CONTROL ::=
 { AddExtensions IDENTIFIED BY id-cmc-addExtensions }

 id-cmc-addExtensions OBJECT IDENTIFIER ::= { id-cmc 8 }

 AddExtensions ::= SEQUENCE {
 pkiDataReference BodyPartID,
 certReferences SEQUENCE OF BodyPartID,
 extensions SEQUENCE OF Extension{{CertExtensions}}
 }

 cmc-encryptedPOP CMC-CONTROL ::=
 { EncryptedPOP IDENTIFIED BY id-cmc-encryptedPOP }

 cmc-decryptedPOP CMC-CONTROL ::=
 { DecryptedPOP IDENTIFIED BY id-cmc-decryptedPOP }

 id-cmc-encryptedPOP OBJECT IDENTIFIER ::= { id-cmc 9 }

 id-cmc-decryptedPOP OBJECT IDENTIFIER ::= { id-cmc 10 }

 EncryptedPOP ::= SEQUENCE {
 request TaggedRequest,
 cms ContentInfo,
 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witnessAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
 {WitnessAlgs}},
 witness OCTET STRING
 }

 POPAlgs MAC-ALGORITHM ::= {
 maca-hMAC-SHA1 | maca-hMAC-SHA256, ... }

 WitnessAlgs DIGEST-ALGORITHM ::= { mda-sha1 | mda-sha256, ... }

 DecryptedPOP ::= SEQUENCE {
 bodyPartID BodyPartID,
 thePOPAlgID AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 thePOP OCTET STRING
 }

 cmc-lraPOPWitness CMC-CONTROL ::=
 { LraPopWitness IDENTIFIED BY id-cmc-lraPOPWitness }

 id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= { id-cmc 11 }

 LraPopWitness ::= SEQUENCE {
 pkiDataBodyid BodyPartID,
 bodyIds SEQUENCE OF BodyPartID
 }

 cmc-getCert CMC-CONTROL ::=
 { GetCert IDENTIFIED BY id-cmc-getCert }

 id-cmc-getCert OBJECT IDENTIFIER ::= { id-cmc 15 }

 GetCert ::= SEQUENCE {
 issuerName GeneralName,
 serialNumber INTEGER }

 cmc-getCRL CMC-CONTROL ::=
 { GetCRL IDENTIFIED BY id-cmc-getCRL }

 id-cmc-getCRL OBJECT IDENTIFIER ::= { id-cmc 16 }

 GetCRL ::= SEQUENCE {
 issuerName Name,
 cRLName GeneralName OPTIONAL,
 time GeneralizedTime OPTIONAL,
 reasons ReasonFlags OPTIONAL }

 cmc-revokeRequest CMC-CONTROL ::=
 { RevokeRequest IDENTIFIED BY id-cmc-revokeRequest }

 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 }

 cmc-confirmCertAcceptance CMC-CONTROL ::=
 { CMCCertId IDENTIFIED BY id-cmc-confirmCertAcceptance }

 id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= { id-cmc 24 }

 CMCCertId ::= IssuerAndSerialNumber

 -- The following is used to request V3 extensions be added
 -- to a certificate

 at-extension-req ATTRIBUTE ::= {
 TYPE ExtensionReq IDENTIFIED BY id-ExtensionReq }

 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{{CertExtensions}}

 -- The following allows Diffie-Hellman Certification Request
 -- Messages to be well-formed

 sa-noSignature SIGNATURE-ALGORITHM ::= {
 IDENTIFIER id-alg-noSignature
 VALUE NoSignatureValue
 PARAMS TYPE NULL ARE required
 HASHES { mda-sha1 }
 }

 id-alg-noSignature OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 2 }

 NoSignatureValue ::= OCTET STRING

 -- Unauthenticated attribute to carry removable data.

 id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) }

 aa-cmc-unsignedData ATTRIBUTE ::= {
 TYPE CMCUnsignedData IDENTIFIED BY id-aa-cmc-unsignedData }

 id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= { id-aa 34 }

 CMCUnsignedData ::= SEQUENCE {
 bodyPartPath BodyPartPath,
 identifier TYPE-IDENTIFIER.&id,
 content TYPE-IDENTIFIER.&Type
 }

 -- Replaces CMC Status Info
 --

 cmc-statusInfoV2 CMC-CONTROL ::=
 { CMCStatusInfoV2 IDENTIFIED BY id-cmc-statusInfoV2 }

 id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= { id-cmc 25 }

 EXTENDED-FAILURE-INFO ::= TYPE-IDENTIFIER

 ExtendedFailures EXTENDED-FAILURE-INFO ::= {...}

 CMCStatusInfoV2 ::= SEQUENCE {
 cMCStatus CMCStatus,
 bodyList SEQUENCE SIZE (1..MAX) OF
 BodyPartReference,
 statusString UTF8String OPTIONAL,
 otherInfo CHOICE {
 failInfo CMCFailInfo,
 pendInfo PendInfo,
 extendedFailInfo [1] SEQUENCE {
 failInfoOID TYPE-IDENTIFIER.&id
 ({ExtendedFailures}),
 failInfoValue TYPE-IDENTIFIER.&Type
 ({ExtendedFailures}
 {@.failInfoOID})
 }
 } OPTIONAL
 }

 BodyPartReference ::= CHOICE {
 bodyPartID BodyPartID,
 bodyPartPath BodyPartPath
 }

 BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

 -- Allow for distribution of trust anchors

 cmc-trustedAnchors CMC-CONTROL ::=
 { PublishTrustAnchors IDENTIFIED BY id-cmc-trustedAnchors }

 id-cmc-trustedAnchors OBJECT IDENTIFIER ::= { id-cmc 26 }

 PublishTrustAnchors ::= SEQUENCE {
 seqNumber INTEGER,
 hashAlgorithm AlgorithmIdentifier{DIGEST-ALGORITHM,
 {HashAlgorithms}},
 anchorHashes SEQUENCE OF OCTET STRING
 }

 HashAlgorithms DIGEST-ALGORITHM ::= {
 mda-sha1 | mda-sha256, ...
 }

 cmc-authData CMC-CONTROL ::=
 { AuthPublish IDENTIFIED BY id-cmc-authData }

 id-cmc-authData OBJECT IDENTIFIER ::= { id-cmc 27 }

 AuthPublish ::= BodyPartID

 -- These two items use BodyPartList

 cmc-batchRequests CMC-CONTROL ::=
 { BodyPartList IDENTIFIED BY id-cmc-batchRequests }

 id-cmc-batchRequests OBJECT IDENTIFIER ::= { id-cmc 28 }

 cmc-batchResponses CMC-CONTROL ::=
 { BodyPartList IDENTIFIED BY id-cmc-batchResponses }

 id-cmc-batchResponses OBJECT IDENTIFIER ::= { id-cmc 29 }

 BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

 cmc-publishCert CMC-CONTROL ::=
 { CMCPublicationInfo IDENTIFIED BY id-cmc-publishCert }

 id-cmc-publishCert OBJECT IDENTIFIER ::= { id-cmc 30 }

 CMCPublicationInfo ::= SEQUENCE {
 hashAlg AlgorithmIdentifier{DIGEST-ALGORITHM,
 {HashAlgorithms}},
 certHashes SEQUENCE OF OCTET STRING,
 pubInfo PKIPublicationInfo
 }

 cmc-modCertTemplate CMC-CONTROL ::=
 { ModCertTemplate IDENTIFIED BY id-cmc-modCertTemplate }

 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

 cmc-controlProcessed CMC-CONTROL ::=
 { ControlsProcessed IDENTIFIED BY id-cmc-controlProcessed }

 id-cmc-controlProcessed OBJECT IDENTIFIER ::= { id-cmc 32 }

 ControlsProcessed ::= SEQUENCE {
 bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
 }

 -- Identity Proof control w/ algorithm agility

 cmc-identityProofV2 CMC-CONTROL ::=
 { IdentityProofV2 IDENTIFIED BY id-cmc-identityProofV2 }

 id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }

 IdentityProofV2 ::= SEQUENCE {
 proofAlgID AlgorithmIdentifier{DIGEST-ALGORITHM,
 {WitnessAlgs}},
 macAlgId AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witness OCTET STRING
 }

 cmc-popLinkWitnessV2 CMC-CONTROL ::=
 { PopLinkWitnessV2 IDENTIFIED BY id-cmc-popLinkWitnessV2 }

 id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }

 PopLinkWitnessV2 ::= SEQUENCE {
 keyGenAlgorithm AlgorithmIdentifier{KEY-DERIVATION,
 {KeyDevAlgs}},
 macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
 witness OCTET STRING
 }

 KeyDevAlgs KEY-DERIVATION ::= { kda-PBKDF2, ... }

 cmc-raIdentityWitness CMC-CONTROL ::=
 { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }

 id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}

 --
 -- Allow for an End-Entity to request a change in name.
 -- This item is added to RegControlSet in CRMF.
 --
 at-cmc-changeSubjectName ATTRIBUTE ::= {
 TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }

 id-cmc-changeSubjectName OBJECT IDENTIFIER ::= { id-cmc 36 }

 ChangeSubjectName ::= SEQUENCE {
 subject Name OPTIONAL,
 subjectAlt [1] GeneralNames OPTIONAL
 }
 (WITH COMPONENTS {..., subject PRESENT} |
 WITH COMPONENTS {..., subjectAlt PRESENT} )

 --
 -- Embedded response from a third party for processing
 --

 cmc-responseBody CMC-CONTROL ::=
 { BodyPartPath IDENTIFIED BY id-cmc-responseBody }

 id-cmc-responseBody OBJECT IDENTIFIER ::= { id-cmc 37 }

 --
 -- Key purpose identifiers are in the Extended Key Usage extension
 --

 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
 id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }

 --
 -- Subject Information Access identifier
 --

 id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }

END
<CODE ENDS>

A.2. ASN.1 Module for PBKDF2 PRFs

<CODE BEGINS>
PBKDF2-PRFs-2025
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 pkcs-9(9) smime(16) modules(0) id-mod-pbkdf2-prfs-2025(125) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

 IMPORTS

 ALGORITHM, AlgorithmIdentifier{}, KEY-DERIVATION
 FROM AlgorithmInformation-2009 -- From [PKIX-ALGS]
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) id-mod(0)
 id-mod-algorithmInformation-02(58) }

 hMAC-SHA1, alg-hMAC-SHA1, id-PBKDF2
 FROM CryptographicMessageSyntaxAlgorithms-2009 -- From [CMS-ALGS]
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
 pkcs-9(9) smime(16) modules(0) id-mod-cmsalg-2001-02(37) }

 id-hmacWithSHA224, id-hmacWithSHA256,
 id-hmacWithSHA384, id-hmacWithSHA512
 FROM HMAC-2010 -- From [HMAC-ALGS]
 { iso(1) identified-organization(3) dod(6) internet(1)
 security(5) mechanisms(5) pkix(7) mod(0) id-mod-hmac(74) } ;

 -- Base OID for algorithms --

 rsadsi OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
 rsadsi(113549) }

 digestAlgorithm OBJECT IDENTIFIER ::= { rsadsi 2 }

 id-hmacWithSHA512-224 OBJECT IDENTIFIER ::= { digestAlgorithm 12 }

 id-hmacWithSHA512-256 OBJECT IDENTIFIER ::= { digestAlgorithm 13 }

 -- PBKDF2-PRFs --

 PBKDF2-PRFs ALGORITHM ::= {
 alg-hMAC-SHA1 |
 alg-hMAC-SHA224 | alg-hMAC-SHA256 |
 alg-hMAC-SHA384 | alg-hMAC-SHA512 |
 alg-hMAC-SHA512-224 | alg-hMAC-SHA512-256, ... }

 PBKDF2-PRFsAlgorithmIdentifier ::=
 AlgorithmIdentifier{ ALGORITHM, {PBKDF2-PRFs} }

 alg-hMAC-SHA224 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA224 PARAMS TYPE NULL ARE preferredAbsent }

 alg-hMAC-SHA256 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA256 PARAMS TYPE NULL ARE preferredAbsent }

 alg-hMAC-SHA384 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA384 PARAMS TYPE NULL ARE preferredAbsent }

 alg-hMAC-SHA512 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA512 PARAMS TYPE NULL ARE preferredAbsent }

 alg-hMAC-SHA512-224 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA512-224 PARAMS TYPE NULL ARE preferredAbsent }

 alg-hMAC-SHA512-256 ALGORITHM ::= { IDENTIFIER
 id-hmacWithSHA512-256 PARAMS TYPE NULL ARE preferredAbsent }

 -- PBKDF2-SaltSources --

 PBKDF2-SaltSources ALGORITHM ::= { ... }

 PBKDF2-SaltSourcesAlgorithmIdentifier ::=
 AlgorithmIdentifier {ALGORITHM, {PBKDF2-SaltSources} }

 -- PBKDF2-params --

 PBKDF2-params ::= SEQUENCE {
 salt CHOICE {
 specified OCTET STRING,
 otherSource PBKDF2-SaltSourcesAlgorithmIdentifier },
 iterationCount INTEGER (1..MAX),
 keyLength INTEGER (1..MAX) OPTIONAL,
 prf PBKDF2-PRFsAlgorithmIdentifier DEFAULT defaultPBKDF2 }

 defaultPBKDF2 PBKDF2-PRFsAlgorithmIdentifier ::=
 { algorithm alg-hMAC-SHA1.&id, parameters NULL:NULL }

 -- Key Derivation Algorithms --

 KeyDerivationAlgs KEY-DERIVATION ::= { kda-PBKDF2, ... }

 kda-PBKDF2 KEY-DERIVATION ::= {
 IDENTIFIER id-PBKDF2
 PARAMS TYPE PBKDF2-params ARE required
 -- No S/MIME caps defined
 }

END
<CODE ENDS>

B.1. Request of a Signing Certificate

This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request.¶

Message from client to server:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIData
 eContent
 controlSequence
 {102, id-cmc-identityProof, computed value}
 {103, id-cmc-senderNonce, 10001}
 reqSequence
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = My Proposed DN
 publicKey = My Public Key
 extensions
 {id-ce-subjectKeyIdentifier, 1000}
 {id-ce-keyUsage, digitalSignature}
 SignedData.SignerInfos
 SignerInfo
 sid.subjectKeyIdentifier = 1000

Response from server to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIResponse
 eContent
 controlSequence
 {102, id-cmc-statusInfoV2, {success, 201}}
 {103, id-cmc-senderNonce, 10005}
 {104, id-cmc-recipientNonce, 10001}
 certificates
 Newly issued certificate
 Other certificates
 SignedData.SignerInfos
 Signed by CA

B.2. Single Certification Request Modified by RA

This section looks at the messages that would flow in the event that an enrollment has one RA in the middle of the data flow. That RA will modify the certification request before passing it on to the CA.¶

Message from client to RA:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIData
 eContent
 controlSequence
 {102, id-cmc-identityProof, computed value}
 {103, id-cmc-senderNonce, 10001}
 reqSequence
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = My Proposed DN
 publicKey = My Public Key
 extensions
 {id-ce-subjectKeyIdentifier, 1000}
 {id-ce-keyUsage, digitalSignature}
 SignedData.SignerInfos
 SignerInfo
 sid.subjectKeyIdentifier = 1000

Message from RA to CA:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIData
 eContent
 controlSequence
 { 102, id-cmc-batchRequests, { 1, 2} }
 { 103, id-cmc-addExtensions,
 { {1, 201, {id-ce-certificatePolicies, anyPolicy}}
 {1, 201, {id-ce-subjectAltName, {extension data}}
 {2, XXX, {id-ce-subjectAltName, {extension data}}}
 The Value XXX is not known here; it would
 reference into the second client request,
 which is not displayed above.
 cmsSequence
 { 1, <Message from client to RA #1> }
 { 2, <Message from client to RA #2> }
 SignedData.SignerInfos
 SignerInfo
 sid = RA key.

Response from CA to RA:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIResponse
 eContent
 controlSequence
 {102, id-cmc-batchResponses, {999, 998}}

 {103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
 cmsSequence
 { bodyPartID = 999
 contentInfo
 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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-cct-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

Response from RA to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIResponse
 eContent
 controlSequence
 {102, id-cmc-statusInfoV2, {success, 201}}
 certificates
 Newly issued certificate
 Other certificates
 SignedData.SignerInfos
 Signed by CA

B.3. Direct POP for an RSA or KEM Certificate

This section looks at the messages that would flow in the event that an enrollment is done for an encryption-only certificate using a direct POP method; an example message follows. For simplicity, it is assumed that the certification requester already has a signature certificate. This example uses EnvelopedData; however, either EnvelopedData or AuthEnvelopedData can be used.¶

Message #1 from client to server:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = <My DN>
 publicKey = My Public Key
 extensions
 {id-ce-keyUsage, keyEncipherment}
 {id-ce-subjectPublicKeyIdentifier, 1000}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 SignedData.SignerInfos
 SignerInfo
 Signed by requester's signing cert

Response #1 from server to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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 {
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = <My DN>
 publicKey = My Public Key
 extensions
 {id-ce-keyUsage, keyEncipherment}
 {id-ce-subjectPublicKeyIdentifier, 1000}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 }
 cms
 contentType = id-envelopedData
 content
 recipientInfos.rid.issuerSerialNumber =
 <NULL-DN, 201>
 encryptedContentInfo
 eContentType = id-data
 eContent = <Encrypted value of 'y' from
 Section 6.7>
 thePOPAlgID = HMAC-SHA256
 witnessAlgID = SHA-256
 witness <hashed value of 'y' from Section 6.7>}}
 {106, id-cmc-dataReturn, <packet of binary data
 identifying where the key
 in question is.>}
 certificates
 Other certificates
 (optional - related to this message's SignedData)
 SignedData.SignerInfos
 Signed by CA

Message #2 from client to server:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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-SHA256,
 thePOP <HMAC computed value goes here>}}
 reqSequence
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = <My DN>
 publicKey = My Public Key
 extensions
 {id-ce-keyUsage, keyEncipherment}
 {id-ce-subjectKeyIdentifier, 1000}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 SignedData.SignerInfos
 SignerInfo
 Signed by requester's signing cert

Response #2 from server to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIResponse
 eContent
 controlSequence
 {101, id-cmc-transactionId, 10132985123483401}
 {102, id-cmc-statusInfoV2, {success, 201}}
 {103, id-cmc-senderNonce, 10019}
 {104, id-cmc-recipientNonce, 100101}
 {105, id-cmc-dataReturn, <packet of binary data
 identifying where the key
 in question is.>}
 certificates
 Newly issued certificate
 Other certificates
 (optional - related to this message's SignedData)
 SignedData.SignerInfos
 Signed by CA

B.4. Direct POP with No Signature Mechanism

This section looks at the messages that would flow in the event that an enrollment is done for an encryption-only certificate using a direct POP method. Instead of assuming that the certification requester already has a signing-only certificate (as in Appendix B.3), here the No Signature mechanism is from Appendix C.1, the public key is for a KEM, and the EnvelopedData uses the KEMRecipientInfo from [CMS-KEM]. This example uses EnvelopedData; however, either EnvelopedData or AuthEnvelopedData can be used.¶

Message #1 from client to server:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = < My DN >
 publicKey = My Public Key
 extensions
 {id-ce-subjectPublicKeyIdentifier, 1000}
 {id-ce-keyUsage, keyEncipherment}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 SignedData.SignerInfos
 SignerInfo
 sid = < subjectKeyIdentifier >
 signatureAlgorithm = id-alg-noSignature

Response #1 from server to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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 {
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = < My DN >
 publicKey = My Public Key
 extensions
 {id-ce-keyUsage, keyEncipherment}
 {id-ce-subjectPublicKeyIdentifier, 1000}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 }
 cms
 contentType = id-envelopedData
 content < uses ori.KEMRecipientInfo >
 recipientInfos.ori.rid.issuerSerialNumber =
 <NULL-DN, 201>
 encryptedContentInfo
 eContentType = id-data
 eContent = <Encrypted value of 'y' from
 Section 6.7>
 thePOPAlgID = KmacWithSHAKE128
 witnessAlgID = SHAKE128
 witness <hashed value of 'y' from Section 6.7>}}
 {106, id-cmc-dataReturn, <packet of binary data
 identifying where the key
 in question is.>}
 certificates
 Other certificates
 (optional - related to this message's SignedData)
 SignedData.SignerInfos
 Signed by CA

Message #2 from client to server:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-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 KmacWithSHAKE128,
 thePOP <KMAC computed value goes here>}}
 reqSequence
 crm
 certReq
 certReqId = 201
 certTemplate
 subject = < My DN >
 publicKey = My Public Key
 extensions
 {id-ce-keyUsage, keyEncipherment}
 {id-ce-subjectPublicKeyIdentifier, 1000}
 popo
 keyEncipherment
 subsequentMessage = challengeResp
 SignedData.SignerInfos
 SignerInfo
 sid = < subjectKeyIdentifier >
 signatureAlgorithm = id-alg-noSignature

Response #2 from server to client:¶

 ContentInfo.contentType = id-signedData
 ContentInfo.content
 SignedData.encapContentInfo
 eContentType = id-cct-PKIResponse
 eContent
 controlSequence
 {101, id-cmc-transactionId, 10132985123483401}
 {102, id-cmc-statusInfoV2, {success, 201}}
 {103, id-cmc-senderNonce, 10019}
 {104, id-cmc-recipientNonce, 100101}
 {105, id-cmc-dataReturn, <packet of binary data
 identifying where the key
 in question is.>}
 certificates
 Newly issued certificate
 Other certificates
 SignedData.SignerInfos
 Signed by CA

C.1. No-Signature Signature Mechanism

Key management (encryption/decryption) private keys cannot always be used to produce some type of signature value as they can be in a decrypt-only device. Certification requests require that the signature field be populated. This section provides a signature algorithm specifically for that purpose. The following object identifier and signature value are used to identify this signature type:¶

 id-alg-noSignature OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 2 }

 NoSignatureValue ::= OCTET STRING

The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the SHA-1 hash of the certification request. The hash value given by NoSignatureValue SHOULD be ignored. 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 CA policy requires proof-of-possession of the private key, the POP mechanism defined in Section 6.7 MUST be used.¶

When the client generates the SignedData.SignerInfos.SignerInfo.sid field, it has two choices: issuerAndSerialNumber or subjectKeyIdentifier. The client does not yet have a certificate; therefore, it cannot fill in the issuerAndSerialNumber and MUST use the subjectKeyIdentifier choice.¶