[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 RFC 5272
Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Expires: September 11, 2008 M. Myers
TraceRoute Security, Inc.
March 10, 2008
Certificate Management Messages over CMS
draft-ietf-pkix-2797-bis-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 11, 2008.
Schaad & Myers Expires September 11, 2008 [Page 1]
Internet-Draft CMC: Structures March 2008
Abstract
This document defines the base syntax for CMC, a Certificate
Management protocol using the Cryptographic Message Syntax (CMS).
This protocol addresses two immediate needs within the Internet
Public Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products
and services based on CMS and PKCS #10 (Public Key Cryptography
Standard), and
2. The need for a PKI enrollment protocol for encryption only keys
due to algorithm or hardware design.
CMC also requires the use of the transport document and the
requirements usage document along with this document for a full
definition.
Schaad & Myers Expires September 11, 2008 [Page 2]
Internet-Draft CMC: Structures March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 5
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 6
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Protocol Request/Responses . . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 12
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. PKIData content type . . . . . . . . . . . . . . . . . 14
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 16
3.2.1.2. Certification Request Formats . . . . . . . . . . 16
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 17
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 18
3.2.1.2.3. Other Certification Request . . . . . . . . . 19
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 20
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 21
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 21
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 22
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 23
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 25
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 25
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 26
5. Application of Encryption to a PKI Request/Response . . . . . 28
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 31
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 31
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 33
6.1.3. CMCStatus values . . . . . . . . . . . . . . . . . . . 34
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 35
6.2. Identification and Identity Proof Controls . . . . . . . . 36
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 37
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 38
6.2.3. Identification Control . . . . . . . . . . . . . . . . 39
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 39
6.3. Linking Identity and POP Information . . . . . . . . . . . 40
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 40
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 40
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 42
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 42
6.3.2. Shared-secret/subject DN linking . . . . . . . . . . . 42
Schaad & Myers Expires September 11, 2008 [Page 3]
Internet-Draft CMC: Structures March 2008
6.3.3. Renewal and Re-Key Messages . . . . . . . . . . . . . 43
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 43
6.5. RA Certificate Modification Controls . . . . . . . . . . . 44
6.5.1. Modify Certificate Request Control . . . . . . . . . . 44
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 45
6.6. Transaction Identifier, Sender and Recipient Nonce
Controls . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 48
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 51
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 52
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 53
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 54
6.12. Registration and Response Information Controls . . . . . . 55
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 56
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 56
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 57
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 58
6.17. Batch Request and Response Controls . . . . . . . . . . . 59
6.18. Publication Information Control . . . . . . . . . . . . . 60
6.19. Control Processed Control . . . . . . . . . . . . . . . . 62
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 63
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 64
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 64
8. Security Considerations . . . . . . . . . . . . . . . . . . . 65
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . . 69
11.2. Informational References . . . . . . . . . . . . . . . . . 69
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 71
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 79
Appendix B.1. Request of a Signing Certificate . . . . . . . . . . 79
Appendix B.2. Single Certification Request, But Modified by RA . . 80
Appendix B.3. Direct POP for an RSA certificate . . . . . . . . . 83
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 88
Appendix C.1. No-Signature Signature Mechanism . . . . . . . . . . 88
Appendix D. Change History . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
Intellectual Property and Copyright Statements . . . . . . . . . . 92
Schaad & Myers Expires September 11, 2008 [Page 4]
Internet-Draft CMC: Structures March 2008
1. Introduction
This document defines the base syntax for CMC, a Certificate
Management protocol using the Cryptographic Message Syntax (CMS).
This protocol addresses two immediate needs within the Internet PKI
community:
1. The need for an interface to public key certification products
and services based on CMS and PKCS #10, and
2. The need for a PKI enrollment protocol for encryption only keys
due to algorithm or hardware design.
A small number of additional services are defined to supplement the
core certification request service.
1.1. Protocol Requirements
The protocol must be based as much as possible on the existing
CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message
Format) [CRMF] specifications.
The protocol must support the current industry practice of a PKCS
#10 certification request followed by a PKCS#7 "certs-only"
response as a subset of the protocol.
The protocol must easily support the multi-key enrollment
protocols required by S/MIME and other groups.
The protocol must supply a way of doing all enrollment operations
in a single-round trip. When this is not possible the number of
round trips is to be minimized.
The protocol must be designed such that all key generation can
occur on the client.
Support must exist for the mandatory algorithms used by S/MIME.
Support should exist for all other algorithms cited by the S/MIME
core documents.
The protocol must contain Proof-of-Possession (POP) methods.
Optional provisions for multiple-round trip POP will be made if
necessary.
The protocol must support deferred and pending responses to
enrollment requests for cases where external procedures are
required to issue a certificate.
Schaad & Myers Expires September 11, 2008 [Page 5]
Internet-Draft CMC: Structures March 2008
The protocol must support arbitrary chains of Registration
Authorities (RAs) as intermediaries between certification
requesters and Certification Authorities (CAs).
1.2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.3. Changes since RFC 2797
We have done a major overhaul on the layout of the document. This
included two different steps. Firstly we removed some sections from
the document and moved them to two other documents. Information on
how to transport our messages are now found in [CMC-TRANS].
Information on which controls and sections of this document must be
implemented along with which algorithms are required can now be found
in [CMC-MUST].
A number of new controls have been added in this version:
Extended CMC Status Info Section 6.1.1
Publish Trust Anchors Section 6.15
Authenticate Data Section 6.16
Batch Request and Response Processing Section 6.17
Publication Information Section 6.18
Modify Certificate Request Section 6.5.1
Control Processed Section 6.19
Identity Proof Section 6.2.2
Identity POP Link Witness V2 Section 6.3.1.1
Schaad & Myers Expires September 11, 2008 [Page 6]
Internet-Draft CMC: Structures March 2008
2. Protocol Overview
A PKI enrollment transaction in this specification is generally
composed of a single round trip of messages. In the simplest case a
PKI enrollment request, henceforth referred to as a PKI Request, is
sent from the client to the server and a PKI enrollment response,
henceforth referred to as a PKI Response, is then returned from the
server to the client. In more complicated cases, such as delayed
certificate issuance, more than one round trip is required.
This specification defines two PKI Request types and two PKI Response
types.
PKI Requests are formed using either the PKCS #10 or CRMF structure.
The two PKI Requests are:
Simple PKI Request: the bare PKCS #10 (in the event that no other
services are needed), and
Full PKI Request: one or more PKCS #10, CRMF or Other Request
Messages structures wrapped in a CMS encapsulation as part of a
PKIData.
PKI Responses are based on SignedData [CMS]. The two PKI Responses
are
Simple PKI Response: a "certs-only" SignedData (in the event no
other services are needed), or
Full PKI Response a PKIResponse content-type wrapped in a
SignedData.
No special services are provided for either renewal (i.e., a new
certificate with the same key) or re-key (i.e., a new certificate
with a new key) of client certificates. Instead renewal and re-key
requests look the same as any certification request, except that the
identity proof is supplied by existing certificates from a trusted
CA. (This is usually the same CA, but could be a different CA in the
same organization where naming is shared.)
No special services are provided to distinguish between a re-key
request and a new certification request (generally for a new
purpose). A control to unpublish a certificate would normally be
included in a re-key request, and be omitted in a new certification
request. CAs or other publishing agents are also expected to have
policies for removing certificates from publication either based on
new certificates being added or the expiration or revocation of a
certificate.
Schaad & Myers Expires September 11, 2008 [Page 7]
Internet-Draft CMC: Structures March 2008
A provision exists for RAs to participate in the protocol by taking
PKI Requests, wrapping them in a second layer of PKI Request with
additional requirements or statements from the RA and then passing
this new expanded PKI Request on to the CA.
This specification makes no assumptions about the underlying
transport mechanism. The use of CMS does not imply an email-based
transport. Several different possible transport methods are defined
in [CMC-TRANS].
Optional services available through this specification are
transaction management, replay detection (through nonces), deferred
certificate issuance, certificate revocation requests and
certificate/certificate revocation list (CRL) retrieval.
2.1. Terminology
There are several different terms, abbreviations and acronyms used in
this document. These are defined here for convenience and
consistency of usage in no particular order:
End-Entity (EE) refers to the entity that owns a key pair and for
whom a certificate is issued.
Registration Authority (RA) or Local RA (LRA) refers to an entity
that acts as an intermediary between the EE and the CA. Multiple
RAs can exist between the End-Entity and the Certification
Authority. RAs may perform additional services such as key
generation or key archival. This document uses the term RA for
both RA and LRA.
Certification Authority (CA) refers to the entity that issues
certificates.
Client refers to an entity that creates a PKI Request. In this
document both RAs and EEs can be clients.
Server refers to the entities that process PKI Requests and create
PKI Responses. In this document both CAs and RAs can be servers.
PKCS #10 refers to the Public Key Cryptography Standard #10
[PKCS10], which defines a certification request syntax.
CRMF refers to the Certificate Request Message Format RFC [CRMF].
CMC uses this certification request syntax defined in this
document as part of the protocol.
Schaad & Myers Expires September 11, 2008 [Page 8]
Internet-Draft CMC: Structures March 2008
CMS refers to the Cryptographic Message Syntax RFC [CMS]. This
document provides for basic cryptographic services including
encryption and signing with and without key management.
PKI Request/Response refers to the requests/responses described in
this document. PKI Requests include certification requests,
revocation requests, etc. PKI Responses include certs-only
messages, failure messages, etc.
Proof-Of-Identity refers to the client proving they are who they say
that they are to the server.
Enrollment or certification request refers to the process of a
client requesting a certificate. A certification request is a
subset of the PKI Requests.
Proof-Of-Possession (POP) refers to a value that can be used to
prove that the private key corresponding to a public key is in the
possession and can be used by an end-entity. This document uses
the following different types of POP:
Signature provides the required POP by a signature operation over
some data.
Direct provides the required POP operation by an encrypted
challange/response mechinism.
Indirect provides the required POP opepration by returning the
issued certificate in an encrypted state.
Publish provides the required POP operation by providing the
private key the the certificate issuer.
Attested provides the required POP operation by allowing a
trusted entity to assert that the POP has been proven by one of
the above methods.
Object IDentifier (OID) is a primitive type in Abstract Syntax
Notation One (ASN.1).
2.2. Protocol Request/Responses
Figure 1 shows the Simple PKI Requests and Responses. The contents
of Simple PKI Request and Response are detailed in Section 3.1 and
Section 4.1.
Schaad & Myers Expires September 11, 2008 [Page 9]
Internet-Draft CMC: Structures March 2008
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Requests and Responses
Figure 2 shows the Full PKI Requests and Responses. The contents of
the Full PKI Request and Responses are detailed in Section 3.2 and
Section 4.2.
Schaad & Myers Expires September 11, 2008 [Page 10]
Internet-Draft CMC: Structures March 2008
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Figure 2: Full PKI Requests and Responses
Schaad & Myers Expires September 11, 2008 [Page 11]
Internet-Draft CMC: Structures March 2008
3. PKI Requests
Two types of PKI Requests exist. This section gives the details for
both types.
3.1. Simple PKI Request
A Simple PKI Request uses the PKCS #10 syntax CertificationRequest
[PKCS10].
When a server processes a Simple PKI Request, the PKI Response
returned is:
Simple PKI Response on success.
Full PKI Response on failure. The server MAY choose not to return a
PKI Response in this case.
The Simple PKI Request MUST NOT be used if a proof-of-identity needs
to be included.
The Simple PKI Request cannot be used if the private key is not
capable of producing some type of signature (i.e. DH keys can use
the signature algorithms in [DH-POP] for production of the
signature).
The Simple PKI Request cannot be used for any of the advanced
services specified in this document.
The client MAY incorporate one or more X.509v3 extensions in any
certification request based on PKCS #10 as an ExtensionReq attribute.
The ExtensionReq attribute is defined as:
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is
identified by:
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
Servers MUST be able to process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers are not required to be able to
process other X.509v3 extensions transmitted using this protocol, nor
are they required to be able to process private extensions. Servers
are not required to put all client-requested extensions into a
certificate. Servers are permitted to modify client-requested
extensions. Servers MUST NOT alter an extension so as to invalidate
Schaad & Myers Expires September 11, 2008 [Page 12]
Internet-Draft CMC: Structures March 2008
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 process a Full PKI Request, a PKI Response MUST be
returned. The PKI Response returned is:
Simple PKI Response if the enrollment was successful and only
certificates are returned. (A CMCStatusInfoV2 control with
success is implied.)
Full PKI Response if the enrollment was successful and information
is returned in addition to certificates, if the enrollment is
pending, or if the enrollment failed.
If SignedData is used, the signature can be generated using either
the private key material of an embedded signature certification
request (i.e., included in the TaggedRequest tcr or crm fields), or a
previously certified signature key. If the private key of a
signature certification request is used, then:
a. The certification request containing the corresponding public key
MUST include a Subject Key Identifier extension.
b. The subjectKeyIdentifier form of the signerIdentifier in
SignerInfo MUST be used.
c. The value of the subjectKeyIdentifier form of SignerInfo MUST be
the Subject Key Identifier specified in the corresponding
certification request. (The subjectKeyIdentifier form of
SignerInfo is used here because no certificates have yet been
issued for the signing key.) If the request key is used for
signing, there MUST be only one SignerInfo in the SignedData.
If AuthenticatedData is used, then:
Schaad & Myers Expires September 11, 2008 [Page 13]
Internet-Draft CMC: Structures March 2008
a. The Password Recipient Info option of RecipientInfo MUST be used.
b. A randomly generated key is used to compute the MAC value on the
encapsulated content.
c. The input for the key derivation algorithm is a concatenation of
the identifier (encoded as UTF8) and the shared-secret.
When creating a PKI Request to renew or rekey a certificate:
a. The Identification and Identity Proof controls are absent. The
same information is provided by the use of an existing
certificate from a CA when signing the PKI Request. In this case
the CA that issued the original certificate and the CA the
request is made to will usually be the same, but could have a
common operator.
b. CAs and RAs can impose additional restrictions on the signing
certificate used. They may require that the most recently issued
signing certificate for a client be used.
c. Some CAs may prevent renewal operations (i.e., reuse of the same
keys). In this case the CA MUST return a PKI Response with
noKeyReuse as the CMCFailInfo failure code.
3.2.1. PKIData content type
The PKIData content type is used for the Full PKI Request. A PKIData
content type is identified by:
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
The ASN.1 structure corresponding to the PKIData content type is:
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
The fields in PKIData have the following meaning:
controlSequence is a sequence of controls. The controls defined in
this document are found in Section 6. Controls can be defined by
other parties. Details on the TaggedAttribute structure can be
found in Section 3.2.1.1.
Schaad & Myers Expires September 11, 2008 [Page 14]
Internet-Draft CMC: Structures March 2008
reqSequence is a sequence of certification requests. The
certification requests can be a CertificationRequest (PKCS #10), a
CertReqMsg (CRMF) or an externally defined PKI request. Full
details are found in Section 3.2.1.2. If an externally defined
certification request is present, but the server does not
understand the certification request (or will not process it), a
CMCStatus of noSupport MUST be returned for the certification
request item and no other certification requests are processed.
cmsSequence is a sequence of [CMS] message objects. See
Section 3.2.1.3 for more details.
otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are referred to by one or more controls. This
allows for controls to use large amounts of data without the data
being embedded in the control. See Section 3.2.1.4 for more
details.
All certification requests encoded into a single PKIData SHOULD be
for the same identity. RAs that batch process (see Section 6.17) are
expected to place the PKI Requests received into the cmsSequence of a
PKIData.
Processing of the PKIData by a recipient is as follows:
1. All controls should be examined and processed in an appropriate
manner. The appropriate processing is to complete processing at
this time, to ignore the control or to place the control on a
to-do list for later processing. Controls can be processed in
any order; the order in the sequence is not significant.
2. Items in the reqSequence are not referenced by a control. These
items, which are certification requests, also need to be
processed. As with controls, the appropriate processing can be
either immediate processing or addition to a to-do list for later
processing.
3. Finally the to-do list is processed. In many cases the to-do
list will be ordered by grouping specific tasks together.
No processing is required for cmsSequence or otherMsgSequence members
of PKIData if they are present and are not referenced by a control.
In this case, the cmsSequence and otherMsgSequence members are
ignored.
Schaad & Myers Expires September 11, 2008 [Page 15]
Internet-Draft CMC: Structures March 2008
3.2.1.1. Control Syntax
The actions to be performed for a PKI Request/Response are based on
the included controls. Each control consists of an object identifier
and a value based on the object identifier.
The syntax of a control is:
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
The fields in TaggedAttribute have the following meaning:
bodyPartID is a unique integer that identifies this control.
attrType is the OID that identifies the control.
attrValues is the data values used in processing the control. The
structure of the data is dependent on the specific control.
The final server MUST fail the processing of an entire PKIData if any
included control is not recognized, that control is not already
marked as processed by a Control Processed control (see Section 6.19)
and no other error is generated. The PKI Response MUST include a
CMCFailInfo value with the value badRequest and the bodyList MUST
contain the bodyPartID of the invalid or unrecognized control(s). A
server is the final server if and only if it is not passing the PKI
Request on to another server. A server is not considered to be the
final server if the server would have passed the PKI Request on, but
instead it returned a processing error.
The controls defined by this document are found in Section 6.
3.2.1.2. Certification Request Formats
Certification Requests are based on PKCS #10, CRMF or Other Request
formats. Section 3.2.1.2.1 specifies the requirements for clients
and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the
requirements for clients and servers dealing with CRMF.
Section 3.2.1.2.3 specifies the requirements for clients and servers
dealing with Other Request.
Schaad & Myers Expires September 11, 2008 [Page 16]
Internet-Draft CMC: Structures March 2008
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
The fields in TaggedRequest have the following meaning:
tcr is a certification request that uses the PKCS #10 syntax.
Details on PKCS #10 are found in Section 3.2.1.2.1.
crm is a certification request that uses the CRMF syntax. Details
on CRMF are found in Section 3.2.1.2.2.
orm is an externally defined certification request. One example is
an attribute certification request. The fields of this structure
are:
bodyPartID is the identifier number for this certification
request. Details on body part identifiers are found in
Section 3.2.2.
requestMessageType identifies the other request type. These
values are defined outside of this document.
requestMessageValue is the data associated with the other request
type.
3.2.1.2.1. PKCS #10 Certification Syntax
A certification request based on PKCS #10 uses the following ASN.1
structure:
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
The fields in TaggedCertificationRequest have the following meaning:
bodyPartID is the identifier number for this certification request.
Details on body part identifiers are found in Section 3.2.2.
Schaad & Myers Expires September 11, 2008 [Page 17]
Internet-Draft CMC: Structures March 2008
certificationRequest contains the PKCS #10 based certification
request. Its fields are described in [PKCS10].
When producing a certification request based on PKCS #10, clients
MUST produce the certification request with a subject name and public
key. Some PKI products are operated using a central repository of
information to assign subject names upon receipt of a certification
request. To accommodate this mode of operation, the subject field in
a CertificationRequest MAY be NULL, but MUST be present. CAs that
receive a CertificationRequest with a NULL subject field MAY reject
such certification requests. If rejected and a PKI Response is
returned, the CA MUST return a PKI Response with the CMCFailInfo
value with the value badRequest.
3.2.1.2.2. CRMF Certification Syntax
A CRMF message uses the following ASN.1 structure (defined in [CRMF]
and included here for convenience):
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
The fields in CertReqMsg are explained in [CRMF].
This document imposes the following additional restrictions on the
construction and processing of CRMF certification requests:
Schaad & Myers Expires September 11, 2008 [Page 18]
Internet-Draft CMC: Structures March 2008
When a Full PKI Request includes a CRMF certification request,
both the subject and publicKey fields in the CertTemplate MUST be
defined. The subject field can be encoded as NULL, but MUST be
present.
When both CRMF and CMC controls exist with equivalent
functionality, the CMC control SHOULD be used. The CMC control
MUST override the CRMF control.
The regInfo field MUST NOT be used on a CRMF certification
request. Equivalent functionality is provided in the CMC regInfo
control (Section 6.12).
The indirect method of proving POP is not supported in this
protocol. One of the other methods (including the direct method
described in this document) MUST be used. The value of encrCert
in SubsequentMessage MUST NOT be used.
Since the subject and publicKeyValues are always present, the
POPOSigningKeyInput MUST NOT be used when computing the value for
POPSigningKey.
A server is not required to use all of the values suggested by the
client in the CRMF certification request. Servers MUST be able to
process all extensions defined, but not prohibited in [PKIXCERT].
Servers are not required to be able to process other X.509v3
extensions transmitted using this protocol, nor are they required to
be able to process private extensions. Servers are permitted to
modify client-requested extensions. Servers MUST NOT alter an
extension so as to invalidate the original intent of a client-
requested extension. (For example change key usage from keyAgreement
to digitalSignature.) If a certification request is denied due to
the inability to handle a requested extension, the server MUST
respond with a Full PKI Response with a CMCFailInfo value with the
value of unsupportedExt.
3.2.1.2.3. Other Certification Request
This document allows for other certification request formats to be
defined and used as well. An example of an other certification
request format is one for Attribute Certificates. These other
certification request formats are defined by specifying an OID for
identification and the structure to contain the data to be passed.
3.2.1.3. Content Info Objects
The cmsSequence field of the PKIData and PKIResponse messages
contains zero or more tagged content info objects. The syntax for
Schaad & Myers Expires September 11, 2008 [Page 19]
Internet-Draft CMC: Structures March 2008
this structure is:
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
The fields in TaggedContentInfo have the following meaning:
bodyPartID is a unique integer that identifies this content info
object.
contentInfo is a ContentInfo object (defined in [CMS]).
The four content types used in cmsSequence are AuthenticatedData,
Data, EnvelopedData and SignedData. All of these content types are
defined in [CMS].
3.2.1.3.1. Authenticated Data
The AuthenticatedData content type provides a method of doing pre-
shared secret based validation of data being sent between two
parties. Unlike SignedData it does not specify which party actually
generated the information.
AuthenticatedData provides origination authentication in those
circumstances where a shared-secret exists, but a PKI based trust has
not yet been established. No PKI based trust may have been
established because a trust anchor has not been installed on the
client or no certificate exists for a signing key.
AuthenticatedData content type is used by this document for:
The id-cmc-authData control (Section 6.16), and
As the top-level wrapper in environments where an encryption only
key is being certified.
This content type can include both PKIData and PKIResponse as the
encapsulated content types. These embedded content types can contain
additional controls that need to be processed.
3.2.1.3.2. Data
The Data content type allows for general transport of unstructured
data.
The Data content type is used by this document for:
Schaad & Myers Expires September 11, 2008 [Page 20]
Internet-Draft CMC: Structures March 2008
Holding the encrypted random value y for POP proof in the
encrypted POP control (see Section 6.7).
3.2.1.3.3. Enveloped Data
The EnvelopedData content type provides for shrouding of data.
The EnvelopedData content type is the primary confidentiality method
for sensitive information in this protocol. EnvelopedData can
provide encryption of an entire PKI Request (see Section 5).
EnvelopedData can also be used to wrap private key material for key
archival. If the decryption on an EnvelopedData fails, the Full PKI
Response with a CMCFailInfo value with a value of badMessageCheck and
a bodyPartId of 0.
3.2.1.3.4. Signed Data
The SignedData content type provides for authentication and
integrity.
The SignedData content type is used by this document for:
The outer wrapper for a PKI Request.
The outer wrapper for a PKI Response.
As part of processing a PKI Request/Response, the signature(s) MUST
be verified. If the signature does not verify and the PKI Request/
Response contains anything other than a CMC Status Info control, a
Full PKI Response containing a CMC Status Info control MUST be
returned using a CMCFailInfo with a value of badMessageCheck and a
bodyPartId of 0.
For the PKI Response, SignedData allows the server to sign the
returning data, if any exists, and to carry the certificates and CRLs
corresponding to the PKI Request. If no data is being returned
beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo
fields are not populated.
3.2.1.4. Other Message Bodies
The otherMsgSequence field of the PKI Request/Response allows for
arbitrary data objects to be carried as part of a PKI Request/
Response. This is intended to contain a data object that is not
already wrapped in a cmsSequence field Section 3.2.1.3. The data
object is ignored unless a control references the data object by
bodyPartID.
Schaad & Myers Expires September 11, 2008 [Page 21]
Internet-Draft CMC: Structures March 2008
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
The fields in OtherMsg have the following meaning:
bodyPartID is the unique id identifying this data object.
otherMsgType is the OID that defines the type of message body
otherMsgValue is the data.
3.2.2. Body Part Identification
Each element of a PKIData or PKIResponse has an associated body part
identifier. The body part identifier is a 4-octet integer using the
ASN.1 of:
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
Body part identifiers are encoded in the certReqIds field for
CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of
the other objects. The body part identifier MUST be unique within a
single PKIData or PKIResponse. Body part identifiers can be
duplicated in different layers (for example a PKIData embedded within
another).
The bodyPartId value of 0 is reserved for use as the reference to the
current PKIData object.
Some controls, such as the Add Extensions control (Section 6.5.2) use
the body part identifier in the pkiDataReference field to refer to a
PKI Request in the current PKIData. Some controls, such as the
Extended CMC Status Info control (Section 6.1.1), will also use body
part identifiers to refer to elements in the previous PKI Request/
Response. This allows an error to be explicit about the control or
PKI Request to which the error applies.
A BodyPartList contains a list of body parts in a PKI Request/
Response (i.e. the Batch Request control in Section 6.17). The ASN.1
type BodyPartList is defined as:
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
A BodyPartPath contains a path of body part identifiers moving
Schaad & Myers Expires September 11, 2008 [Page 22]
Internet-Draft CMC: Structures March 2008
through nesting (i.e. the Modify Certificate Request control in
Section 6.5.1). The ASN.1 type BodyPartPath is defined as:
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
3.2.3. CMC Unsigned Data Attribute
There is sometimes a need to include data in a PKI Request designed
to be removed by an RA during processing. An example of this is the
inclusion of an encrypted private key, where a key archive agent
removes the encrypted private key before sending it on to the CA.
One side effect of this desire is that every RA which encapsulates
this information needs to move the data so that it is not covered by
that RA's signature. (A client PKI Request, encapsulated by an RA
cannot have a signed control removed by the key archive agent without
breaking the RA's signature.) The CMC Unsigned Data attribute
addresses this problem.
The CMC Unsigned Data attribute contains information that is not
directly signed by a client. When an RA encounters this attribute in
the unsigned or unauthenticated attribute field of a request it is
aggregating, the CMC Unsigned Data attribute is removed from the
request prior to placing it in a cmsSequence and placed in the
unsigned or unauthenticated attributes of the RA's signed or
authenticated data wrapper.
The CMC Unsigned Data attribute is identified by:
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
The CMC Unsigned Data attribute has the ASN.1 definition:
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
The fields in CMCUnsignedData have the following meaning:
bodyPartPath is the path pointing to the control associated with
this data. When an RA moves the control in an unsigned or
unauthenticated attribute up one level as part of wrapping the
data in a new SignedData or AuthenticatedData, the body part
identifier of the embedded item in the PKIData is pre-pended to
the bodyPartPath sequence.
Schaad & Myers Expires September 11, 2008 [Page 23]
Internet-Draft CMC: Structures March 2008
identifier is the OID that defines the associated data.
content is the data.
There MUST be at most one CMC Unsigned Data attribute in the
UnsignedAttribute sequence of a SignerInfo or in the
UnauthenticatedAttribute sequence of an AuthenticatedData.
UnsignedAttribute consists of a set of values, the attribute can have
any number of values greater than zero in that set. If the CMC
Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it
MUST appear with the same values(s) in all SignerInfo and
AuthenticatedData items.
Schaad & Myers Expires September 11, 2008 [Page 24]
Internet-Draft CMC: Structures March 2008
4. PKI Responses
Two types of PKI Responses exist. This section gives the details on
both types.
4.1. Simple PKI Response
Clients MUST be able to process the Simple PKI Response. The Simple
PKI Response consists of a SignedData with no EncapsulatedContentInfo
and no SignerInfo. The certificates requested in the PKI Response
are returned in the certificate field of the SignedData.
Clients MUST NOT assume the certificates are in any order. Servers
SHOULD include all intermediate certificates needed to form complete
certification paths to one or more trust anchors, not just the newly
issued certificate(s). The server MAY additionally return CRLs in
the CRL bag. Servers MAY include the self-signed certificates.
Clients MUST NOT implicitly trust included self-signed certificate(s)
merely due to its presence in the certificate bag. In the event
clients receive a new self-signed certificate from the server,
clients SHOULD provide a mechanism to enable the user to use the
certificate as a trust anchor. (The Publish Trust Anchors control
Section 6.15 should be used in the event that the server intends the
client to accept one or more certificates as trust anchors. This
requires the use of the Full PKI Response message.)
4.2. Full PKI Response
Clients MUST be able to process a Full PKI Response.
The Full PKI Response consists of a SignedData encapsulating a
PKIResponse content type. The certificates issued in a PKI Response
are returned in the certificates field of the immediately
encapsulating SignedData.
Clients MUST NOT assume the certificates are in any order. Servers
SHOULD include all intermediate certificates needed to form complete
chains one or more trust anchors, not just the newly issued
certificate(s). The server MAY additionally return CRLs in the CRL
bag. Servers MAY include self-signed certificates. Clients MUST NOT
implicitly trust included self-signed certificate(s) merely due to
its presence in the certificate bag. In the event clients receive a
new self-signed certificate from the server, clients MAY provide a
mechanism to enable the user to explicitly use the certificate as a
trust anchor. (The Publish Trust Anchors control Section 6.15 exists
for the purpose of allowing for distribution of trust anchor
certificates. If a trusted anchor publishes a new trusted anchor,
this is one case where automated trust of the new trust anchor could
Schaad & Myers Expires September 11, 2008 [Page 25]
Internet-Draft CMC: Structures March 2008
be allowed.)
4.2.1. PKIResponse Content Type
The PKIResponse content type is used for the Full PKI Response. The
PKIResponse content type is identified by:
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
The ASN.1 structure corresponding to the PKIResponse content type is:
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ReponseBody ::= PKIResponse
Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has
been renamed to PKIResponse for clarity and the old name kept as a
synonym.
The fields in PKIResponse have the following meaning:
controlSequence is a sequence of controls. The controls defined in
this document are found in Section 6. Controls can be defined by
other parties. Details on the TaggedAttribute structure are found
in Section 3.2.1.1.
cmsSequence is a sequence of [CMS] message objects. See
Section 3.2.1.3 for more details.
otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are referred to by one or more controls. This
allows for controls to use large amounts of data without the data
being embedded in the control. See Section 3.2.1.4 for more
details.
Processing of PKIResponse by a recipient is as follows:
1. All controls should be examined and processed in an appropriate
manner. The appropriate processing is to complete processing at
this time, to ignore the control or to place the control on a
to-do list for later processing.
2. Additional processing of non-element items includes the saving of
certificates and CRLs present in wrapping layers. This type of
Schaad & Myers Expires September 11, 2008 [Page 26]
Internet-Draft CMC: Structures March 2008
processing is based on the consumer of the element and should not
be relied on by generators.
No processing is required for cmsSequence or otherMsgSequence members
of the PKIResponse, if items are present and are not referenced by a
control. In this case, the cmsSequence and otherMsgSequence members
are to be ignored.
Schaad & Myers Expires September 11, 2008 [Page 27]
Internet-Draft CMC: Structures March 2008
5. Application of Encryption to a PKI Request/Response
There are occasions when a PKI Request or Response must be encrypted
in order to prevent disclosure of information in the PKI Request/
Response from being accessible to unauthorized entities. This
section describes the means to encrypt Full PKI Requests and
Responses (Simple PKI Requests cannot be encrypted). Data portions
of PKI Requests and Responses that are placed in the cmsSequence
field can be encrypted separately.
Confidentiality is provided by wrapping the PKI Request/Response (a
SignedData) in an EnvelopedData. The nested content type in the
EnvelopedData is id-SignedData. Note that this is different from
S/MIME where there is a MIME layer placed between the encrypted and
signed data. It is recommended that if an EnvelopedData layer is
applied to a PKI Request/Response, a second signature layer be placed
outside of the EnvelopedData layer. The following figure shows how
this nesting would be done:
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Note: PKIResponse can be substituted for PKIData in the above figure.
Options 1 and 2 prevent leakage of sensitive data by encrypting the
Full PKI Request/Response. An RA that receives a PKI Request that it
cannot decrypt MAY reject the PKI Request unless it can process the
PKI Request without knowledge of the contents (i.e., all it does is
amalgamate multiple PKI Requests and forwards them to a server).
After the RA removes the envelope and completes processing, it may
then apply a new EnvelopedData layer to protect PKI Requests for
transmission to the next processing agent. Section 7 contains more
information about RA processing.
Full PKI Requests/Responses can be encrypted or transmitted in the
clear. Servers MUST provide support for all three options.
Alternatively, an authenticated, secure channel could exist between
the parties that require confidentiality. Clients and servers MAY
use such channels instead of the technique described above to provide
secure, private communication of Simple and Full PKI Requests/
Responses.
Schaad & Myers Expires September 11, 2008 [Page 28]
Internet-Draft CMC: Structures March 2008
6. Controls
Controls are carried as part of both Full PKI Requests and Responses.
Each control is encoded as a unique OID followed by the data for the
control (see syntax in Section 3.2.1.1. The encoding of the data is
based on the control. Processing systems would first detect the OID
(TaggedAttribute attrType) and process the corresponding control
value (TaggedAttribute attrValues) prior to processing the message
body.
The OIDs are all defined under the following arc:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= { id-pkix 7 }
The following table lists the names, OID and syntactic structure for
each of the controls described in this document.
+------------------------+-------+------------------+---------------+
| Control Identifier | OID | Syntax | Section |
+------------------------+-------+------------------+---------------+
| id-cmc-statusInfo | id-cm | CMCStatusInfo | Section 6.1.2 |
| | c1 | | |
| | | | |
| id-cmc-identification | id-cm | UTF8String | Section 6.2.3 |
| | c2 | | |
| | | | |
| id-cmc-identityProof | id-cm | OCTET STRING | Section 6.2.2 |
| | c3 | | |
| | | | |
| id-cmc-dataReturn | id-cm | OCTET STRING | Section 6.4 |
| | c4 | | |
| | | | |
| id-cmc-transactionId | id-cm | INTEGER | Section 6.6 |
| | c5 | | |
| | | | |
| id-cmc-senderNonce | id-cm | OCTET STRING | Section 6.6 |
| | c6 | | |
| | | | |
| id-cmc-recipientNonce | id-cm | OCTET STRING | Section 6.6 |
| | c7 | | |
| | | | |
| id-cmc-addExtensions | id-cm | AddExtensions | Section 6.5.2 |
| | c8 | | |
| | | | |
Schaad & Myers Expires September 11, 2008 [Page 29]
Internet-Draft CMC: Structures March 2008
| id-cmc-encryptedPOP | id-cm | EncryptedPOP | Section 6.7 |
| | c9 | | |
| | | | |
| id-cmc-decryptedPOP | id-cm | DecryptedPOP | Section 6.7 |
| | c10 | | |
| | | | |
| id-cmc-lraPOPWitness | id-cm | LraPOPWitness | Section 6.8 |
| | c11 | | |
| | | | |
| id-cmc-getCert | id-cm | GetCert | Section 6.9 |
| | c15 | | |
| | | | |
| id-cmc-getCRL | id-cm | GetCRL | Section 6.10 |
| | c16 | | |
| | | | |
| id-cmc-revokeRequest | id-cm | RevokeRequest | Section 6.11 |
| | c17 | | |
| | | | |
| id-cmc-regInfo | id-cm | OCTET STRING | Section 6.12 |
| | c18 | | |
| | | | |
| id-cmc-responseInfo | id-cm | OCTET STRING | Section 6.12 |
| | c19 | | |
| | | | |
| id-cmc-queryPending | id-cm | OCTET STRING | Section 6.13 |
| | c21 | | |
| | | | |
| id-cmc-popLinkRandom | id-cm | OCTET STRING | Section 6.3.1 |
| | c22 | | .3 |
| | | | |
| id-cmc-popLinkWitness | id-cm | OCTET STRING | Section 6.3.1 |
| | c23 | | .2 |
| | | | |
| id-cmc-popLinkWitnessV | id-cm | OCTET STRING | Section 6.3.1 |
| 2 | c33 | | .1 |
| | | | |
| id-cmc-confirmCertAcce | id-cm | CMCCertId | Section 6.14 |
| ptance | c24 | | |
| | | | |
| id-cmc-statusInfoV2 | id-cm | CMCStatusInfoV2 | Section 6.1.1 |
| | c25 | | |
| | | | |
| id-cmc-trustedAnchors | id-cm | PublishTrustAnch | Section 6.15 |
| | c26 | ors | |
| | | | |
| id-cmc-authData | id-cm | AuthPublish | Section 6.16 |
| | c27 | | |
| | | | |
Schaad & Myers Expires September 11, 2008 [Page 30]
Internet-Draft CMC: Structures March 2008
| id-cmc-batchRequests | id-cm | BodyPartList | Section 6.17 |
| | c28 | | |
| | | | |
| id-cmc-batchResponses | id-cm | BodyPartList | Section 6.17 |
| | c29 | | |
| | | | |
| id-cmc-publishCert | id-cm | CMCPublicationIn | Section 6.18 |
| | c30 | fo | |
| | | | |
| id-cmc-modCertTemplate | id-cm | ModCertTemplate | Section 6.5.1 |
| | c31 | | |
| | | | |
| id-cmc-controlProcesse | id-cm | ControlsProcesse | Section 6.19 |
| d | c32 | d | |
| | | | |
| id-cmc-identityProofV2 | id-cm | IdentityProofV2 | Section 6.2.1 |
| | c34 | | |
+------------------------+-------+------------------+---------------+
Table 1: CMC Control Attributes
6.1. CMC Status Info Controls
The CMC Status Info controls return information about the status of a
client/server request/response. Two controls are described in this
section. The Extended CMC Status Info control is the preferred
control; the CMC Status Info control is included for backwards
compatibility with RFC 2797.
Servers MAY emit multiple CMC status info controls referring to a
single body part. Clients MUST be able to deal with multiple CMC
status info controls in a PKI Response. Servers MUST use the
Extended CMC Status Info control, but MAY additionally use the CMC
Status Info control. Clients MUST be able to process the Extended
CMC Status Info control.
6.1.1. Extended CMC Status Info Control
The Extended CMC Status Info control is identified by the OID:
id-cmc-statusInfoV2 ::= { id-cmc 25 }
The Extended CMC Status Info control has the ASN.1 definition:
Schaad & Myers Expires September 11, 2008 [Page 31]
Internet-Draft CMC: Structures March 2008
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
The fields in CMCStatusInfoV2 have the following meaning:
cMCStatus contains the returned status value. Details are in
Section 6.1.3.
bodyList identifies the controls or other elements to which the
status value applies. If an error is returned for a Simple PKI
Request, this field is the bodyPartID choice of BodyPartReference
with the single integer of value 1.
statusString contains additional description information. This
string is human readable.
otherInfo contains additional information that expands on the CMC
status code returned in the cMCStatus field.
The fields in OtherStatusInfo have the following meaning:
Schaad & Myers Expires September 11, 2008 [Page 32]
Internet-Draft CMC: Structures March 2008
failInfo is described in Section 6.1.4. It provides an error code
that details what failure occurred. This choice is present only
if cMCStatus contains the value failed.
pendInfo contains information about when and how the client should
request for the result of this request. It is present when the
cMCStatus is either pending or partial. pendInfo uses the
structure PendInfo, which has the fields:
pendToken is the token used in the Query Pending control
Section 6.13.
pendTime contains the suggested time the server wants to be
queried about the status of the certification request.
extendedFailInfo includes application dependent detail error
information. This choice is present only if cMCStatus contains
the value failed. Caution should be used when defining new values
as they may not be correctly recognized by all clients and
servers. The CMCFailInfo value of internalCAError may be assumed
if the extended error is not recognized. This field uses the type
ExtendedFailInfo. ExtendedFailInfo has the fields:
failInfoOID contains an OID that is associated with a set of
extended error values.
failInfoValue contains an extended error code from the defined
set of extended error codes.
If the cMCStatus field is success, the Extended CMC Status Info
control MAY be omitted unless it is the only item in the response.
6.1.2. CMC Status Info Control
The CMC Status Info control is identified by the OID:
id-cmc-statusInfo ::= { id-cmc 1 }
The CMC Status Info control has the ASN.1 definition:
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
Schaad & Myers Expires September 11, 2008 [Page 33]
Internet-Draft CMC: Structures March 2008
The fields in CMCStatusInfo have the following meaning:
cMCStatus contains the returned status value. Details are in
Section 6.1.3.
bodyList contains the list of controls or other element to which the
status value applies. If an error is being returned for a Simple
PKI Request, this field contains a single integer of value 1.
statusString contains additional description information. This
string is human readable.
otherInfo provides additional information that expands on the CMC
status code returned in the cMCStatus field.
failInfo is described in Section 6.1.4. It provides an error
code that details what failure occurred. This choice is
present only if cMCStatus is failed.
pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It
contains information about when and how the client should
request for results on this request. The pendInfo field MUST
be populated for a cMCStatus value of pending or partial.
Further details can be found in Section 6.1.1 (Extended CMC
Status Info Control) and Section 6.13 (Query Pending Control).
If the cMCStatus field is success, the CMC Status Info control MAY be
omitted unless it is the only item in the response. If no status
exists for a Simple or Full PKI Request, then the value of success is
assumed.
6.1.3. CMCStatus values
CMCStatus is a field in the Extended CMC Status Info and CMC Status
Info controls. This field contains a code representing the success
or failure of a specific operation. CMCStatus has the ASN.1
structure:
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
Schaad & Myers Expires September 11, 2008 [Page 34]
Internet-Draft CMC: Structures March 2008
The values of CMCStatus have the following meaning:
success indicates the request was granted or the action was
completed.
failed indicates the request was not granted or the action was not
completed. More information is included elsewhere in the
response.
pending indicates the PKI Request has yet to be processed. The
requestor is responsible to poll back on this Full PKI request.
pending may only be returned for certification request operations.
noSupport indicates the requested operation is not supported.
confirmRequired indicates a Confirm Certificate Acceptance control
Section 6.14 must be returned before the certificate can be used.
popRequired indicates an direct POP operation is required
Section 6.3.1.3.
partial indicates a partial PKI Response is returned. The requestor
is responsible to poll back for the unfulfilled portions of the
Full PKI Request.
6.1.4. CMCFailInfo
CMCFailInfo is a field in the Extended CMC Status Info and CMC Status
Info controls. CMCFailInfo conveys more detailed information
relevant to the interpretation of a failure condition. The
CMCFailInfo has the following ASN.1 structure:
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsuportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
Schaad & Myers Expires September 11, 2008 [Page 35]
Internet-Draft CMC: Structures March 2008
The values of CMCFailInfo have the following meanings:
badAlg indicates unrecognized or unsupported algorithm.
badMessageCheck indicates integrity check failed.
badRequest indicates transaction not permitted or supported.
badTime indicates message time field was not sufficiently close to
the system time.
badCertId indicates no certificate could be identified matching the
provided criteria.
unsuportedExt indicates a requested X.509 extension is not supported
by the recipient CA.
mustArchiveKeys indicates private key material must be supplied.
badIdentity indicates identification control failed to verify.
popRequired indicates server requires a POP proof before issuing
certificate.
popFailed indicates POP processing failed.
noKeyReuse indicates server policy does not allow key reuse.
internalCAError indicates that the CA had an unknown internal
failure.
tryLater indicates that the server is not accepting requests at this
time and the client should try at a later time.
authDataFail indicates failure occurred during processing of
authenticated data
If additional failure reasons are needed, they SHOULD use the
ExtendedFailureInfo item in the Extended CMC Status Info control.
However for closed environments they can be defined using this type.
Such codes MUST be in the range from 1000 to 1999.
6.2. Identification and Identity Proof Controls
Some CAs and RAs require that a proof-of-identity be included in a
certification request. Many different ways of doing this exist with
different degrees of security and reliability. Most are familiar
with a bank's request to provide your mother's maiden name as a form
Schaad & Myers Expires September 11, 2008 [Page 36]
Internet-Draft CMC: Structures March 2008
of identity proof. The reasoning behind requiring a proof-of-
identity can be found in Appendix C of [CRMF].
CMC provides a method to prove the client's identity based on a
client/server shared-secret. If clients support the Full PKI
Request, clients MUST implement this method of identity proof
(Section 6.2.2). Servers MUST provide this method, but MAY
additionally support bilateral methods of similar strength.
This document also provides an Identification control
(Section 6.2.3). This control is a simple method to allow a client
to state who they are to the server. Generally, a shared secret AND
an identifier of that shared-secret is passed from the server to the
client. The identifier is placed in the Identification control and
the shared-secret is used to compute the Identity Proof control.
6.2.1. Identity Proof Version 2 Control
The Identity Proof Version 2 control is identified by the OID:
id-cmc-identityProofV2 ::= { id-cmc 34 }
The Identity Proof Version 2 control has the ASN.1 definition:
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}
The fields of IdentityProofV2 have the following meaning:
hashAlgID is the identifier and parameters for the hash algorithm
used to convert the shared-secret into a key for the MAC
algorithm.
macAlgID is the identifier and the parameters for the message
authentication code algorithm used to compute the value of the
witness field.
witness is the identity proof.
The required method starts with an out-of-band transfer of a token
(the shared-secret). The shared-secret should be generated in a
random manner. The distribution of this token is beyond the scope of
this document. The client then uses this token for an identity proof
as follows:
Schaad & Myers Expires September 11, 2008 [Page 37]
Internet-Draft CMC: Structures March 2008
1. The PKIData reqSequence field (encoded exactly as it appears in
the Full PKI Request including the sequence type and length) is
the value to be validated.
2. A hash of the shared-secret as a UTF8 string is computed using
hashAlgID.
3. A MAC is then computed using the value produced in Step 1 as the
message and the value from Step 2 as the key.
4. The result from Step 3 is then encoded as the witness value in
the Identity Proof Version 2 control.
When the server verifies the Identity Proof Version 2 control, it
computes the MAC value in the same way and compares it to the witness
value contained in the PKI Request.
If a server fails the verification of an Identity Proof Version 2
control, the CMCFailInfo value MUST be present in the Full PKI
Response and MUST have a value of badIdentity.
Reuse of the shared-secret on certification request retries allows
the client and server to maintain the same view of acceptable
identity proof values. However, reuse of the shared-secret can
potentially open the door for some types of attacks.
Implementations MUST be able to support tokens at least 16 characters
long. Guidance on the amount of entropy actually obtained from a
given length token based on character sets can be found in Appendix A
of [PASSWORD].
6.2.2. Identity Proof Control
The Identity Proof control is identified by the OID:
id-cmc-identityProof ::= { id-cmc 3 }
The Identity Proof control has the ASN.1 definition:
IdentifyProof ::= OCTET STRING
This control is processed in the same way as the Identity Proof
Version 2 control. In this case the hash algorithm is fixed to SHA-1
and the MAC algorithm is fixed to HMAC-SHA1.
Schaad & Myers Expires September 11, 2008 [Page 38]
Internet-Draft CMC: Structures March 2008
6.2.3. Identification Control
Optionally, servers MAY require the inclusion of the unprotected
Identification control with an Identification Proof control. The
Identification control is intended to contain a text string which
assists the server in locating the shared-secret needed to validate
the contents of the Identity Proof control. If the Identification
control is included in the Full PKI Request, the derivation of the
key in step 2 (from Section 6.2.1 is altered so that the hash of the
concatenation of the shared-secret and the UTF8 identity value
(without the type and length bytes) are hashed rather than just the
shared-secret.
The Identification control is identified by the OID:
id-cmc-identification ::= { id-cmc 2 }
The Identification control has the ASN.1 definition:
Identification ::= UTF8String
6.2.4. Hardware Shared-Secret Token Generation
The shared-secret between the EE and the server is sometimes computed
using a hardware device that generates a series of tokens. The EE
can therefore prove their identity by transferring this token in
plain text along with a name string. The above protocol can be used
with a hardware shared-secret token generation device by the
following modifications:
1. The Identification control MUST be included and MUST contain the
hardware-generated token.
2. The shared-secret value used above is the same hardware-generated
token.
3. All certification requests MUST have a subject name and the
subject name MUST contain the fields required to identify the
holder of the hardware token device.
4. The entire certification request MUST be shrouded in some fashion
to prevent eavesdropping. Although the token is time critical,
an active eavesdropper cannot be permitted to extract the token
and submit a different certification request with the same token
value.
Schaad & Myers Expires September 11, 2008 [Page 39]
Internet-Draft CMC: Structures March 2008
6.3. Linking Identity and POP Information
In a Full PKI Request, identity information about the client is
carried in the signature of the SignedData containing all of the
certification requests. Proof-of-possession information for key
pairs, however, is carried separately for each PKCS #10 or CRMF
certification request. (For keys capable of generating a digital
signature, the POP is provided by the signature on the PKCS #10 or
CRMF request. For encryption-only keys the controls described in
Section 6.7 are used.) In order to prevent substitution-style
attacks, the protocol must guarantee that the same entity generated
both the POP and proof-of-identity information.
This section describes two mechanisms for linking identity and POP
information: witness values cryptographically derived from the
shared-secret (Section 6.3.1.3) and shared-secret/subject DN matching
(Section 6.3.2). Clients and servers MUST support the witness value
technique. Clients and servers MAY support shared-secret/subject DN
matching or other bilateral techniques of similar strength. The idea
behind both mechanisms is to force the client to sign some data into
each certification request that can be directly associated with the
shared-secret; this will defeat attempts to include certification
requests from different entities in a single Full PKI Request.
6.3.1. Cryptographic Linkage
The first technique that links identity and POP information forces
the client to include a piece of information cryptographically-
derived from the shared-secret as a signed extension within each
certification request (PKCS #10 or CRMF).
6.3.1.1. POP Link Witness Version 2 Controls
The POP Link Witness Version 2 control is identified by the OIDs:
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }
The POP Link Witness Version 2 control has the ASN.1 definition:
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
The fields of PopLinkWitnessV2 have the meaning:
Schaad & Myers Expires September 11, 2008 [Page 40]
Internet-Draft CMC: Structures March 2008
keyGenAlgorithm contains the algorithm used to generate the key for
the MAC algorithm. This will generally be a hash algorithm, but
could be a more complex algorithm.
macAlgorithm contains the algorithm used to create the witness
value.
witness contains the computed witness value.
This technique is useful if null subject DNs are used (because, for
example, the server can generate the subject DN for the certificate
based only on the shared-secret). Processing begins when the client
receives the shared-secret out-of-band from the server. The client
then computes the following values:
1. The client generates a random byte-string, R, which SHOULD be at
least 512 bits in length.
2. The key is computed from the shared-secret using the algorithm in
keyGenAlgorithm.
3. A MAC is then computed over the random value produced in Step 1,
using the key computed in Step 2.
4. The random value produced in Step 1 is encoded as the value of a
POP Link Random control. This control MUST be included in the
Full PKI Request.
5. The MAC value produced in Step 3 is placed in either the POP Link
Witness control or the witness field of the POP Link Witness V2
control.
* For CRMF, the POP Link Witness/POP Link Witness V2 control is
included in the controls field of the CertRequest structure.
* For PKCS #10, the POP Link Witness/POP Link Witness V2 control
is included in the attributes field of the
CertificationRequestInfo structure.
Upon receipt, servers MUST verify that each certification request
contains a copy of the POP Link Witness/POP Link Witness V2 control
and that its value was derived using the above method from the
shared-secret and the random string included in the POP Link Random
control.
The Identification control (see Section 6.2.3) or the subject DN of a
certification request can be used to help identify which shared-
secret was used.
Schaad & Myers Expires September 11, 2008 [Page 41]
Internet-Draft CMC: Structures March 2008
6.3.1.2. POP Link Witness Control
The POP Link Witness control is identified by the OIDs:
id-cmc-popLinkWitness ::= { id-cmc 23 }
The POP Link Witness control has the ASN.1 definition:
PopLinkWitness ::= OCTET STRING
For this control, SHA-1 is used as the key generation algorithm.
HMAC-SHA1 is used as the mac algorithm.
6.3.1.3. POP Link Random Control
The POP Link Random control is identified by the OID:
The POP Link Random is identified by the OID:
id-cmc-popLinkRandom ::= { id-cmc 22 }
The POP Link Random control has the ASN.1 definition:
PopLinkRandom ::= OCTET STRING
6.3.2. Shared-secret/subject DN linking
The second technique to link identity and POP information is to link
a particular subject distinguished name (subject DN) to the shared-
secrets that are distributed out-of-band and to require that clients
using the shared-secret to prove identity include that exact subject
DN in every certification request. It is expected that many client-
server connections that use shared-secret based proof-of-identity
will use this mechanism. (It is common not to omit the subject DN
information from the certification request.)
When the shared-secret is generated and transferred out-of-band to
initiate the registration process (Section 6.2), a particular subject
DN is also associated with the shared-secret and communicated to the
client. (The subject DN generated MUST be unique per entity in
accordance with the CA policy; a null subject DN cannot be used. A
common practice could be to place the identification value as part of
the subject DN.) When the client generates the Full PKI Request, it
MUST use these two pieces of information as follows:
1. The client MUST include the specific subject DN that it received
along with the shared-secret as the subject name in every
certification request (PKCS #10 and/or CRMF) in the Full PKI
Schaad & Myers Expires September 11, 2008 [Page 42]
Internet-Draft CMC: Structures March 2008
Request. The subject names in the certification requests MUST
NOT be null.
2. The client MUST include an Identity Proof control (Section 6.2.2)
or Identity Proof Version 2 (Section 6.2.1), derived from the
shared-secret, in the Full PKI Request.
The server receiving this message MUST (a) validate the Identity
Proof control and then, (b) check that the subject DN included in
each certification request matches that associated with the shared-
secret. If either of these checks fails the certification request
MUST be rejected.
6.3.3. Renewal and Re-Key Messages
When doing a renewal or re-key certification request, linking
identity and POP information is simple. The client copies the
subject DN for a current signing certificate into the subject name
field of each certification request that is made. The POP for each
certification request will now cover that information. The outmost
signature layer is created using the current signing certificate,
which allows the original identity to be associated with the
certification request. Since the name in the current signing
certificate and the names in the certification requests match, the
necessary linking has been achieved.
6.4. Data Return Control
The Data Return control allows clients to send arbitrary data
(usually some type of internal state information) to the server and
to have the data returned as part of the Full PKI Response. Data
placed in a Data Return control is considered to be opaque to the
server. The same control is used for both Full PKI Requests and
Responses. If the Data Return control appears in a Full PKI Request,
the server MUST return it as part of the PKI Response.
In the event that the information in the Data Return control needs to
be confidential, it is expected that the client would apply some type
of encryption to the contained data, but the details of this are
outside the scope of this specification.
The Data Return control is identified by the OID:
id-cmc-dataReturn ::= { id-cmc 4 }
The Data Return control has the ASN.1 definition:
DataReturn ::= OCTET STRING
Schaad & Myers Expires September 11, 2008 [Page 43]
Internet-Draft CMC: Structures March 2008
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
Certificate Request (Section 6.5.1), allows the RA to replace or
remove of any field in the certificate. The second control, Add
Extensions (Section 6.5.2), only allows for the addition of
extensions.
6.5.1. Modify Certificate Request Control
The Modify Certificate Request control is used by RAs to change
fields in a requested certificate.
The Modify Certificate Request control is identified by the OID:
id-cmc-modCertTemplate ::= { id-cmc 31 }
The Modify Certificate Request has the ASN.1 definition:
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
The fields in ModCertTemplate have the following meaning:
pkiDataReference is the path to the PKI Request containing
certification request(s) to be modified.
certReferences refers to one or more certification requests in the
PKI Request referenced by pkiDataReference to be modified. Each
BodyPartID of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg (CRMF). By
definition, the certificate extensions included in the
certTemplate field are applied to every certification request
referenced in the certReferences sequence. If a request
Schaad & Myers Expires September 11, 2008 [Page 44]
Internet-Draft CMC: Structures March 2008
corresponding to bodyPartID cannot be found, the CMCFailInfo with
a value of badRequest is returned that references this control.
replace specifies if the target certification request is to be
modified by replacing or deleting fields. If the value is TRUE,
the data in this control replaces the data in the target
certification request. If the value is FALSE, the data in the
target certification request is deleted. The action is slightly
different for the extensions field of certTemplate, each extension
is treated individually rather than as a single unit.
certTemplate is a certificate template object [CRMF]. If a field is
present and replace is TRUE, it replaces that field in the
certification request. If the field is present and replace is
FALSE, the field in the certification request is removed. If the
field is absent, no action is performed. Each extension is
treated as a single field.
Servers MUST be able to process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers are not required to be able to
process every X.509v3 extension transmitted using this protocol, nor
are they required to be able to process other, private extensions.
Servers are not required to put all RA-requested extensions into a
certificate. Servers are permitted to modify RA-requested
extensions. Servers MUST NOT alter an extension so as to reverse the
meaning of a client-requested extension. If a certification request
is denied due to the inability to handle a requested extension and a
Full PKI Response is returned, the server MUST return a CMCFailInfo
value with the value of unsupportedExt.
If a certification request is the target of multiple Modify
Certificate Request controls, the behavior is:
o If control A exists in a layer that contains the layer of control
B, control A MUST override control B. In other words, controls
should be applied from the innermost layer to the outermost layer.
o If control A and control B are in the same PKIData (i.e. the same
wrapping layer), the order of application is non-determinate.
The same order of application is used if a certification request is
the target of both a Modify Certificate Request control and an Add
Extensions control.
6.5.2. Add Extensions Control
The Add Extensions control has been deprecated in favor of the Modify
Certificate Request control. It was replaced so that fields in the
Schaad & Myers Expires September 11, 2008 [Page 45]
Internet-Draft CMC: Structures March 2008
certification request other than extensions could be modified.
The Add Extensions control is used by RAs to specify additional
extensions that are to be included in certificates.
The Add Extensions control is identified by the OID:
id-cmc-addExtensions ::= { id-cmc 8 }
The Add Extensions control has the ASN.1 definition:
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
The fields in AddExtensions have the following meaning:
pkiDataReference contains the body part identity of the embedded
certification request.
certReferences is a list of references to one or more of the
certification requests contained within a PKIData. Each body part
identifier of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg (CRMF). By
definition, the listed extensions are to be applied to every
certification request referenced in the certReferences sequence.
If a certification request corresponding to bodyPartID cannot be
found, the CMCFailInfo with a value of badRequest is returned
referencing this control.
extensions is a sequence of extensions to be applied to the
referenced certification requests.
Servers MUST be able to process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers are not required to be able to
process every X.509v3 extension transmitted using this protocol, nor
are they required to be able to process other, private extensions.
Servers are not required to put all RA-requested extensions into a
certificate. Servers are permitted to modify RA-requested
extensions. Servers MUST NOT alter an extension so as to reverse the
meaning of a client-requested extension If a certification request is
denied due to the inability to handle a requested extension and a
response is returned, the server MUST return a CMCFailInfo with the
value of unsupportedExt.
Schaad & Myers Expires September 11, 2008 [Page 46]
Internet-Draft CMC: Structures March 2008
If multiple Add Extensions controls exist in a Full PKI Request, the
exact behavior is left up to the CA policy. However it is
recommended that the following policy be used. These rules would be
applied to individual extensions within an Add Extensions control (as
opposed to an "all or nothing" approach).
1. If the conflict is within a single PKIData, the certification
request would be rejected with a CMCFailInfo value of badRequest.
2. If the conflict is between different PKIData, the outermost
version of the extension would be used (allowing an RA to
override the requested extension).
6.6. Transaction Identifier, Sender and Recipient Nonce Controls
Transactions are identified and tracked with a transaction
identifier. If used, clients generate transaction identifiers and
retain their value until the server responds with a Full PKI Response
that completes the transaction. Servers correspondingly include
received transaction identifiers in the Full PKI Response.
The Transaction Identifier control is identified by the OID:
id-cmc-transactionId ::= { id-cmc 5 }
The Transaction Identifier control has the ASN.1 definition:
TransactionId ::= INTEGER
The Transaction Identifier control identifies a given transaction.
It is used by client and server to manage the state of an operation.
Clients MAY include a Transaction Identifier control in 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
Schaad & Myers Expires September 11, 2008 [Page 47]
Internet-Draft CMC: Structures March 2008
message associated with the same transaction.
The Sender Nonce and Recipient controls are identified by the OIDs:
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }
The Sender Nonce control has the ASN.1 definition:
SenderNonce ::= OCTET STRING
The Recipient Nonce control has the ASN.1 definition:
RecepientNonce ::= 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 [