< draft-ietf-pkix-2797-bis-00.txt   draft-ietf-pkix-2797-bis-01.txt >
PKIX Working Group M. Myers PKIX Working Group J. Schaad
Internet Draft VeriSign Internet Draft Soaring Hawk Consulting
Document: draft-ietf-pkix-2797-bis-00.txt X. Liu M. Myers
February 2001 Cisco February 2002 TraceRoute Security
Expires: July 2001 J. Schaad Expires: August 2002 X. Liu
Soaring Hawk Consulting Cisco
J. Weinstein J. Weinstein
Certificate Management Messages over CMS Certificate Management Messages over CMS
draft-ietf-pkix-2797-bis-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
skipping to change at line 56 skipping to change at line 58
and services based on [CMS] and [PKCS10], and and services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for 2. The need in [SMIMEV3] for a certificate enrollment protocol for
DSA-signed certificates with Diffie-Hellman public keys. DSA-signed certificates with Diffie-Hellman public keys.
A small number of additional services are defined to supplement the A small number of additional services are defined to supplement the
core certificate request service. core certificate request service.
Throughout this specification the term CMS is used to refer to both Throughout this specification the term CMS is used to refer to both
[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a [CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a
superset of the PKCS7. In general, the use of PKCS7 in this document superset of the PKCS7. In general, the use of PKCS7 in this document
is aligned to the Cryptographic Message Syntax [CMS] that provides a
superset of the PKCS7 syntax. The term CMC refers to this superset of the PKCS7 syntax. The term CMC refers to this
specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", specification.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC 2119]. 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 [RFC 2119].
1. Protocol Requirements 1. Protocol Requirements
- The protocol is to be based as much as possible on the existing - The protocol is to be based as much as possible on the existing
CMS, PKCS#10 and CRMF specifications. CMS, PKCS#10 and CRMF specifications.
- The protocol must support the current industry practice of a - The protocol must support the current industry practice of a
PKCS#10 request followed by a PKCS#7 response as a subset of the PKCS#10 request followed by a PKCS#7 response as a subset of the
protocol. protocol.
- The protocol needs to easily support the multi-key enrollment
protocols required by S/MIME and other groups. - The protocol needs to easily support the multi-key enrollment
- The protocol must supply a way of doing all operations in a protocols required by S/MIME and other groups.
single-round trip. When this is not possible the number of round - The protocol must supply a way of doing all operations in a
trips is to be minimized. single-round trip. When this is not possible the number of round
- The protocol will be designed such that all key generation can trips is to be minimized.
occur on the client. - The protocol will be designed such that all key generation can
- The mandatory algorithms must superset the required algorithms occur on the client.
for S/MIME. - The mandatory algorithms must superset the required algorithms
- The protocol will contain POP methods. Optional provisions for for S/MIME.
multiple-round trip POP will be made if necessary.
- The protocol will support deferred and pending responses to - The protocol will contain POP methods. Optional provisions for
certificate request for cases where external procedures are required multiple-round trip POP will be made if necessary.
to issue a certificate. - The protocol will support deferred and pending responses to
- The protocol needs to support arbitrary chains of local certificate request for cases where external procedures are required
registration authorities as intermediaries between certificate to issue a certificate.
requesters and issuers. - The protocol needs to support arbitrary chains of local
registration authorities as intermediaries between certificate
requesters and issuers.
2. Protocol Overview 2. Protocol Overview
An enrollment transaction in this specification is generally An enrollment transaction in this specification is generally
composed of a single round trip of messages. In the simplest case composed of a single round trip of messages. In the simplest case
an enrollment request is sent from the client to the server and an an enrollment request is sent from the client to the server and an
enrollment response is then returned from the server to the client. enrollment response is then returned from the server to the client.
In some more complicated cases, such as delayed certificate issuance In some more complicated cases, such as delayed certificate issuance
and polling for responses, more than one round trip is required. and polling for responses, more than one round trip is required.
This specification supports two different request messages and two This specification supports two different request messages and two
different response messages. different response messages.
Public key certification requests can be based on either the PKCS10 Public key certification requests can be based on either the PKCS10
or CRMF object. The two different request messages are (a) the bare or CRMF object. The two different request messages are (a) the bare
PKCS10 (in the event that no other services are needed), and (b) the PKCS10 (in the event that no other services are needed), and (b) the
PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a
PKIData object. PKIData object.
Public key certification responses are based on the CMS signedData Public key certification responses are based on the CMS signedData
object. The response may be either (a) a degenerate CMS signedData object. The response may be either (a) a degenerate CMS signedData
object (in the event no other services are needed), or (b) a object (in the event no other services are needed), or (b) a
ResponseBody object wrapped in a CMS signedData object. ResponseBody object wrapped in a CMS signedData object.
No special services are provided for doing either renewal (new No special services are provided for doing either renewal (new
certificates with the same key) or re-keying (new certificates on certificates with the same key) or re-keying (new certificates on
new keys) of clients. Instead a renewal/re-key message looks the new keys) of clients. Instead a renewal/re-key message looks the
same as any enrollment message, with the identity proof being same as any enrollment message, with the identity proof being
supplied by existing certificates from the CA. supplied by existing certificates from the CA.
A provision exists for Local Registration Authorities (LRAs) to A provision exists for Local Registration Authorities (LRAs) to
participate in the protocol by taking client enrollment messages, participate in the protocol by taking client enrollment messages,
wrapping them in a second layer of enrollment message with wrapping them in a second layer of enrollment message with
additional requirements or statements from the LRA and then passing additional requirements or statements from the LRA and then passing
this new expanded request on to the Certification Authority. this new expanded request on to the Certification Authority.
This specification makes no assumptions about the underlying This specification makes no assumptions about the underlying
transport mechanism. The use of CMS is not meant to imply an email- transport mechanism. The use of CMS is not meant to imply an email-
based transport. based transport.
Optional services available through this specification are Optional services available through this specification are
transaction management, replay detection (through nonces), deferred transaction management, replay detection (through nonces), deferred
certificate issuance, certificate revocation requests and certificate issuance, certificate revocation requests and
certificate/CRL retrieval. certificate/CRL retrieval.
2.1 Terminology 2.1 Terminology
There are several different terms, abbreviations and acronyms used There are several different terms, abbreviations and acronyms used
in this document that we define here for convenience and consistency
of usage:
"End-Entity" (EE) refers to the entity that owns a key pair and for in this document that we define here for convenience and consistency
whom a certificate is issued.
"LRA" or "RA" refers to a (Local) Registration Authority. A of usage:
registration authority acts as an intermediary between an End-Entity
and a Certification Authority. Multiple RAs can exist between the "End-Entity" (EE) refers to the entity that owns a key pair and for
End-Entity and the Certification Authority.
"CA" refers to a Certification Authority. A Certification Authority whom a certificate is issued.
is the entity that performs the actual issuance of a certificate.
"Client" refers to an entity that creates a PKI request. In this "LRA" or "RA" refers to a (Local) Registration Authority. A
document both RAs and End-Entities can be clients.
"Server" refers to the entities that process PKI requests and create registration authority acts as an intermediary between an End-Entity
PKI responses. CAs and RAs can be servers in this document.
"PKCS#10" refers the Public Key Cryptography Standard #10. This is and a Certification Authority. Multiple RAs can exist between the
one of a set of standards defined by RSA Laboratories in the 1980s.
PKCS#10 defines a Certificate Request Message syntax. End-Entity and the Certification Authority.
"CRMF" refers to the Certificate Request Message Format RFC [CRMF].
We are using certificate request message format defined in this "CA" refers to a Certification Authority. A Certification Authority
document as part of our management protocol.
"CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This is the entity that performs the actual issuance of a certificate.
document provides for basic cryptographic services including
encryption and signing with and without key management. "Client" refers to an entity that creates a PKI request. In this
"POP" is an acronym for "Proof of Possession". POP refers to a
value that can be used to prove that the private key corresponding document both RAs and End-Entities can be clients.
to a public key is in the possession and can be used by an end-
entity. "Server" refers to the entities that process PKI requests and create
"Transport wrapper" refers to the outermost CMS wrapping layer.
PKI responses. CAs and RAs can be servers in this document.
"PKCS#10" refers the Public Key Cryptography Standard #10. This is
one of a set of standards defined by RSA Laboratories in the 1980s.
PKCS#10 defines a Certificate Request Message syntax.
"CRMF" refers to the Certificate Request Message Format RFC [CRMF].
We are using certificate request message format defined in this
document as part of our management protocol.
"CMS" refers to the Cryptographic Message Syntax RFC [CMS]. This
document provides for basic cryptographic services including
encryption and signing with and without key management.
"POP" is an acronym for "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.
"Transport wrapper" refers to the outermost CMS wrapping layer.
2.2 Protocol Flow Charts 2.2 Protocol Flow Charts
Figure 1 shows the Simple Enrollment Request and Response messages. Figure 1 shows the Simple Enrollment Request and Response messages.
The contents of these messages are detailed in Sections 4.1 and 4.3
below.
Simple PKI Request Simple PKI Response The contents of these messages are detailed in Sections 4.1 and 4.3
------------------------- --------------------------
+----------+ +------------------+ below.
| PKCS #10 | | CMS "certs-only" |
+----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Request and Response Messages Simple PKI Request Simple PKI Response
Full PKI Request Full PKI Response ------------------------- --------------------------
----------------------- ------------------------
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
Figure 2: Full PKI Request and Response Messages +----------+ +------------------+
Figure 2 shows the Full Enrollment Request and Response messages. | PKCS #10 | | CMS "certs-only" |
The contents of these messages are detailed in Sections 4.2 and 4.4
below. +----------+--------------+ | message |
| | +------------------+------+
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes | | or more certificates in |
| | | the "certificates" |
+-----------+-------------+ | portion of the |
| signed with | | signedData. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is empty. |
| |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Request and Response Messages
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS signedData | | CMS signedData |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData object | | ResponseBody object |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS#10 | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData. |
| OID) pairs. | | Relevant CA certs and |
| | | CRLs can be included as |
+-------+-----------------+ | well. |
| used may be pre-| +---------+---------------+
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) | +---------------+
+-----------------+
Figure 2: Full PKI Request and Response Messages
Figure 2 shows the Full Enrollment Request and Response messages.
The contents of these messages are detailed in Sections 4.2 and 4.4
below.
3. Protocol Elements 3. Protocol Elements
This section covers each of the different elements that may be used This section covers each of the different elements that may be used
to construct enrollment request and enrollment response messages.
Section 4 will cover how to build the enrollment request and to construct enrollment request and enrollment response messages.
response messages.
Section 4 will cover how to build the enrollment request and
response messages.
3.1 PKIData Object 3.1 PKIData Object
The new content object PKIData has been defined for this protocol. The new content object PKIData has been defined for this protocol.
This new object is used as the body of the full PKI request message.
The new body is identified by:
id-cct-PKIData ::= {id-pkix id-cct(12) 2 } This new object is used as the body of the full PKI request message.
The ASN.1 structure corresponding to this new content type is: The new body is identified by:
PKIData ::= SEQUENCE id-cct-PKIData ::= {id-pkix id-cct(12) 2 }
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, The ASN.1 structure corresponding to this new content type is:
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes. PKIData ::= SEQUENCE {
The control attributes defined in this document are found in section
5. As control sequences are defined by OIDs, other parties can
define additional control attributes. Unrecognized OIDs MUST result
in no part of the request being successfully processed.
-- reqSequence consists of a sequence of certificate requests. The controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
certificate requests can be either a CertificateRequest (PKCS10
request) or a CertReqMsg. Details on each of these request types
are found in sections 3.3.1 and 3.3.2 respectively.
-- cmsSequence consists of a sequence of [CMS] message objects. reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
This protocol only uses EnvelopedData, SignedData and EncryptedData.
See section 3.6 for more details. cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes.
The control attributes defined in this document are found in section
5. As control sequences are defined by OIDs, other parties can
define additional control attributes. Unrecognized OIDs MUST result
in no part of the request being successfully processed.
-- reqSequence consists of a sequence of requests. The requests can
be a CertificateRequest (PKCS10 request), a CertReqMsg or an
externally defined request (orm). Details on the first two request
types are found in sections 3.3.1 and 3.3.2 respectively. If an
externally defined request message is present, but the server does
not understand the request (or will not process it), a CMCStatus of
noSupport MUST be returned for the request item and no requests
processed.
-- cmsSequence consists of a sequence of [CMS] message objects.
This protocol uses EnvelopedData, SignedData, EncryptedData and
AuthenticatedData. See section 3.6 for more details.
-- otherMsgSequence allows for other arbitrary data items to be
placed into the enrollment protocol. The {OID, any} pair of values
allows for arbitrary definition of material. Data objects are
placed here while control objects are placed in the controlSequence
field. See section 3.7 for more details.
Processing of this object by a recipient is as follows:
1. All control attributes should be examined and processed in an
appropriate manner. The appropriate processing may be either to do
complete processing at this time, ignore the control attribute or to
place the control attribute on a to-do list for later processing.
2. An implicit control attribute is then processed for each item in
the reqSequence. Again this may be either immediate processing or
addition to a to-do list for later processing.
No processing is required for cmsSequence or otherMsgSequence
members of the element. If items are present and are not referenced
by a control sequence, they are to be ignored.
-- otherMsgSequence allows for other arbitrary data items to be
placed into the enrollment protocol. The {OID, any} pair of values
allows for arbitrary definition of material. Data objects are
placed here while control objects are placed in the controlSequence
3.2 ResponseBody Object 3.2 ResponseBody Object
The new content object ResponseBody has been defined for this The new content object ResponseBody has been defined for this
protocol. This new object is used as the body of the full PKI
response message. The new body is identified by:
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } protocol. This new object is used as the body of the full PKI
The ASN.1 structure corresponding to this body content type is: response message. The new body is identified by:
ResponseBody ::= SEQUENCE id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, The ASN.1 structure corresponding to this body content type is:
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- controlSequence consists of a sequence of control attributes. ResponseBody ::= SEQUENCE {
The control attributes defined in this document are found in section
3.5. Other parties can define additional control attributes.
-- cmsSequence consists of a sequence of [CMS] message objects. controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
This protocol only uses EnvelopedData, SignedData and EncryptedData.
See section 3.6 for more details.
-- otherMsgSequence allows for other arbitrary items to be placed cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
into the enrollment protocol. The {OID, any} pair of values allows
for arbitrary definition of material. Data objects are placed here otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
while control objects are placed in the controlSequence field. See
section 3.7 for more details. }
-- controlSequence consists of a sequence of control attributes.
The control attributes defined in this document are found in section
3.5. Other parties can define additional control attributes.
-- cmsSequence consists of a sequence of [CMS] message objects.
This protocol only uses EnvelopedData, SignedData, EncryptedData and
AuthenticatedData. See section 3.6 for more details.
-- otherMsgSequence allows for other arbitrary items to be placed
into the enrollment protocol. The {OID, any} pair of values allows
for arbitrary definition of material. Data objects are placed here
while control objects are placed in the controlSequence field. See
section 3.7 for more details.
Processing of this object by a recipient is as follows:
1. All control attributes should be examined and processed in an
complete processing at this time, ignore the control attribute or to
place the control attribute on a to-do list for later processing.
2. Additional processing of non-element items includes the saving of
certificates and CRLs present in wrapping layers. This type of
processing is based on the consumer of the element and should not be
relied on by generators.
No processing is required for cmsSequence or otherMsgSequence
members of the element. If items are present and are not referenced
by a control sequence, they are to be ignored.
3.3 Certification Requests (PKCS10/CRMF) 3.3 Certification Requests (PKCS10/CRMF)
Certification Requests are based on either PKCS10 or CRMF messages. Certification Requests are based on either PKCS10 or CRMF messages.
Section 3.3.1 specifies mandatory and optional requirements for
clients and servers dealing with PKCS10 request messages. Section Section 3.3.1 specifies mandatory and optional requirements for
3.3.2 specifies mandatory and optional requirements for clients and
servers dealing with CRMF request messages. clients and servers dealing with PKCS10 request messages. Section
3.3.2 specifies mandatory and optional requirements for clients and
servers dealing with CRMF request messages.
All certificate requests directly encoded into a single PKIData
object SHOULD be for the same identity. RAs that batch processing
are expected to place the signed PKIData sequences received into the
cmsSequence of the PKIData object it generates.
3.3.1 PKCS10 Request Body 3.3.1 PKCS10 Request Body
Servers MUST be able to understand and process PKCS10 request Servers MUST be able to understand and process PKCS10 request
bodies. Clients MUST produce a PKCS10 request body when using the
Simple Enrollment Request message. Clients MAY produce a PKCS10
request body when using the Full Enrollment Request message.
When producing a PKCS10 request body, clients MUST produce a PKCS10 bodies. Clients MUST produce a PKCS10 request body when using the
message body containing a subject name and public key. Some
certification products are operated using a central repository of
information to assign subject names upon receipt of a public key for
certification. To accommodate this mode of operation, the subject
name in a CertificationRequest MAY be NULL, but MUST be present.
CAs that receive a CertificationRequest with a NULL subject name MAY
reject such requests. If rejected and a response is returned, the
CA MUST respond with the failInfo attribute of badRequest.
The client MAY incorporate one or more standard X.509 v3 extensions Simple Enrollment Request message. Clients MAY produce a PKCS10
in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq
attribute is defined as
ExtensionReq ::= SEQUENCE OF Extension request body when using the Full Enrollment Request message.
where Extension is imported from [PKIXCERT] and ExtensionReq is When producing a PKCS10 request body, clients MUST produce a PKCS10
identified by {pkcs-9 14}.
Servers MUST be able to process all extensions defined in message body containing a subject name and public key. Some
[PKIXCERT]. Servers are not required to be able to process other V3
X.509 extensions transmitted using this protocol, nor are they certification products are operated using a central repository of
required to be able to process other, private extensions. Servers
are not required to put all client-requested extensions into a information to assign subject names upon receipt of a public key for
certificate. Servers are permitted to modify client-requested
extensions. Servers MUST NOT alter an extension so as to invalidate certification. To accommodate this mode of operation, the subject
the original intent of a client-requested extension. (For example
changing key usage from key exchange to signing.) If a certification name in a CertificationRequest MAY be NULL, but MUST be present.
request is denied due to the inability to handle a requested
extension and a response is returned, the server MUST respond with CAs that receive a CertificationRequest with a NULL subject name MAY
the failInfo attribute of unsupportedExt.
reject such requests. If rejected and a response is returned, the
CA MUST respond with the failInfo attribute of badRequest.
The client MAY incorporate one or more standard X.509 v3 extensions
in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq
attribute is defined as
ExtensionReq ::= SEQUENCE OF Extension
where Extension is imported from [PKIXCERT] and ExtensionReq is
identified by {pkcs-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 V3 X.509 extensions transmitted using this protocol,
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 key exchange to
signing.) If a certification request is denied due to the inability
to handle a requested extension and a response is returned, the
server MUST respond with the failInfo attribute of unsupportedExt.
3.3.2 CRMF Request Body 3.3.2 CRMF Request Body
Servers MUST be able to understand and process CRMF request body. Servers MUST be able to understand and process CRMF request body.
Clients MAY produce a CRMF message body when using the Full
Enrollment Request message.
This memo imposes the following additional changes on the Clients MAY produce a CRMF message body when using the Full
construction and processing of CRMF messages:
- When CRMF message bodies are used in the Full Enrollment Request Enrollment Request message.
message, each CRMF message MUST include both the subject and
publicKey fields in the CertTemplate. As in the case of PKCS10
requests, the subject may be encoded as NULL, but MUST be present.
- In general, when both CRMF and CMC controls exist with equivalent
functionality, the CMC control SHOULD be used. The CMC control MUST
override any CRMF control.
- The regInfo field MUST NOT be used on a CRMF message. Equivalent
functionality is provided in the regInfo control attribute (section
5.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 instead if POP is desired.
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 This memo imposes the following additional changes on the
client in the certificate template. Servers MUST be able to process
all extensions defined in [PXIXCERT]. Servers are not required to construction and processing of CRMF messages:
be able to process other V3 X.509 extension transmitted using this
protocol, nor are they required to be able to process other, private - When CRMF message bodies are used in the Full Enrollment Request
extensions. Servers are permitted to modify client-requested
the original intent of a client-requested extension. (For example message, each CRMF message MUST include both the subject and
change key usage from key exchange to signing.) If a certificate
request is denied due to the inability to handle a requested publicKey fields in the CertTemplate. As in the case of PKCS10
extension, the server MUST respond with a failInfo attribute of
unsupportedExt. requests, the subject may 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 message. Equivalent
functionality is provided in the regInfo control attribute (section
5.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 instead if POP is desired.
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 certificate template. Servers MUST be able to process
all extensions defined, but not prohibited in [PXIXCERT]. Servers
are not required to be able to process other V3 X.509 extension
transmitted using this protocol, nor are they required to be able to
process other, 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 key exchange to
signing.) If a certificate request is denied due to the inability
to handle a requested extension, the server MUST respond with a
failInfo attribute of unsupportedExt.
3.3.3 Production of Diffie-Hellman Public Key Certification Requests 3.3.3 Production of Diffie-Hellman Public Key Certification Requests
Part of a certification request is a signature over the request; Part of a certification request is a signature over the request;
Diffie-Hellman is a key agreement algorithm and cannot be used to
directly produce the required signature object. [DH-POP] provides Diffie-Hellman is a key agreement algorithm and cannot be used to
two ways to produce the necessary signature value. This document
also defines a signature algorithm that does not provide a POP directly produce the required signature object. [DH-POP] provides
value, but can be used to produce the necessary signature value. also defines a signature algorithm that does not provide a POP
value, but can be used to produce the necessary signature value.
3.3.3.1 No-Signature Signature Mechanism 3.3.3.1 No-Signature Signature Mechanism
Key management (encryption/decryption) private keys cannot always be Key management (encryption/decryption) private keys cannot always be
used to produce some type of signature value as they can be in a
decrypt only device. Certification requests require that the
signature field be populated. This section provides a signature
algorithm specifically for that purposes. The following object
identifier and signature value are used to identify this signature
type:
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} used to produce some type of signature value as they can be in a
NoSignatureValue ::= OCTET STRING decrypt only device. Certification requests require that the
The parameters for id-alg-noSignature MUST be present and MUST be signature field be populated. This section provides a signature
encoded as NULL. NoSignatureValue contains the hash of the
certification request. It is important to realize that there is no
security associated with this signature type. If this signature
type is on a certification request and the Certification Authority
policy requires proof-of-possession of the private key, the POP
mechanism defined in section 5.7 MUST be used.
3.3.3.2 Diffie-Hellman POP Signature algorithm specifically for that purposes. The following object
CMC compliant implementations MUST support section 5 of [DH-POP]. 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 hash of the
certification request. It is important to realize that there is no
security associated with this signature type. If this signature
type is on a certification request and the Certification Authority
policy requires proof-of-possession of the private key, the POP
mechanism defined in section 5.7 MUST be used.
3.3.3.2 Diffie-Hellman POP Discrete Logarithm Signature
CMC compliant implementations MUST support section 4 of [DH-POP].
3.3.3.3 Diffie-Hellman MAC signature 3.3.3.3 Diffie-Hellman MAC signature
CMC compliant implementations MAY support section 4 of [DH-POP]. CMC compliant implementations MAY support section 3 of [DH-POP].
3.4 Body Part Identifiers 3.4 Body Part Identifiers
Each element of a PKIData or PKIResponse message has an associated Each element of a PKIData or PKIResponse message has an associated
body part identifier. The Body Part Identifier is a 4-octet integer
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 object. Body Part Identifiers can be duplicated in
different layers (for example a CMC message embedded within
another). The Body Part Id of zero is reserved to designate the
such as the Add Extensions Control in the pkiDataReference field to
refer to a request in the current PKIData object.
Some control attribute, such as the CMC Status Info attribute, will body part identifier. The Body Part Identifier is a 4-octet integer
also use Body Part Identifiers to refer to elements in the previous
message. This allows an error to be explicit about the attribute or encoded in the certReqIds field for CertReqMsg objects (in a
request to which the error applies.
TaggedRequest) or in the bodyPartId field of the other objects. The
Body Part Identifier MUST be unique within a single PKIData or
PKIResponse object. Body Part Identifiers can be duplicated in
different layers (for example a CMC message embedded within
another). The Body Part Id of zero is reserved to designate the
current PKIData object. This value is used in control attributes
such as the Add Extensions Control in the pkiDataReference field to
refer to a request in the current PKIData object.
Some control attribute, such as the CMC Status Info attribute, will
also use Body Part Identifiers to refer to elements in the previous
message. This allows an error to be explicit about the attribute or
request to which the error applies.
3.5 Control Attributes 3.5 Control Attributes
The overall control flow of how a message is processed in this The overall control flow of how a message is processed in this
document is based on the control attributes. Each control attribute consists of an object identifier and a value based on the object
consists of an object identifier and a value based on the object
identifier.
Servers MUST fail the processing of an entire PKIData message if any identifier.
included control attribute is not recognized. The response MUST be
the error badRequest and bodyList MUST contain the bodyPartID of the
invalid or unrecognized control attribute.
The syntax of a control attribute is Servers MUST fail the processing of an entire PKIData message if any
TaggedAttribute ::= SEQUENCE included control attribute is not recognized. The response MUST be
bodyPartID BodyPartId, the error badRequest and bodyList MUST contain the bodyPartID of the
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
-- bodyPartId is a unique integer that is used to reference this invalid or unrecognized control attribute(s).
control attribute. The id of 0 is reserved for use as the reference
to the current PKIData object.
-- attrType is the OID defining the associated data in attrValues The syntax of a control attribute is
-- attrValues contains the set of data values used in processing TaggedAttribute ::= SEQUENCE {
the control attribute.
The set of control attributes that are defined by this memo are bodyPartID BodyPartId,
found in section 5.
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
-- bodyPartId is a unique integer that is used to reference this
control attribute. The id of 0 is reserved for use as the reference
to the current PKIData object.
-- attrType is the OID defining the associated data in attrValues
-- attrValues contains the set of data values used in processing
the control attribute.
The set of control attributes that are defined by this memo are
found in section 5.
3.6 Content Info objects 3.6 Content Info objects
The cmsSequence field of the PKIRequest and PKIResponse messages The cmsSequence field of the PKIRequest and PKIResponse messages
contains zero or more tagged content info objects. The syntax for
this structure is
TaggedContentInfo ::= SEQUENCE contains zero or more tagged content info objects. The syntax for
bodyPartID BodyPartId, this structure is
contentInfo ContentInfo
}
-- bodyPartId is a unique integer that is used to reference this TaggedContentInfo ::= SEQUENCE {
content info object. The id of 0 is reserved for use as the
reference to the current PKIData object.
-- contentInfo contains a ContentInfo object (defined in [CMS]). bodyPartID BodyPartId,
The three contents used in this location are SignedData,
EnvelopedData and Data.
EnvelopedData provides for shrouding of data. Data allows for contentInfo ContentInfo
general transport of unstructured data.
The SignedData object from [CMS] is also used in this specification }
to provide for authentication as well as serving as the general
transport wrapper of requests and responses. -- bodyPartId is a unique integer that is used to reference this
content info object. The id of 0 is reserved for use as the
reference to the current PKIData object.
-- contentInfo contains a ContentInfo object (defined in [CMS]).
The three contents used in this location are SignedData,
EnvelopedData and Data.
EnvelopedData provides for shrouding of data. Data allows for
general transport of unstructured data.
The SignedData object from [CMS] is also used in this specification
to provide for authentication as well as serving as the general
transport wrapper of requests and responses.
3.6.1 Signed Data 3.6.1 Signed Data
The signedData object is used in two different locations when
The signedData object is used in two different locations when constructing enrollment messages. The signedData object is used as
constructing enrollment messages. The signedData object is used as
a wrapper for a PKIData as part of the enrollment request message.
The signedData object is also used as the outer part of an
enrollment response message. If the signature on a signedData
object fails to verify, the response should be a CMCFailInfo with a
value of badMessageCheck and a bodyPart of 0.
For the enrollment response the signedData wrapper allows the server a wrapper for a PKIData as part of the enrollment request message.
to sign the returning data, if any exists, and to carry the
certificates and CRLs for the enrollment request. If no data is The signedData object is also used as the outer part of an
being returned beyond the certificates, no signerInfo objects are
placed in the signedData object. enrollment response message.
As part of processing a message the signature(s) MUST be verified.
If the signature does not verify, and the body contains anything
other than a status response, a new message containing a status
response MUST be returned using a CMCFailInfo with a value of
badMessageCheck and a bodyPart of 0.
For the enrollment response the signedData wrapper allows the server
to sign the returning data, if any exists, and to carry the
certificates and CRLs for the enrollment request. If no data is
being returned beyond the certificates, no signerInfo objects are
placed in the signedData object.
3.6.2 Enveloped Data 3.6.2 Enveloped Data
EnvelopedData is the primary method of providing confidentiality for EnvelopedData is the primary method of providing confidentiality for
sensitive information in this protocol. The protocol currently uses
EnvelopedData to provide encryption of an entire request (see
section 4.5). The envelopedData object would also be used to wrap
private key material for key archival. If the decryption on an
envelopedData failes, the response is a CMCFailInfo with a value of
badMessageCheck and a bodyPart of 0.
Servers MUST implement envelopedData according to [CMS]. There is sensitive information in this protocol. The protocol currently uses
an ambiguity (about encrypting content types other than id-data) in
the PKCS7 specification that has lead to non-interoperability. EnvelopedData to provide encryption of an entire request (see
section 4.5). The envelopedData object would also be used to wrap
private key material for key archival. If the decryption on an
envelopedData failes, the response is a CMCFailInfo with a value of
badMessageCheck and a bodyPart of 0.
Servers MUST implement envelopedData according to [CMS]. There is
an ambiguity (about encrypting content types other than id-data) in
the PKCS7 specification that has lead to non-interoperability.
3.6.3 Authenticated Data
AuthenticatedData is used for providing origination authentication
in those circumstances where a shared-secret exists, but a PKI trust
anchor has not yet been established. This is currently only used
for the publishAutenticatedData control (section 5.2.16). This
control is uses the PKIData body so that new controls with
additional policy type information could be included as well.
3.7 Other Message Bodies 3.7 Other Message Bodies
The other message body portion of the message allows for arbitrary The other message body portion of the message allows for arbitrary
data objects to be carried as part of a message. This is intended
to contain data that is not already wrapped in a CMS contentInfo
object. The data is ignored unless a control attribute references
the data by bodyPartId.
OtherMsg ::= SEQUENCE data objects to be carried as part of a message. This is intended
bodyPartID BodyPartID, to contain data that is not already wrapped in a CMS contentInfo
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- bodyPartID contains the unique id of this object object. The data is ignored unless a control attribute references
-- otherMsgType contains the OID defining both the usage of this
body part and the syntax of the value associated with this body part
-- otherMsgValue contains the data associated with the message body the data by bodyPartId.
part.
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- bodyPartID contains the unique id of this object
-- otherMsgType contains the OID defining both the usage of this
body part and the syntax of the value associated with this body part
-- otherMsgValue contains the data associated with the message body
part.
3.8 Unsigned Attributes
There is sometimes a need to include data in an enrollment message
designed to be removed 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 the fact that every RA which
encapsulates this information needs to move the data so that it is
not covered by the RA signature. (A client request, encapsulated by
an RA cannot have the unsigned attribute removed by the key archive
agent without breaking the RA's signature.) This attribute
addresses that problem.
This attribute is used to contain the information that is not
directly signed by a user. When an RA finds a message that has this
attribute in the unsigned or unauthenticated attribute fields of the
CMS objects it is aggregating, they are removed from the embedded
CMS objects and propagated up to the RA CMS object.
id-cmc-UnsignedData OBJECT IDENTIFIER ::= {<TBD>}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
There MUST be at most one CMCUnsignedData attribute in the
UnsignedAttribute sequence of a SignerInfo structure. If the
attribute appears in one SignerInfo in a sequence, it MUST appear
the same in all SignerInfo items and MUST have the same value.
4. PKI Messages 4. PKI Messages
This section discusses the details of putting together the different This section discusses the details of putting together the different
enrollment request and response messages.
enrollment request and response messages.
4.1 Simple Enrollment Request 4.1 Simple Enrollment Request
The simplest form of an enrollment request is a plain PKCS10 The simplest form of an enrollment request is a plain PKCS10
message. If this form of enrollment request is used for a private
key that is capable of generating a signature, the PKCS10 MUST be
signed with that private key. If this form of the enrollment
request is used for a D-H key, then the D-H POP mechanism described
in [DH-POP] MUST be used.
Servers MUST support the Simple Enrollment Request message. If the message. If this form of enrollment request is used for a private
Simple Enrollment Request message is used, servers MUST return the
Simple Enrollment Response message (see Section 4.3) if the
enrollment request is granted. If the enrollment request fails, the
Full Enrollment Response MAY be returned or no response MAY be
returned.
The Simple Enrollment Request message MUST NOT be used if a proof- key that is capable of generating a signature, the PKCS10 MUST be
of-identity needs to be included.
Many advanced services specified in this memo are not supported by signed with that private key. If this form of the enrollment
the Simple Enrollment Request message.
request is used for a D-H key, then the D-H POP mechanism described
in [DH-POP] MUST be used.
Servers MUST support the Simple Enrollment Request message. If the
Simple Enrollment Request message is used, servers MUST return the
Simple Enrollment Response message (see Section 4.3) if the
Full Enrollment Response MAY be returned or no response MAY be
returned.
The Simple Enrollment Request message MUST NOT be used if a proof-
of-identity needs to be included.
Many advanced services specified in this memo are not supported by
the Simple Enrollment Request message.
4.2 Full PKI Request 4.2 Full PKI Request
The Full Enrollment Request provides the most functionality and The Full Enrollment Request provides the most functionality and
flexibility. Clients SHOULD use the Full Enrollment Request message
when enrolling. Servers MUST support the Full Enrollment Request
message. An enrollment response (full or simple as appropriate)
MUST be returned to all Full Enrollment Requests.
The Full Enrollment Request message consists of a PKIData object flexibility. Clients SHOULD use the Full Enrollment Request message
wrapped in a signedData CMS object. The objects in the PKIData are
ordered as follows:
1. All Control Attributes, when enrolling. Servers MUST support the Full Enrollment Request
2. All certification requests,
3. All CMS objects,
4. All other messages.
Each element object in the PKIData sequencein a Full Enrollment message. An enrollment response (full or simple as appropriate)
Request is identified by a Body Part Identifier. If duplicate ids
are found, the server MUST return the error badRequest with a
bodyPartID of 0.
The signedData object wrapping the PKIData may be signed either by MUST be returned to all Full Enrollment Requests.
the private key material of the signature certification request, or
by a previously certified signature key. If the private key of a
signature certification request is being used, then:
a) the certification request containing the corresponding public key
MUST include a Subject Key Identifier extension request,
b) the subjectKeyIdentifier form of signerInfo MUST be used, and
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 The Full Enrollment Request message consists of a PKIData object
certificates have yet been issued for the signing key.) If the
request key is used for signing, there MUST be only one signerInfo
object in the signedData object.
When creating a message to renew a certificate, the following should wrapped in a signedData CMS object. The objects in the PKIData are
be taken into consideration:
1. The identification and identityProof control statements are not ordered as follows:
required. The same information is provided by the use of an
existing certificate from the CA when signing the enrollment 1. All Control Attributes,
message.
2. CAs and LRAs may impose additional restrictions on the signing 2. All certification requests,
certificate used. They may require that the most recently issued
signing certificate for an entity be used. 3. All CMS objects,
3. A renewal message may occur either by creating a new set of keys,
or by re-using an existing set of keys. Some CAs may prevent re-use 4. All other messages.
of keys by policy. In this case the CA MUST return NOKEYREUSE as
the failure code. Each object in the PKIData sequence is identified by a Body Part
Identifier. If duplicate ids are found, the server MUST return the
error badRequest with a bodyPartID of 0.
The signedData object wrapping the PKIData may be signed either by
the private key material of the signature certification request, or
by a previously certified signature key. If the private key of a
signature certification request is being used, then:
a) the certification request containing the corresponding public key
MUST include a Subject Key Identifier extension,
b) the subjectKeyIdentifier form of signerInfo MUST be used, and
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
object in the signedData object.
When creating a message to renew a certificate, the following should
be taken into consideration:
1. The identification and identityProof control statements are not
required. The same information is provided by the use of an
existing certificate from the CA when signing the enrollment
message.
2. CAs and LRAs may impose additional restrictions on the signing
certificate used. They may require that the most recently issued
3. A renewal message may occur either by creating a new set of keys,
or by re-using an existing set of keys. Some CAs may prevent re-use
of keys by policy. In this case the CA MUST return NOKEYREUSE as
the failure code.
4.3 Simple Enrollment Response 4.3 Simple Enrollment Response
Servers SHOULD use the simple enrollment response message whenever Servers SHOULD use the simple enrollment response message whenever
possible. Clients MUST be able to process the simple enrollment
response message. The simple enrollment response message consists
of a signedData object with no signerInfo objects on it. The
certificates requested are returned in the certificate bag of the
signedData object.
Clients MUST NOT assume the certificates are in any order. Servers possible. Clients MUST be able to process the simple enrollment
SHOULD include all intermediate certificates needed to form complete
chains to one or more self-signed certificates, not just the newly response message. The simple enrollment response message consists
issued certificate(s). The server MAY additionally return CRLs in
the CRL bag. Servers MAY include the self-signed certificates. of a signedData object with no signerInfo objects on it. The
Clients MUST NOT implicitly trust included self-signed
certificate(s) merely due to its presence in the certificate bag. In certificates requested are returned in the certificate bag of the
the event clients receive a new self-signed certificate from the
server, clients SHOULD provide a mechanism to enable the user to signedData object.
explicitly trust the certificate.
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 self-signed certificates, 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
explicitly trust the certificate.
4.4 Full PKI Response 4.4 Full PKI Response
Servers MUST return full PKI response messages if a) a full PKI Servers MUST return full PKI response messages if a) a full PKI
request message failed or b) additional services other than
responses with failure information for simple PKI requests.
Following section 4.3 above, servers returning only certificates and
a success status to the client SHOULD use the simple PKI response
message.
Clients MUST be able to process a full PKI response message. request message failed or b) additional services other than
The full enrollment response message consists of a signedData object returning certificates are required. Servers MAY return full PKI
encapsulating a responseBody object. In a responseBody object all
Control Attributes MUST precede all CMS objects. The certificates
granted in an enrollment response are returned in the certificates
field of the immediately encapsulating signedData object.
Clients MUST NOT assume the certificates are in any order. Servers responses with failure information for simple PKI requests.
SHOULD include all intermediate certificates needed to form complete
chains one ore more self-signed certificates, 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
explicitly trust the certificate.
4.5 Application of Encryption to a PKI Message Following section 4.3 above, servers returning only certificates and
There are occasions where a PKI request or response message must be a success status to the client SHOULD use the simple PKI response
encrypted in order to prevent any information about the enrollment
from being accessible to unauthorized entities. This section
describes the means used to encrypt a PKI message. This section is
not applicable to a simple enrollment message.
Confidentiality is provided by wrapping the PKI message (a message.
signedData object) in a CMS EnvelopedData object. 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 objects. It is recommended that if an
enveloped data layer is applied to a PKI message, a second signing
layer be placed outside of the enveloped data layer. The following
figure shows how this nesting would be done:
Normal Option 1 Option 2 Clients MUST be able to process a full PKI response message.
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData
Options 1 and 2 provide the benefit of preventing leakage of The full enrollment response message consists of a signedData object
sensitive data by encrypting the information. LRAs can remove the
enveloped data wrapping, and replace or forward without further
processing. Section 6 contains more information about LRA
processing.
PKI Messages MAY be encrypted or transmitted in the clear. Servers encapsulating a responseBody object. In a responseBody object all
MUST provided support for all three versions.
Alternatively, an authenticated, secure channel could exist between Control Attributes MUST precede all CMS objects. The certificates
the parties requiring encryption. Clients and servers MAY use such
channels instead of the technique described above to provide secure,
private communication of PKI request and response messages.
5. Control Attributes granted in an enrollment response are returned in the certificates
Control attributes are carried as part of both PKI requests and field of the immediately encapsulating signedData object.
responses. Each control attribute is encoded as a unique Object
Identifier followed by that data for the control attribute. The
encoding of the data is based on the control attribute object
identifier. Processing systems would first detect the OID and
process the corresponding attribute value prior to processing the
message body.
The following table lists the names, OID and syntactic structure for Clients MUST NOT assume the certificates are in any order. Servers
each of the control attributes documented in this memo.
Control Attribute OID Syntax SHOULD include all intermediate certificates needed to form complete
----------------- ---------- --------------
cMCStatusInfo id-cmc 1 CMCStatusInfo
identification id-cmc 2 UTF8String
identityProof id-cmc 3 OCTET STRING
dataReturn id-cmc 4 OCTET STRING
transactionId id-cmc 5 INTEGER
senderNonce id-cmc 6 OCTET STRING
recipientNonce id-cmc 7 OCTET STRING
addExtensions id-cmc 8 AddExtensions
encryptedPOP id-cmc 9 EncryptedPOP
decryptedPOP id-cmc 10 DecryptedPOP
lraPOPWitness id-cmc 11 LraPOPWitness
getCert id-cmc 15 GetCert
getCRL id-cmc 16 GetCRL
revokeRequest id-cmc 17 RevokeRequest
regInfo id-cmc 18 OCTET STRING
responseInfo id-cmc 19 OCTET STRING
QueryPending id-cmc 21 OCTET STRING
idPOPLinkRandom id-cmc 22 OCTET STRING
idPOPLinkWitness id-cmc 23 OCTET STRING
idConfirmCertAcceptance id-cmc 24 CMCCertId
cmcStatusInfoExt id-cmc XX CMCStatusInfoExt
5.1 CMC Status Info Control Attributes chains one ore more self-signed certificates, not just the newly
The CMC status info control is used in full PKI Response messages to issued certificate(s). The server MAY additionally return CRLs in
return information about the processing of a client request. Two
controls are described in this section. The first is the preferred
control, the second is included for backwards compatibility with RFC
2797.
Servers MAY emit multiple CMC status info controls referring to a the CRL bag. Servers MAY include the self-signed certificates.
single body part. Clients MUST be able to deal with multiple CMC
CMCStatusInfoExt control, but MAY additionally use the CMCStatusInfo
attribute. Clients MUST be able to process the CMCStatusInfoExt
control.
5.1.1 Extended CMC Status Info Control Attribute Clients MUST NOT implicitly trust included self-signed
This control uses the following ASN.1 definition: certificate(s) merely due to its presence in the certificate bag. In
CMCStatusInfoExt ::= SEQUENCE the event clients receive a new self-signed certificate from the
CMCStatus CMCStatus, server, clients SHOULD provide a mechanism to enable the user to
BodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
StatusString UTF8String OPTIONAL,
OtherInfo CHOICE
FailInfo CMCFailInfo, explicitly trust the certificate.
PendInfo PendInfo,
ExtendedFailInfo SEQUENCE
FailInfoOID OBJECT IDENTIFIER, 4.5 Application of Encryption to a PKI Message
FailInfoValue AttributeValue There are occasions where a PKI request or response message must be
}
}
}
BodyPartReference ::= CHOICE encrypted in order to prevent any information about the enrollment
BodyPartID BodyPartID, from being accessible to unauthorized entities. This section
BodyPartPath SEQUENCE SIZE (2..MAX) OF BodyPartID
}
PendInfo ::= SEQUENCE describes the means used to encrypt a PKI message. This section is
pendToken OCTET STRING, not applicable to a simple enrollment message.
pendTime GeneralizedTime
}
-- cMCStatus is described in section 5.1.3 Confidentiality is provided by wrapping the PKI message (a
-- bodyList contains the list of references to body parts in signedData object) in a CMS EnvelopedData object. The nested
the request message to which this status information applies. If an
error is being returned for a simple enrollment message, body list
will contain a single integer of value '1'.
-- statusString contains a string with additional description content type in the EnvelopedData is id-signedData. Note that this
information. This string is human readable.
-- failInfo is described in section 5.1.4. It provides a is different from S/MIME where there is a MIME layer placed between
detailed error on what the failure was. This choice is present only
if cMCStatus is failed.
-- extendedFailInfo is provided for other users of the the encrypted and signed data objects. It is recommended that if an
enrollment protocol to provided their own error codes. This choice
is present only if cMCStatus is failed.
-- pendToken is the token to be used in the queryPending enveloped data layer is applied to a PKI message, a second signing
control attribute.
-- pendTime contains the suggested time the server wants to be layer be placed outside of the enveloped data layer. The following
If the cMCStatus field is success, the CMC Status Info Control MAY
be omitted unless it is only item in the response message. If no
status exists for a certificate request or other item requiring
processing, then the value of success is to be assumed.
5.1.2 CMC Status Info Control Attribute figure shows how this nesting would be done:
The CMC status info control is used in full PKI Response messages to Normal Option 1 Option 2
return information on a client request. 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
response message. This statement uses the following ASN.1
definition:
CMCStatusInfo ::= SEQUENCE ------ -------- --------
cMCStatus CMCStatus, SignedData EnvelopedData SignedData
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE
failInfo CMCFailInfo, PKIData SignedData EnvelopedData
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE PKIData SignedData
pendToken OCTET STRING, PKIData
pendTime GeneralizedTime
}
-- cMCStatus is described in section 5.1.31 Options 1 and 2 provide the benefit of preventing leakage of
-- bodyList contains the list of body parts in the request sensitive data by encrypting the information. LRAs can remove the
message to which this status information applies. If an error is
being returned for a simple enrollment message, body list will
contain a single integer of value '1'.
-- statusString contains a string with additional description enveloped data wrapping, and replace or forward without further
information. This string is human readable.
-- failInfo is described in section 5.1.42. It provides a processing. Section 6 contains more information about LRA
detailed error on what the failure was. This choice is present only
if cMCStatus is failed.
-- pendToken is the token to be used in the queryPending control processing.
attribute.
-- pendTime contains the suggested time the server wants to be PKI Messages MAY be encrypted or transmitted in the clear. Servers
queried about the status of the request.
If the cMCStatus field is success, the CMC Status Info Control MAY MUST provided support for all three versions.
be omitted unless it is only item in the response message. If no
status exists for a certificate request or other item requiring
processing, then the value of success is to be assumed.
5.1.31 CMCStatus values Alternatively, an authenticated, secure channel could exist between
CMCStatus is a field in the CMCStatusInfo structure. This field
contains a code representing the success or failure of a specific
operation. CMCStatus has the ASN.1 structure of:
CMCStatus ::= INTEGER the parties requiring encryption. Clients and servers MAY use such
success (0), channels instead of the technique described above to provide secure,
-- request was granted
-- reserved (1),
-- not used, defined where the original structure was
defined
failed (2),
-- you don't get what you want, more information elsewhere
in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
-- pending may only be return for certificate request
operations.
noSupport (4),
-- the requested operation is not supported
confirmRequired (5)
-- conformation using the idConfirmCertAcceptance control is
required
-- before use of certificate
}
5.1.42 CMCFailInfo private communication of PKI request and response messages.
CMCFailInfo conveys information relevant to the interpretation of a 5. Control Attributes
failure condition. The CMCFailInfo has the following ASN.1
structure:
CMCFailInfo ::= INTEGER Control attributes are carried as part of both PKI requests and
badAlg (0) responses. Each control attribute is encoded as a unique Object
-- Unrecognized or unsupported algorithm
badMessageCheck (1)
-- integrity check failed
badRequest (2)
-- transaction not permitted or supported
badTime (3)
-- Message time field was not sufficiently close to the
system time
badCertId (4)
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5)
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6)
-- Private key material must be supplied
badIdentity (7)
-- Identification Attribute failed to verify
popRequired (8)
-- Server requires a POP proof before issuing certificate
popFailed (9)
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
Additional failure reasons MAY be defined for closed environments Identifier followed by that data for the control attribute. The
with a need.
5.2 Identification and IdentityProof Control Attributes encoding of the data is based on the control attribute object
Some CAs and LRAs require that a proof of identity be included in a identifier. Processing systems would first detect the OID and
certification request. Many different ways of doing this exist with
different degrees of security and reliability. Most people are
familiar with the request of a bank to provide your mother's maiden
name as a form of identity proof.
CMC provides one method of proving the client's identity based on a process the corresponding attribute value prior to processing the
shared secret between the certificate requestor and the verifying
authority. If clients support full request messages, clients MUST
implement this method of identity proof. Servers MUST provide this
method and MAY also have a bilateral method of similar strength
available.
The CMC method starts with an out-of-band transfer of a token (the message body.
shared secret). The shared-secret should be generated in a random
manner. The distribution of this token is beyond the scope of this
document. The client then uses this token for an identity proof as
follows:
1. The reqSequence field of the PKIData object (encoded exactly as The following table lists the names, OID and syntactic structure for
it appears in the request message including the sequence type and
length) is the value to be validated.
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the value produced in
Step 1, as described in [HMAC], using the hash of the token from
Step 2 as the shared secret value.
4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the
value of the identityProof attribute.
When the server verifies the identityProof attribute, it computes each of the control attributes documented in this memo.
the HMAC-SHA1 value in the same way and compares it to the
identityProof attribute contained in the enrollment request.
If a server fails the verification of an identityProof attribute and Control Attribute OID Syntax
the server returns a response message, the failInfo attribute MUST
be present in the response and MUST have a value of badIdentity.
Reuse of the shared-secret on enrollment retries makes it easier for
the client and to prevent getting out of sync. However, reuse of
the shared-secret can potentially open the door for some types of
attacks.
Optionally, servers MAY require the inclusion of the unprotected ----------------- ---------- --------------
identification attribute with an identification attribute. The
identification attribute is intended to contain either a text string
server in locating the shared secret needed to validate the contents
of the identityProof attribute. Numeric values MUST be converted to
text string representations prior to encoding as UTF8-STRINGs in
this attribute. If the identification control attribute is included
in the message, the derivation of the shared secret in step 2 is
altered so that the hash of the concatenation of the token and the
identity value are hashed rather than just the token.
5.2.1 Hardware Shared Secret Token Generation cMCStatusInfo id-cmc 1 CMCStatusInfo
The shared secret between the end-entity and the identity verify is identification id-cmc 2 UTF8String
sometimes transferred using a hardware device that generates a
series of tokens based on some shared secret value. The user 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 attribute MUST be included and MUST contain identityProof id-cmc 3 OCTET STRING
the hardware-generated token. transactionId id-cmc 5 INTEGER
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.
5.3 Linking Identity and POP Information senderNonce id-cmc 6 OCTET STRING
In a PKI Full Request message identity information about the recipientNonce id-cmc 7 OCTET STRING
creator/author of the message is carried in the signature of the CMS
SignedData object containing all of the certificate requests. Proof-
of-possession information for key pairs requesting certification,
however, is carried separately for each PKCS#10 or CRMF message.
(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 5.7 below are
used.) In order to prevent substitution-style attacks we 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 addExtensions id-cmc 8 AddExtensions
information: witness values cryptographically derived from the
shared-secret (Section 5.3.1) and shared-secret/subject DN matching
(Section 5.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 certificate request that can be directly associated with
the shared-secret; this will defeat attempts to include certificate
requests from different entities in a single Full PKI Request
message.
5.3.1 Witness values derived from the shared-secret encryptedPOP id-cmc 9 EncryptedPOP
The first technique for doing identity-POP linking works by forcing decryptedPOP id-cmc 10 DecryptedPOP
derived from the shared-secret token as a signed extension within
each certificate request (PKCS#10 or CRMF) message. 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 token 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 lraPOPWitness id-cmc 11 LraPOPWitness
least 512 bits in length.
2. A SHA1 hash of the token is computed.
3. An HMAC-SHA1 value is then computed over the random value
produced in Step 1, as described in [HMAC], using the hash of the
token from Step 2 as the shared secret.
4. The random value produced in Step 1 is encoded as the value of an
idPOPLinkRandom control attribute. This control attribute MUST be
included in the Full PKI Request message.
5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value
of an idPOPLinkWitness extension to the certificate request.
a. For CRMF, idPOPLinkWitness is included in the controls section
of the CertRequest structure.
b. For PKCS#10, idPOPLinkWitness is included in the attributes
section of the CertificationRequest structure.
Upon receipt, servers MUST verify that each certificate request getCert id-cmc 15 GetCert
contains a copy of the idPOPLinkWitness and that its value was
derived in the specified manner from the shared secret and the
random string included in the idPOPLinkRandom control attribute.
5.3.2 Shared-secret/subject DN matching getCRL id-cmc 16 GetCRL
The second technique for doing identity-POP linking is to link a revokeRequest id-cmc 17 RevokeRequest
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 certificate request. It is expected that many client-
server connections using shared-secret based proof-of-identity will
use this mechanism. (It is common not to omit the subject DN
information from the certificate request messages.)
When the shared secret is generated and transferred out-of-band to regInfo id-cmc 18 OCTET STRING
initiate the registration process (Section 5.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 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 message, it MUST use these two pieces
of information as follows:
1. The client MUST include the specific subject DN that it received responseInfo id-cmc 19 OCTET STRING
along with the shared secret as the subject name in every
certificate request (PKCS#10 and/or CRMF) in the Full PKI Request.
2. The client MUST include the identityProof control attribute QueryPending id-cmc 21 OCTET STRING
(Section 5.2), derived from the shared secret, in the Full PKI
Request.
The server receiving this message MUST (a) validate the idPOPLinkRandom id-cmc 22 OCTET STRING
identityProof control attribute and then, (b) check that the subject
DN included in each certificate request matches that associated with
the shared secret. If either of these checks fails the certificate
request MUST be rejected.
5.3.3 Renewal and Re-Key Messages idPOPLinkWitness id-cmc 23 OCTET STRING
In a renewal or re-key message, the subject DN in (a) the idConfirmCertAcceptance id-cmc 24 CMCCertId
certificate referenced by the CMS SignerInfo object, and (b) all
certificate requests within the request message MUST match according
to the standard name match rules described in [PKIXCERT].
5.4 Data Return Control Attribute cmcStatusInfoExt id-cmc XX CMCStatusInfoExt
The data return control attribute allows clients to send arbitrary publishTrustRoot id-cmc XX CertificateSequence
data (usually some type of internal state information) to the server
and to have the data returned as part of the enrollment response
message. Data placed in a data return statement is considered to be
opaque to the server. The same control is used for both requests
and responses. If the data return statement appears in an
enrollment message, the server MUST return it as part of the
enrollment response message.
In the event that the information in the data return statement needs publishAuthenticatedData id-cmc XX AuthPublish
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.
An example of using this feature is for a client to place an batchRequests id-cmc XX BodyPartList
identifier marking the exact source of the private key material.
This might be the identifier of a hardware device containing the
private key.
5.5 Add Extensions Control Attribute batchResponses id-cmc XX BodyPartList
The Add Extensions control attribute is used by LRAs in order to 5.1 CMC Status Info Control Attributes
specify additional extensions that are to be placed on certificates.
This attribute uses the following ASN.1 definition:
AddExtensions ::= SEQUENCE The CMC status info control is used in full PKI Response messages to
pkiDataReference BodyPartID return information about the processing of a client request. Two
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
-- pkiDataReference field contains the body part id of the controls are described in this section. The first is the preferred
embedded request message.
-- certReferences field is a list of references to one or more of control, the second is included for backwards compatibility with RFC
certReferences sequence MUST be equal to either the bodyPartID of a
TaggedCertificationRequest or the certReqId of the CertRequest
within a CertReqMsg. By definition, the listed extensions are to
be applied to every element referenced in the certReferences
sequence. If a request corresponding to bodyPartID cannot be found,
the error badRequest is returned referencing this control attribute.
-- extensions field contains the sequence of extensions to be 2797.
applied to the referenced certificate requests.
Servers MUST be able to process all extensions defined in Servers MAY emit multiple CMC status info controls referring to a
[PKIXCERT]. Servers are not required to be able to process every V3
X.509 extension transmitted using this protocol, nor are they
required to be able to process other, private extensions. Servers
are not required to put all LRA-requested extensions into a
certificate. Servers are permitted to modify LRA-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
failInfo attribute with the value of unsupportedExt.
If multiple Add Extensions statements exist in an enrollment single body part. Clients MUST be able to deal with multiple CMC
message, the exact behavior is left up to the certificate issuer
policy. However it is recommended that the following policy be used.
These rules would be applied to individual extensions within an Add
Extensions control attribute (as opposed to an "all or nothing"
approach).
1. If the conflict is within a single PKIData object, the status info controls in a response message. Servers MUST use the
certificate request would be rejected with an error of
badRequest.
2. If the conflict is between different PKIData objects, the CMCStatusInfoExt control, but MAY additionally use the CMCStatusInfo
outermost version of the extension would be used (allowing an LRA to
override the extension requested by the end-entity).
5.6 Transaction Management Control Attributes attribute. Clients MUST be able to process the CMCStatusInfoExt
Transactions are identified and tracked using a transaction control.
identifier. If used, clients generate transaction identifiers and
retain their value until the server responds with a message that
completes the transaction. Servers correspondingly include received
transaction identifiers in the response.
The transactionId attribute identifies a given transaction. It is 5.1.1 Extended CMC Status Info Control Attribute
used between client and server to manage the state of an operation.
Clients MAY include a transactionID attribute in request messages.
If the original request contains a transactionID attribute, all
subsequent request and response messages MUST include the same
transactionID attribute. A server MUST use only transactionIds in
the outermost PKIdata object. TransactionIds on inner PKIdata
objects are for intermediate entities.
Replay protection can be supported through the use of sender and This control uses the following ASN.1 definition:
transaction, no recipientNonce is transmitted; a senderNonce is
instantiated by the message originator and retained for later
reference. The recipient of a sender nonce reflects this value back
to the originator as a recipientNonce and includes it's own
senderNonce. Upon receipt by the transaction originator of this
message, the originator compares the value of recipientNonce to its
retained value. If the values match, the message can be accepted
for further security processing. The received value for senderNonce
is also retained for inclusion in the next message associated with
the same transaction.
The senderNonce and recipientNonce attribute can be used to provide CMCStatusInfoExt ::= SEQUENCE {
application-level replay prevention. Clients MAY include a
senderNonce in the initial request message. Originating messages
include only a value for senderNonce. If a message includes a
senderNonce, the response MUST include the transmitted value of the
previously received senderNonce as recipientNonce and include new
value for senderNonce. A server MUST use only nonces in the
outermost PKIdata object. Nonces on inner PKIdata objects are for
intermediate entities.
5.7 Proof-of-possession (POP) for encryption-only keys CMCStatus CMCStatus,
Everything described in this section is optional to implement, for BodyList SEQUENCE SIZE (1..MAX) OF
both servers and clients. Servers MAY require this POP method be
used only if another POP method is unavailable. Servers SHOULD
reject all requests contained within a PKIData if any required POP
is missing for any element within the PKIData.
Many servers require proof that an entity requesting a certificate BodyPartReference,
for a public key 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 StatusString UTF8String OPTIONAL,
round-trip, since there are four distinct phases:
1. Client tells the server about the public component of a new OtherInfo CHOICE {
encryption key pair.
2. Server sends the client a POP challenge, encrypted with the
presented public encryption key, which the client must decrypt.
3. Client decrypts the POP challenge and sends it back to the
server.
4. Server validates the decrypted POP challenge and continues
processing the certificate request.
CMC defines two different attributes. The first deals with the FailInfo CMCFailInfo,
encrypted challenge sent from the server to the user in step 2. The
second deals with the decrypted challenge sent from the client to
the server in step 3.
The encryptedPOP attribute is used to send the encrypted challenge PendInfo PendInfo,
from the server to the client. As such, it is encoded as a tagged
attribute within the controlSequence of a ResponseBody. (Note that
we assume that the message sent in Step 1 above is an enrollment
request and that the response in step 2 is a Full Enrollment
Response including a failureInfo specifying that a POP is explicitly
required, and providing the POP challenge in the encryptedPOP
attribute.)
EncryptedPOP ::= SEQUENCE ExtendedFailInfo SEQUENCE {
request TaggedRequest, FailInfoOID OBJECT IDENTIFIER,
cms contentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE FailInfoValue AttributeValue
bodyPartID BodyPartID, }
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows: }
1. The server generates a random value y and associates it with the }
request. BodyPartReference ::= CHOICE {
2. The server returns the encrypted pop with the following fields
set:
a. request is the certificate request in the original request
message (it is included here so the client need not key a copy of
the request),
b. cms is an EnvelopedData object, the content type being id-data
and the content being the value y. If the certificate request
contains a subject key identifier (SKI) extension, then the
recipient identifier SHOULD be the SKI. If the
issuerAndSerialNumber form is used, the IsserName MUST be
encoded as NULL and the SerialNumber as the bodyPartId of the
certificate request,
c. thePOPAlgID contains the algorithm to be used in computing the
return POP value,
d. witnessAlgID contains the hash algorithm used on y to create
the field witness,
e. witness contains the hashed value of y.
3. The client decrypts the cms field to obtain the value y. The
client computes H(y) 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 message containing a
CMCStatusInfo control attribute with failInfo value of popFailed.
4. The client creates the decryptedPOP as part of a new PKIData
message. The fields in the decryptedPOP are:
a. bodyPartID refers to the certificate request in the new
enrollment message,
c. thePOP contains the possession proof. This value is computed
by thePOPAlgID using the value y and request referenced in (4a).
5. The server then re-computes the value of thePOP from its cached
value of y and the request and compares to the value of thePOP. If
the values do not match, the server MUST NOT issue the certificate.
The server MAY re-issue a new challenge or MAY fail the request
altogether.
When defining the algorithms for thePOPAlgID and witnessAlgID care BodyPartID BodyPartID,
must be taken to ensure that the result of witnessAlgID is not a
useful value to shortcut the computation with thePOPAlgID. Clients
MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC-
SHA1 for thePOPAlgID. The value of y is used as the secret value in
the HMAC algorithm and the request referenced in (4a) is used as the
data. If y is greater than 64 bytes, only the first 64 bytes of y
are used as the secret.
One potential problem with the algorithm above is the amount of BodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID
state that a CA needs to keep in order to verify the returned POP
value. This 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 certificate request R, server computes y = F(x,R). F can be, PendInfo ::= SEQUENCE {
for example, HMAC-SHA1(x,R). All that's important for statelessness
is that y be consistently computable with only known state constant
x and function F, other inputs coming from the cert request
structure. y should not be predictable based on knowledge of R,
thus the use of a OWF like HMAC-SHA1.
5.8 LRA POP Witnesses Control Attribute pendToken OCTET STRING,
In an enrollment scenario involving an LRAs the CA may allow (or pendTime GeneralizedTime
require) the LRA to perform the POP protocol with the entity
requesting certification. In this case the LRA needs a way to
inform the CA it has done the POP. This control attribute has been
created to address this issue.
The ASN.1 structure for the LRA POP witness is as follows: }
LraPopWitness ::= SEQUENCE -- cMCStatus is described in section 5.1.3
pkiDataBodyid BodyPartID, -- bodyList contains the list of references to body parts in the
bodyIds SEQUENCE of BodyPartID
}
-- pkiDataBodyid field contains the body part id of the nested CMS request message to which this status information applies. If an
body object containing the client's full request message.
pkiDataBodyid is set to 0 if the request is in the current
PKIRequest body.
-- bodyIds contains a list of certificate requests for which the LRA
authentication could be archival of private key material, challenge-
response or other means.
If a certificate server does not allow for an LRA to do the POP error is being returned for a simple enrollment message, body list
verification, it returns an error of POPFAILURE. The CA MUST NOT
start a challenge-response to re-verify the POP itself.
5.9 Get Certificate Control Attribute will contain a single integer of value '1'.
Everything described in this section is optional to implement. -- statusString contains a string with additional description
The get certificate control attribute is used to retrieve previously information. This string is human readable.
issued certificates from a repository of certificates. A
Certificate Authority, an LRA or an independent service may provide
this repository. The clients expected to use this facility are
those operating in a resource-constrained environment. (An example
of a resource-constrained client would be a low-end IP router that
does not retain its own certificate in non-volatile memory.)
The get certificate control attribute has the following ASN.1 -- failInfo is described in section 5.1.4. It provides a detailed
structure:
GetCert ::= SEQUENCE error on what the failure was. This choice is present only if
issuerName GeneralName, cMCStatus is failed.
serialNumber INTEGER }
The service responding to the request will place the requested -- extendedFailInfo is provided for other users of the enrollment
certificate in the certificates field of a SignedData object. If
the get certificate attribute is the only control in a Full PKI
Request message, the response would be a Simple Enrollment Response.
5.10 Get CRL Control Attribute protocol to provided their own error codes. This choice is present
Everything described in this section is optional to implement. only if cMCStatus is failed. Caution should be used in defining new
The get CRL control attribute is used to retrieve CRLs from a values as they may not be correctly recognized by all clients and
repository of CRLs. A Certification Authority, an LRA 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 attribute has the following ASN.1 structure: servers. The failInfo value of internalCA error may be assumed if
GetCRL ::= SEQUENCE the extended error is not recognized.
issuerName Name, -- pendToken is the token to be used in the queryPending control
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings: attribute.
-- issuerName is the name of the CRL issuer. -- pendTime contains the suggested time the server wants to be
-- cRLName may be the value of CRLDistributionPoints in the subject queried about the status of the request.
certificate or equivalent value in the event the certificate does
-- 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 If the cMCStatus field is success, the CMC Status Info Control MAY
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 service responding to the request will place the requested CRL in be omitted unless it is only item in the response message. If no
the crls field of a SignedData object. If the get CRL attribute is
the only control in a full enrollment message, the response would be
a simple enrollment response.
5.11 Revocation Request Control Attribute status exists for a certificate request or other item requiring
The revocation request control attribute is used to request that a processing, then the value of success is to be assumed.
certificate be revoked.
The revocation request control attribute has the following ASN.1 5.1.2 CMC Status Info Control Attribute
syntax:
RevRequest ::= SEQUENCE The CMC status info control is used in full PKI Response messages to
issuerName Name, return information on a client request. Servers MAY emit multiple
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
-- issuerName contains the issuerName of the certificate to be CMC status info controls referring to a single body part. Clients
revoked.
-- serialNumber contains the serial number of the certificate to be MUST be able to deal with multiple CMC status info controls in a
revoked
-- reason contains the suggested CRLReason code for why the response message. This statement uses the following ASN.1
certificate is being revoked. The CA can use this value at its
discretion in building the CRL.
-- invalidityDate contains the suggested value for the Invalidity definition:
Date CRL Extension. The CA can use this value at its discretion in
building the CRL.
-- sharedSecret contains a secret value registered by the EE when CMCStatusInfo ::= SEQUENCE {
the certificate was obtained to allow for revocation of a
certificate in the event of key loss.
-- comment contains a human readable comment. cMCStatus CMCStatus,
For a revocation request to become a reliable object in the event of bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
However, in the instance when an end-entity has lost use of its
signature private key, it is impossible for the end-entity to
produce a digital signature (prior to the certification of a new
signature key pair). The RevRequest provides for the optional
transmission from the end-entity to the CA of a shared secret that
may be used as an alternative authenticator in the instance of loss
of use. The acceptability of this practice is a matter of local
security policy.
(Note that in some situations a Registration Authority may be statusString UTF8String OPTIONAL,
delegated authority to revoke certificates on behalf of some failInfo CMCFailInfo,
population within its scope control. In these situations the CA
would accept the LRA's digital signature on the request to revoke a
certificate, independent of whether the end entity still had access
to the private component of the key pair.)
Clients MUST provide the capability to produce a digitally signed pendInfo PendInfo } OPTIONAL
revocation request control attribute. Clients SHOULD be capable of
producing an unsigned revocation request containing the end-entity's
shared secret. (The unsigned message consisting of a CMS signedData
object with no signatures.) If a client provides shared secret
based self- revocation, the client MUST be capable of producing a
revocation request 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. The shared
secret has a one-time use, that of causing the certificate to be
revoked, 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 response message MUST be returned for a revocation request. -- cMCStatus is described in section 5.1.3
5.12 Registration and Response Information Control Attributes -- bodyList contains the list of body parts in the request
The regInfo control attribute is for clients and LRAs to pass message to which this status information applies. If an error is
additional information as part a PKI request. The regInfo control
attribute uses the ASN.1 structure:
RegInfo ::= OCTET STRING being returned for a simple enrollment message, body list will
The content of this data is based on bilateral agreement between the contain a single integer of value '1'.
client and server.
If a server (or LRA) needs to return information back to a requestor -- statusString contains a string with additional description
in response to data submitted in a regInfo attribute, then that data
is returned as a responseInfo control attribute. The content of the
OCTET STRING for response information is based on bilateral
agreement between the client and server.
5.13 Query Pending Control Attribute information. This string is human readable.
In some environments, process requirements for manual intervention
or other identity checking can cause a delay in returning the
certificate related to a certificate request. The query pending
attribute allows for a client to query a server about the state of a
pending certificate request. The server returns a token as part of
the CMCStatusInfo attribute (in the otherInfo field). The client
puts the token into the query pending attribute to identify the
correct request to the server. The server can also return a
suggested time for the client to query for the state of a pending
certificate request.
The ASN.1 structure used by the query pending control attribute is: -- failInfo is described in section 5.1.4. It provides a detailed
QueryPending ::= OCTET STRING error on what the failure was. This choice is present only if
If a server returns a pending state (the transaction is still cMCStatus is failed.
pending), the otherInfo MAY be omitted. If it is not omitted then
the same value MUST be returned (the token MUST NOT change during
the request).
5.14 Confirm Certificate Acceptance If the cMCStatus field is success, the CMC Status Info Control MAY
Some Certification Authorities require that clients give a positive be omitted unless it is only item in the response message. If no
conformation that the certificates issued to it are acceptable. The
Confirm Certificate Acceptance control attribute is used for that
purpose. If the CMCStatusInfo on a certificate responserequest is
confirmRequired, then the client MUST return a Confirm Certificate
attribute contained in a full enrollment response message.
Acceptance prior to any usage of the certificate. Clients SHOULD status exists for a certificate request or other item requiring
wait for the response from the server that the conformation has been
received before using the certificate for any purpose..
The confirm certificate acceptance structure is: processing, then the value of success is to be assumed.
CMCCertId ::= IssuerSerial 5.1.3 CMCStatus values
-- CMCCertId contains the issuer and serial number of the CMCStatus is a field in the CMCStatusInfo structure. This field
certificate being accepted.
Servers MUST return a full enrollment response request for a confirm contains a code representing the success or failure of a specific
certificate acceptance control.
Note that if the Certification Authority includes this attribute, operation. CMCStatus has the ASN.1 structure of:
there will be two full round trips of messages.
The client sends the request to the CA. CMCStatus ::= INTEGER {
The CA returns the certificate and this attribute.
The client sends a response message to the CA with an
CMCStatusInfoEx control either accepting or rejecting the
certificate.
The CA sends a response message to the client with a CMCStatusInfoEx
of success.
6. Local Registration Authorities success (0),
This specification permits the use of Local Registration Authorities
(LRAs). An LRA sits between the end-entity and the Certification
Authority. From the end-entity's perspective, the LRA appears to be
the Certification Authority and from the server the LRA appears to
be a client. LRAs receive the enrollment messages, perform local
processing and then forward onto Certificate Authorities. Some of
the types of local processing that an LRA can perform include:
- batching multiple enrollment messages together, -- request was granted
- challenge/response POP proofs,
- addition of private or standardized certificate extensions to all
requests,
- archival of private key material,
- routing of requests to different CAs.
When an LRA receives an enrollment message it has three options: it -- reserved (1),
may forward the message without modification, it may add a new
wrapping layer to the message, or it may remove one or more existing
layers and add a new wrapping layer.
When an LRA adds a new wrapping layer to a message it creates a new -- not used, defined where the original structure was
PKIData object. The new layer contains any control attributes
required (for example if the LRA does the POP proof for an
encryption key or the addExtension control attribute to modify an
enrollment request) and the client enrollment message. The client
enrollment message is placed in the cmsSequence if it is a Full
Enrollment message and in the reqSequence if it is a Simple
Enrollment message. If an LRA is batching multiple client messages
together, then each client enrollment message is placed into the
appropriate location in the LRA's PKIData object along with all
relevant control attributes.
(If multiple LRAs are in the path between the end-entity and the defined
Certification Authority, this will lead to multiple wrapping layers
on the message.)
In processing an enrollment message, an LRA MUST NOT alter any failed (2),
certificate request body (PKCS #10 or CRMF) as any alteration would
invalidate the signature on the request and thus the POP for the
private key.
An example of how this would look is illustrated by the following -- you don't get what you want, more information elsewhere
figure:
SignedData (by LRA) in the message
PKIData
controlSequence
LRA added control statements
reqSequence
Zero or more Simple CertificationRequests from clients
cmsSequence
Zero or more Full PKI messages from clients
SignedData (by client)
PKIData
Under some circumstances an LRA is required to remove wrapping
layers. The following sections look at the processing required if
encryption layers and signing layers need to be removed.
6.1 Encryption Removal pending (3),
There are two cases that require an LRA to remove or change -- the request body part has not yet been processed,
encryption in an enrollment message. In the first case the
encryption was applied for the purposes of protecting the entire
enrollment request from unauthorized entities. If the CA does not
have a recipient info entry in the encryption layer, the LRA MUST
remove the encryption layer. The LRA 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 -- requester is responsible to poll back on this
the encryption inside of a signing layer. In this case the LRA 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 LRA. If the signing
layer provided by the end-entity needs to be removed to the LRA can
remove the layer.
6.2 Signature Layer Removal -- pending may only be return for certificate request
Only two instances exist where an LRA should remove a signature operations.
layer on a Full Enrollment message. If an encryption needs to be
modified within the message, or if a Certificate Authority will not
accept secondary delegation (i.e. multiple LRA signatures). In all
other situations LRAs SHOULD NOT remove a signing layer from a
message.
If an LRA removes a signing layer from a message, all control noSupport (4),
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 LRA.
7. Transport Wrapping -- the requested operation is not supported
Not all methods of transporting data allow for sending unlabeled raw confirmRequired (5)
binary data, in may cases standard methods of encoding can be used
to greatly ease this issue. These methods normally consist of
wrapping some identification of the content around the binary data,
possibly applying an encoding to the data and labeling the data.
We document for use three different wrapping methods.
-- MIME wrapping is for transports that are natively MIME based such -- conformation using the idConfirmCertAcceptance control is
as HTTP and E-mail.
-- Binary file transport is defined since floppy disk transport is
still very common. File transport can be done either as MIME
wrapped (section 7.1) or bare (section 7.2).
-- Socket based transport uses the raw BER encoded object.
7.1 MIME Wrapping required
MIME wrapping is defined for those environments that are MIME
native. These include E-Mail based protocols as well as HTTP.
The basic mime wrapping in this section is taken from [SMIMEV2] and -- before use of certificate
[SMIMEV3]. Simple enrollment requests are encoded using the
application/pkcs10 content type. A file name MUST be included
either in a content type or content disposition statement. The
extension for the file MUST be ".p10".
Simple enrollment response messages MUST be encoded as content-type }
application/pkcs7-mime. An smime-type parameter MUST be on the
content-type statement with a value of "certs-only." A file name
with the ".p7c" extension MUST be specified as part of the content-
type or content-disposition.
Full enrollment request messages MUST be encoded as content-type 5.1.4 CMCFailInfo
application/pkcs7-mime. The smime-type parameter MUST be included
with a value of "CMC-enroll". A file name with the ".p7m" extension
MUST be specified as part of the content-type or content-disposition
statement.
Full enrollment response messages MUST be encoded as content-type CMCFailInfo conveys information relevant to the interpretation of a
application/pkcs7-mime. The smime-type parameter MUST be included
with a value of "CMC-response." A file name with the ".p7m"
extensions MUST be specified as part of the content-type or content-
disposition.
MIME TYPE File Extension SMIME-TYPE failure condition. The CMCFailInfo has the following ASN.1
CMCFailInfo ::= INTEGER {
application/pkcs10 .p10 N/A badAlg (0)
(simple PKI request)
application/pkcs7-mime .p7m CMC-request -- Unrecognized or unsupported algorithm
(full PKI request)
application/pkcs7-mime .p7c certs-only badMessageCheck (1)
(simple PKI response)
application/pkcs7-mime .p7m CMC-response -- integrity check failed
(full PKI response)
7.2 File-Based Transport badRequest (2)
Enrollment messages and responses may also be transferred between -- transaction not permitted or supported
clients and servers using file system-based mechanisms, such as when
enrollment is performed for an off-line client. When files are used
to transport binary, BER-encoded Full Enrollment Request and
Response messages, the following file type extensions SHOULD be
used:
Message Type File Extension badTime (3)
Full PKI Request .crq -- Message time field was not sufficiently close to the
Full PKI Response .crp system time
7.3 Socket-Based Transport
When enrollment messages and responses are sent over sockets, no badCertId (4)
wrapping is required. Messages SHOULD be sent in their binary, BER-
encoded form.
8. Interoperability -- No certificate could be identified matching the provided
8.1 Mandatory and Optional Algorithms criteria
CMC clients and servers MUST be capable of producing and processing unsuportedExt (5)
message signatures using the Digital Signature Algorithm [DSA]. DSA
signatures MUST be indicated by the DSA AlgorithmIdentifier value
(as specified in section 7.2.2 of [PKIXCERT]). PKI clients and
servers SHOULD also be capable of producing and processing RSA
signatures (as specified in section 7.2.1 of [PKIXCERT]).
CMC clients and servers MUST be capable of protecting and accessing -- A requested X.509 extension is not supported by the
message encryption keys using the Diffie-Hellman (D-H) key exchange
algorithm. D-H/3DES protection MUST be indicated by the D-H
AlgorithmIdentifier value specified in [CMS]. PKI clients and
servers SHOULD also be capable of producing and processing RSA key
transport. When used for PKI messages, RSA key transport MUST be
indicated as specified in section 7.2.1 of [PKIXCERT].
8.2 Minimum Conformance Requirements recipient CA.
A minimally compliant CMC server: mustArchiveKeys (6)
a) MUST accept a Full PKI Request message -- Private key material must be supplied
i) MUST accept CRMF Request Bodies within a Full PKI Request
ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
b) MUST accept a Simple Enrollment Request message
c) MUST be able to return a Full PKI Response. (A Full PKI Response
is always a valid response, but for interoperability with downlevel
clients a compliant server SHOULD use the Simple Enrollment Response
whenever possible.)
A minimally-complaint CMC client: badIdentity (7)
a) MAY use either the Simple Enrollment Message or the Full PKI -- Identification Attribute failed to verify
Request.
i) clients MUST use PKCS#10 with the Simple Enrollment Message
ii) clients MAY use either PKCS#10 or CRMF with the Full PKI
Request
b) MUST understand the Simple Enrollment Response.
c) MUST understand the Full PKI Response.
9. Security Considerations popRequired (8)
Initiation of a secure communications channel between an end-entity -- Server requires a POP proof before issuing certificate
and a CA or LRA (and, similarly, between an LRA and another LRA or
CA) necessarily requires an out-of-band trust initiation mechanism.
For example, a secure channel may be constructed between the end-
entity and the CA via IPSEC or TLS. Many such schemes exist and the
scope of this document. Implementers of this protocol are strongly
encouraged to consider generally accepted principles of secure key
management when integrating this capability within an overall
security architecture.
Mechanisms for thwarting replay attacks may be required in popFailed (9)
particular implementations of this protocol depending on the
operational environment. In cases where the CA maintains significant
state information, replay attacks may be detectable without the
inclusion of the optional nonce mechanisms. Implementers of this
protocol need to carefully consider environmental conditions before
choosing whether or not to implement the senderNonce and
recipientNonce attributes described in section 5.6. Developers of
state-constrained PKI clients are strongly encouraged to incorporate
the use of these attributes.
Under no circumstances should a signing key be archived. Doing so -- POP processing failed
allows the archiving entity to potentially use the key for forging
signatures.
Due care must be taken prior to archiving keys. Once a key is given noKeyReuse (10)
to an archiving entity, the archiving entity could use the keys in a
way not conducive to the archiving entity. Users should be made
especially aware that proper verification is made of the certificate
used to encrypt the private key material.
Clients and servers need to do some checks on cryptographic -- Server policy does not allow key re-use
parameters prior to issuing certificates to make sure that weak
parameters are not used. A description of the small subgroup attack
is provided in [X942]. CMC implementations ought to be aware of
this attack when doing parameter validations.
When using a shared-secret for authentication purposes, the shared- internalCAError (11)
secret should be generated using good random number techniques.
User selection of the secret allows for dictionary attacks to be
mounted.
10. Acknowledgments tryLater (12)
The authors would like to thank Brian LaMacchia for his work in }
developing and writing up many of the concepts presented in this
document. The authors would also like to thank Alex Deacon and Barb
Fox for their contributions.
11. References Additional failure reasons MAY be defined for closed environments
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, with a need.
June 1999.
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet 5.2 Identification and IdentityProof Control Attributes
X.509 Certificate Request Message Format", RFC 2511,
March
1999.
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4" Some CAs and LRAs require that a proof of identity be included in a
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of- certification request. Many different ways of doing this exist with
Possession Algorithms", Work in Progress.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- different degrees of security and reliability. Most people are
Hashing for Message Authentication", RFC 2104, February
1997.
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC familiar with the request of a bank to provide your mother's maiden
2313, March 1998.
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax name as a form of identity proof.
v1.5",
RFC 2315, October 1997.
[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax CMC provides one method of proving the client's identity based on a
Standard, Version 1.2", November 1, 1993.
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax shared secret between the certificate requestor and the verifying
v1.5", RFC 2314, October 1997.
[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet authority. If clients support full request messages, clients MUST
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate implement this method of identity proof. Servers MUST provide this
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and method and MAY also have a bilateral method of similar strength
L.
Repka, "S/MIME Version 2 Message Specification", RFC
2311,
March 1998.
[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification", available.
RFC 2633, June 1999.
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC The CMC method starts with an out-of-band transfer of a token (the
2631, June 1999.
12. Authors' Addresses shared secret). The shared-secret should be generated in a random
Michael Myers manner. The distribution of this token is beyond the scope of this
VeriSign Inc.
1350 Charleston Road
Mountain View, CA, 94043
Phone: (650) 429-3402 document. The client then uses this token for an identity proof as
EMail: mmyers@verisign.com
Xiaoyi Liu follows:
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
EMail: xliu@cisco.com
Jim Schaad 1. The reqSequence field of the PKIData object (encoded exactly as
EMail: jimsch@nwlinkexmsft.com it appears in the request message including the sequence type and
Jeff Weinstein length) is the value to be validated.
EMail: jsw@meer.net 2. A SHA1 hash of the token is computed.
Appendix A ASN.1 Module 3. An HMAC-SHA1 value is then computed over the value produced in
EnrollmentMessageSyntax Step 1, as described in [HMAC], using the hash of the token from
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
DEFINITIONS IMPLICIT TAGS ::= Step 2 as the shared secret value.
BEGIN
-- EXPORTS All -- 4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS value of the identityProof attribute.
-- Information Directory Framework (X.501) When the server verifies the identityProof attribute, it computes
Name
FROM InformationFramework { joint-iso-itu-t ds(5)
modules(1) informationFramework(1) 3 }
-- Directory Authentication Framework (X.509) the HMAC-SHA1 value in the same way and compares it to the
AlgorithmIdentifier, AttributeCertificate, Certificate,
CertificateList, CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Part 1 - Implicit identityProof attribute contained in the enrollment request.
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- PKIX Part 1 - Explicit If a server fails the verification of an identityProof attribute and
SubjectPublicKeyInfo, Extension
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- Cryptographic Message Syntax the server returns a response message, the failInfo attribute MUST
ContentInfo, Attribute
FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
CertReqMsg
FROM CRMF { 1 3 6 1 5 5 7 0 5 };
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) be present in the response and MUST have a value of badIdentity.
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls Reuse of the shared-secret on enrollment retries makes it easier for
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have simple type content (usually OCTET the client and to prevent getting out of sync. However, reuse of
STRING)
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2} the shared-secret can potentially open the door for some types of
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
-- This is the content type used for a request message in the attacks.
protocol
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 } Optionally, servers MAY require the inclusion of the unprotected
PKIData ::= SEQUENCE identification attribute with an identification attribute. The
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, identification attribute is intended to contain either a text string
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
bodyIdMax INTEGER ::= 4294967295 or a numeric quantity, such as a random number, which assists the
BodyPartID ::= INTEGER(0..bodyIdMax) server in locating the shared secret needed to validate the contents
TaggedAttribute ::= SEQUENCE of the identityProof attribute. Numeric values MUST be converted to
bodyPartID BodyPartId, text string representations prior to encoding as UTF8-STRINGs in
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY this attribute. If the identification control attribute is included
TaggedRequest ::= CHOICE in the message, the derivation of the shared secret in step 2 is
tcr [0] TaggedCertificationRequest, altered so that the hash of the concatenation of the token and the
crm [1] CertReqMsg
}
TaggedCertificationRequest ::= SEQUENCE identity value are hashed rather than just the token.
certificationRequest CertificationRequest
}
CertificationRequest ::= SEQUENCE 5.2.1 Hardware Shared Secret Token Generation
certificationRequestInfo SEQUENCE The shared secret between the end-entity and the identity verify is
version INTEGER, sometimes transferred using a hardware device that generates a
subject Name,
subjectPublicKeyInfo SEQUENCE
algorithm AlgorithmIdentifier, series of tokens based on some shared secret value. The user can
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TaggedContentInfo ::= SEQUENCE therefore prove their identity by transferring this token in plain
bodyPartID BodyPartId, text along with a name string. The above protocol can be used with
contentInfo ContentInfo
}
OtherMsg ::= SEQUENCE a hardware shared-secret token generation device by the following
bodyPartID BodyPartID, modifications:
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- This defines the response message in the protocol 1. The identification attribute MUST be included and MUST contain
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= SEQUENCE the hardware-generated token.
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute, 2. The shared secret value used above is the same hardware-generated
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- Used to return status state in a response token.
id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1} 3. All certification requests MUST have a subject name and the
CMCStatusInfo ::= SEQUENCE subject name MUST contain the fields required to identify the holder
cMCStatus CMCStatus, of the hardware token device.
bodyList SEQUENCE SIZE (1..MAX) OF INTEGERBodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE
failInfo CMCFailInfo, 5.3 Linking Identity and POP Information
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE In a PKI Full Request message identity information about the
SignedData object containing all of the certificate requests. Proof-
pendToken INTEGEROCTET STRING, of-possession information for key pairs requesting certification,
pendTime GENERALIZEDTIME
}
CMCStatus ::= INTEGER however, is carried separately for each PKCS#10 or CRMF message.
success (0), (For keys capable of generating a digital signature, the POP is
-- you got exactly what you asked for
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCFailInfo ::= INTEGER provided by the signature on the PKCS#10 or CRMF request. For
badAlg (0), encryption-only keys the controls described in Section 5.7 below are
-- Unrecognized or unsupported algorithm
badMessageCheck (1),
-- integrity check failed
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- Message time field was not sufficiently close to the
systemtime
badCertId (4),
-- No certificate could be identified matching the provided
criteria
unsuportedExt (5),
-- A requested X.509 extension is not supported by the
recipient CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
-- Used for LRAs to add extensions to certificate requests used.) In order to prevent substitution-style attacks we must
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
AddExtensions ::= SEQUENCE guarantee that the same entity generated both the POP and proof-of-
pkiDataReference BodyPartID, identity information.
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9} This section describes two mechanisms for linking identity and POP
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
EncryptedPOP ::= SEQUENCE information: witness values cryptographically derived from the
request TaggedRequest, shared-secret (Section 5.3.1) and shared-secret/subject DN matching
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE (Section 5.3.2). Clients and servers MUST support the witness value
bodyPartID BodyPartID, technique. Clients and servers MAY support shared-secret/subject DN
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11} matching or other bilateral techniques of similar strength. The
LraPopWitness ::= SEQUENCE idea behind both mechanisms is to force the client to sign some data
pkiDataBodyid BodyPartID, into each certificate request that can be directly associated with
bodyIds SEQUENCE OF BodyPartID
}
-- the shared-secret; this will defeat attempts to include certificate
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
GetCert ::= SEQUENCE requests from different entities in a single Full PKI Request
issuerName GeneralName, message.
serialNumber INTEGER }
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16} 5.3.1 Witness values derived from the shared-secret
GetCRL ::= SEQUENCE The first technique for doing identity-POP linking works by forcing
issuerName Name, the client to include a piece of information cryptographically-
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17} derived from the shared-secret token as a signed extension within
RevRequest ::= SEQUENCE each certificate request (PKCS#10 or CRMF) message. This technique
issuerName Name, is useful if null subject DNs are used (because, for example, the
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24} server can generate the subject DN for the certificate based only on
CMCCertId ::= IssuerSerial the shared secret). Processing begins when the client receives the
-- The following is used to request V3 extensions be added to a shared-secret token out-of-band from the server. The client then
certificate
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) computes the following values:
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
ExtensionReq ::= SEQUENCE OF Extension 1. The client generates a random byte-string, R, which SHOULD be at
-- The following exists to allow Diffie-Hellman Certificate Requests
Messages to be
-- well-formed
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2} least 512 bits in length.
NoSignatureValue ::= OCTET STRING 2. A SHA1 hash of the token is computed.
END 3. An HMAC-SHA1 value is then computed over the random value
Full Copyright Statement produced in Step 1, as described in [HMAC], using the hash of the
Copyright (C) The Internet Society (2000). All Rights Reserved. token from Step 2 as the shared secret.
This document and translations of it may be copied and furnished to 4. The random value produced in Step 1 is encoded as the value of an
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be idPOPLinkRandom control attribute. This control attribute MUST be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an included in the Full PKI Request message.
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value
Funding for the RFC Editor function is currently provided by the of an idPOPLinkWitness extension to the certificate request.
Internet Society.
a. For CRMF, idPOPLinkWitness is included in the controls section
of the CertRequest structure.
b. For PKCS#10, idPOPLinkWitness is included in the attributes
section of the CertificationRequest structure.
Upon receipt, servers MUST verify that each certificate request
contains a copy of the idPOPLinkWitness and that its value was
derived in the specified manner from the shared secret and the
 End of changes. 440 change blocks. 
1735 lines changed or deleted 1249 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/