WDIFF

draft-ietf-pkix-2797-bis-04.txt --> draft-ietf-pkix-2797-bis-05.txt

Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Expires: September 3, 2006 May 22, 2008 M. Myers
TraceRoute Security, Inc.
March 2, 2006
November 19, 2007

Certificate Management Messages over CMS
draft-ietf-pkix-2797-bis-04.txt
draft-ietf-pkix-2797-bis-05.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 3, 2006. May 22, 2008.

Schaad & Myers Expires May 22, 2008 [Page 1]

Internet-Draft CMC: Structures November 2007

Abstract

This document defines the base syntax for CMC, a Certificate
Management protocol using CMS (Cryptographic the Cryptographic Message Syntax). Syntax (CMS).
This protocol addresses two immediate needs within the Internet PKI
Public Key Infrastructure (PKI) community:

1. The need for an interface to public key certification products
and services based on CMS and PKCS #10 (Public Key Crytpography

Schaad & Myers Expires September 3, 2006 [Page 1]

Internet-Draft CMS: Structures March 2006 Cryptography
Standard), and

2. The need in S/MIME (Secure MIME) for a certificate PKI enrollment protocol for DSA-signed certificates with Diffie-Hellman public
keys. encryption only keys
due to algorithm or hardware design.

CMC also requires the use of the transport document and the
requirements usage document along with this document for a full
definition.

Schaad & Myers Expires May 22, 2008 [Page 2]

Internet-Draft CMC: Structures November 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4 5
1.2. Notation Requirements Terminology . . . . . . . . . . . . . . . . . 6
1.3. Changes since RFC 2797 . . . . . . . . . 5 . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 7
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 8
2.2. Protocol Flow Charts Request/Responses . . . . . . . . . . . . . . . . 9
3. PKI Requests . . . 8
3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 12
3.1. PKIData Object . . Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10 12
3.2. ResponseBody Object Full PKI Request . . . . . . . . . . . . . . . . . . . 11
3.3. Certification Requests (PKCS10/CRMF) . . 13
3.2.1. PKIData content type . . . . . . . . . . 12
3.3.1. PKCS10 Request Body . . . . . . . 14
3.2.1.1. Control Syntax . . . . . . . . . . 12
3.3.2. CRMF Request Body . . . . . . . . 16
3.2.1.2. Certification Request Formats . . . . . . . . . . 13
3.3.3. Production of Diffie-Hellman Public Key 16
3.2.1.2.1. PKCS #10 Certification Requests . Syntax . . . . . . . . 17
3.2.1.2.2. CRMF Certification Syntax . . . . . . . 14
3.4. Body Part Identifiers . . . 18
3.2.1.2.3. Other Certification Request . . . . . . . . . 19
3.2.1.3. Content Info Objects . . . . . . 15
3.5. Control Attributes . . . . . . . . . 20
3.2.1.3.1. Authenticated Data . . . . . . . . . . . 15
3.6. Content Info objects . . . 20
3.2.1.3.2. Data . . . . . . . . . . . . . . . . 16
3.6.1. Signed Data . . . . . 21
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 17
3.6.2. Enveloped 21
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . . . . 17
3.6.3. Authenticated Data . 21
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 22
3.2.2. Body Part Identification . . 17
3.7. Other Message Bodies . . . . . . . . . . . . . 22
3.2.3. CMC Unsigned Data Attribute . . . . . . 18
3.8. Unsigned Attributes . . . . . . . 23
4. PKI Responses . . . . . . . . . . . . 18
4. PKI Messages . . . . . . . . . . . . 25
4.1. Simple PKI Response . . . . . . . . . . . . . 20
4.1. Simple Enrollment Request . . . . . . 25
4.2. Full PKI Response . . . . . . . . . . 20
4.2. Full PKI Request . . . . . . . . . . 25
4.2.1. PKIResponse Content Type . . . . . . . . . . . 20
4.3. Simple Enrollment Response . . . . 26
5. Application of Encryption to a PKI Request/Response . . . . . 28
6. Controls . . . . . . . 21
4.4. Full PKI Response . . . . . . . . . . . . . . . . . . . . 22
4.5. Application of Encryption to a PKI Message . . . . . . . . 22
5. Control Attributes . . . . . 29
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 24
5.1. 31
6.1.1. Extended CMC Status Info Control Attributes . . . . . . . . . . . . 24
5.1.1. Extended 31
6.1.2. CMC Status Info Control Attribute . . . . . . 25
5.1.2. CMC Status Info Control Attribute . . . . . . . . . . 26
5.1.3. 33
6.1.3. CMCStatus values . . . . . . . . . . . . . . . . . . . 27
5.1.4. 34
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 27
5.2. 35
6.2. Identification and IdentityProof Control Attributes . . Identity Proof Controls . 28

Schaad & Myers Expires September 3, 2006 [Page 2]

Internet-Draft CMS: Structures March 2006

5.2.1. Hardware Shared Secret Token Generation . . . . . . . 30
5.3. Linking 36
6.2.1. Identity and POP Information . . . . . Proof Version 2 Control . . . . . . 30
5.3.1. Witness values derived from the shared-secret . . . . 30
5.3.2. Shared-secret/subject DN matching . 37
6.2.2. Identity Proof Control . . . . . . . . . 31
5.3.3. Renewal and Re-Key Messages . . . . . . . 38
6.2.3. Identification Control . . . . . . 32
5.4. Data Return Control Attribute . . . . . . . . . . 39
6.2.4. Hardware Shared-Secret Token Generation . . . . 32
5.5. RA Certificate Modification Controls . . . 39
6.3. Linking Identity and POP Information . . . . . . . . 33
5.5.1. Modify Certificate Request Control . . . 40
6.3.1. Cryptographic Linkage . . . . . . . 33
5.5.2. Add Extensions Control . . . . . . . . . 40
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 34
5.6. Transaction Management 40
6.3.1.2. POP Link Witness Control Attributes . . . . . . . . 36
5.7. Proof-of-possession (POP) for encryption-only keys . . . . 36
5.8. LRA . 42
6.3.1.3. POP Witnesses Link Random Control Attribute . . . . . . . . . . . 40
5.9. Get Certificate Control Attribute . . 42
6.3.2. Shared-secret/subject DN linking . . . . . . . . . . 40
5.10. Get CRL Control Attribute . 42

Schaad & Myers Expires May 22, 2008 [Page 3]

Internet-Draft CMC: Structures November 2007

6.3.3. Renewal and Re-Key Messages . . . . . . . . . . . . . 43
6.4. Data Return Control . . 41
5.11. Revocation Request Control Attribute . . . . . . . . . . . 42
5.12. Registration and Response Information Control
Attributes . . . . . . 43
6.5. RA Certificate Modification Controls . . . . . . . . . . . 44
6.5.1. Modify Certificate Request Control . . . . . . . 43
5.13. Query Pending Control Attribute . . . 44
6.5.2. Add Extensions Control . . . . . . . . . . 43
5.14. Confirm Certificate Acceptance . . . . . . 46
6.6. Transaction Identifier, Sender and Recipient Nonce
Controls . . . . . . . . 44
5.15. Publish Trust Roots . . . . . . . . . . . . . . . . . 47
6.7. Encrypted and Decrypted POP Controls . . 45
5.16. Provide Autenticated Data . . . . . . . . . 48
6.8. RA POP Witness Control . . . . . . . 46
5.17. Batch Process Identification . . . . . . . . . . . 51
6.9. Get Certificate Control . . . . 46
5.18. Publication Information Control . . . . . . . . . . . . . 46
5.19. 52
6.10. Get CRL Control Processed . . . . . . . . . . . . . . . . . . . . 47
6. Local . 53
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 54
6.12. Registration and Response Information Controls . . . . . . 55
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 56
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 56
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 57
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 58
6.17. Batch Request and Response Controls . . . . . . . . . . . 59
6.18. Publication Information Control . . . . . . . . . . . . . 60
6.19. Control Processed Control . . . . . . . . . . . . . . . . 61
7. Registration Authorities . . . . . . . . . . . . . . . . 48
6.1. . . . 63
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 49
6.2. 64
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 49
7. 64
8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8. 65
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
9. 67
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
10. 68
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
10.1. 69
11.1. Normative References . . . . . . . . . . . . . . . . . . . 54
10.2. 69
11.2. Informational References . . . . . . . . . . . . . . . . . 54 69
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 56 71
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 64 79
Appendix B.1. Request of a Signing Certificate . . . . . . . . . . 64 79
Appendix B.2. Single Certificate Certification Request, But Modified by RA . . . 65 80
Appendix B.3. Indirect POP for an RSA certificate . . . . . . . . 68 83
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 88
Appendix C.1. No-Signature Signature Mechanism . . . . . . . . . . 88
Appendix D. Change History . . . . . . . . . . . . . . . . . . . 73 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 91
Intellectual Property and Copyright Statements . . . . . . . . . . 75 92

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 3] 4]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

1. Introduction

1. The need for an interface to public key certification products
and services based on CMS and the PKCS #10 (Public Key
Cryptography Standard), #10, and

2. The need in S/MIME (Secure MIME) for a certificate PKI enrollment protocol for DSA-signed certificates with Diffie-Hellman public
keys.

A small number of encryption only keys
due to algorithm or hardware design.

A small number of additional services are defined to supplement the
core certificate certification request service.

Throughout this specification the term CMS is used to refer to both
[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a
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
specification.

1.1. Protocol Requirements

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

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

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

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

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

o The mandatory algorithms

Support must superset exist for the required mandatory algorithms for used by S/MIME.

Schaad & Myers Expires September 3, 2006 [Page 4]

Internet-Draft CMS: Structures March 2006

o
Support should exist for all other algorithms cited by the S/MIME
core documents.

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

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

Schaad & Myers Expires May 22, 2008 [Page 5]

Internet-Draft CMC: Structures November 2007

The protocol needs to must support arbitrary chains of local
registration authorities Registration
Authorities (RAs) as intermediaries between certificate certification
requesters and issuers. Certification Authorities (CAs).

1.2. Notation Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

Schaad & Myers Expires September 3, 2006 [Page 5]

Internet-Draft CMS: Structures March 2006

2. Protocol Overview

An enrollment transaction in this specification is generally composed
of

1.3. Changes since RFC 2797

We have done a single round trip major overhaul on the layout of messages. In the simplest case an
enrollment request is sent document. This
included two different steps. Firstly we removed some sections from
the client to the server document and an
enrollment response is then returned from the server moved them to the client.
In some more complicated cases, such as delayed certificate issuance
and polling for responses, more than one round trip is required.

This specification supports two different request other documents. Information on
how to transport our messages and two
different response messages.

Public key certification requests are now found in [CMC-TRANS].
Information on which controls and sections of this document must be
implemented along with which algorithms are required can now be based on found
in [CMC-MUST].

A number of new controls have been added in this version:

Extended CMC Status Info Section 6.1.1

Publish Trust Anchors Section 6.15

Authenticate Data Section 6.16

Batch Request and Response Processing Section 6.17

Publication Information Section 6.18

Modify Certificate Request Section 6.5.1

Control Processed Section 6.19

Identity Proof Section 6.2.2

Identity POP Link Witness V2 Section 6.3.1.1

Schaad & Myers Expires May 22, 2008 [Page 6]

Internet-Draft CMC: Structures November 2007

2. Protocol Overview

A PKI enrollment transaction in this specification is generally
composed of a single round trip of messages. In the simplest case a
PKI enrollment request, henceforth referred to as a PKI Request, is
sent from the client to the server and a PKI enrollment response,
henceforth referred to as a PKI Responses, is then returned from the
server to the client. In more complicated cases, such as delayed
certificate issuance, more than one round trip is required.

This specification defines two PKI Request types and two PKI Response
types.

PKI Requests are formed using either the PKCS10 PKCS #10 or CRMF object. structure.
The two different request messages are (a) PKI Requests are:

Simple PKI Request: the bare
PKCS10 PKCS #10 (in the event that no other
services are needed), and (b) the
PKCS10

Full PKI Request: one or more PKCS #10, CRMF message or Other Request
Messages structures wrapped in a CMS encapsulation as part of a
PKIData object.

Public key certification responses
PKIData.

PKI Responses are based on the CMS signedData
object. SignedData [CMS]. The response may be either (a) two PKI Responses
are

Simple PKI Response: a degenerate CMS signedData
object "certs-only" SignedData (in the event no
other services are needed), or (b)

Full PKI Response a
ResponseBody object PKIResponse content-type wrapped in a CMS signedData object.
SignedData.

No special services are provided for doing either renewal (new
certificates (i.e., a new
certificate with the same key) or re-keying (new certificates on re-key (i.e., a new certificate
with a new
keys) key) of clients. client certificates. Instead a renewal/re-key message looks the same as
any enrollment message, with renewal and re-key
requests look the same as any certification request, except that the
identity proof being is supplied by existing certificates from the a trusted
CA. (This is usually the same CA, but could be a different CA in the
same organization where naming is shared.)

No special services are provided to distinguish between doing a re-
keying operation re-key
request and obtaining a new certificate certification request (generally for a new
purpose). A control to unpublish a certificate would normally be
included in a replacement operation, re-key request, and be omitted if in a new
certificate was desired. certification
request. CAs or other publishing agents are also expected to have
policies for removing certificates from publication either based on
new certificates being added or the expiration or revocation of a
certificate.

Schaad & Myers Expires May 22, 2008 [Page 7]

Internet-Draft CMC: Structures November 2007

A provision exists for Local Registration Authorities (LRAs) RAs to participate in the protocol by taking client enrollment messages,
PKI Requests, wrapping them in a second layer of enrollment message PKI Request with
additional requirements or statements from the LRA RA and then passing
this new expanded request PKI Request on to the Certification Authority. CA.

This specification makes no assumptions about the underlying
transport mechanism. The use of CMS is does not meant to imply an email-
based email-based
transport.

Schaad & Myers Expires September 3, 2006 [Page 6]

Internet-Draft CMS: Structures March 2006 Several different possible transport methods are defined
in [CMC-TRANS].

Optional services available through this specification are
transaction management, replay detection (through nonces), deferred
certificate issuance, certificate revocation requests and
certificate/CRL
certificate/certificate revocation list (CRL) retrieval.

2.1. Terminology

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

End-Entity (EE) refers to the entity that owns a key pair and for
whom a certificate is issued.

LRA

Registration Authority (RA) or "RA" Local RA (LRA) refers to a (Local) Registration Authority. A
registration authority an entity
that acts as an intermediary between an End-
Entity the EE and a Certification Authority. the CA. Multiple
RAs can exist between the End-Entity and the Certification
Authority.

CA refers to a Certification Authority. A RAs may perform additional services such as key
generation or key archival. This document uses the term RA for
both RA and LRA.

Certification Authority is (CA) refers to the entity that performs the actual issuance of a certificate. issues
certificates.

Client refers to an entity that creates a PKI request. Request. In this
document both RAs and End-Entities EEs can be clients.

Server refers to the entities that process PKI requests Requests and create
PKI responses. Responses. In this document both CAs and RAs can be servers in this document.

PKCS#10 servers.

PKCS #10 refers to the Public Key Cryptography Standard #10. This is one
of a set of standards defined by RSA Laboratories in the 1980s.
PKCS#10 #10
[PKCS10], which defines a Certificate Request Message certification request syntax.

CRMF refers to the Certificate Request Message Format RFC [CRMF]. We
are using certificate
CMC uses this certification request message format syntax defined in this
document as part of our management the protocol.

Schaad & Myers Expires May 22, 2008 [Page 8]

Internet-Draft CMC: Structures November 2007

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

PKI Request/Response refers to a value
that can be used to prove that the private key corresponding requests/responses described in
this document. PKI Requests include certification requests,
revocation requests, etc. PKI Responses include certs-only
messages, failure messages, etc.

Proof-Of-Identity refers to the client proving they are who they say
that are to the server.

Enrollment or certification request refers to the process of a
client requesting a certificate. A certification request is a
subset of the PKI Requests.

Proof-Of-Possession (POP) refers to a value that can be used to
prove that the private key corresponding to a public key is in the
possession and can be used by an end-entity.

Transport wrapper refers to the outermost CMS wrapping layer.

Schaad & Myers Expires September 3, 2006 [Page 7]

Internet-Draft CMS: Structures March 2006

Object IDentifier (OID) is a primitive type in Abstract Syntax
Notation One (ASN.1).

2.2. Protocol Flow Charts Request/Responses

Figure 1 shows the Simple Enrollment Request PKI Requests and Response messages. Responses. The contents
of these messages Simple PKI Request and Response are detailed in Sections 4.1 Section 3.1 and 4.3
below.
Section 4.1.

Schaad & Myers Expires May 22, 2008 [Page 9]

Internet-Draft CMC: Structures November 2007

Simple PKI Request Simple PKI Response
------------------------- --------------------------

Figure 1: Simple PKI Requests and Responses

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

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 8] 10]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

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 Requests and 4.4
below. Responses

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 9] 11]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

3. Protocol Elements PKI Requests

Two types of PKI Requests exist. This section covers each of gives the different elements that may details for
both types.

3.1. Simple PKI Request

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

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

Simple PKI Response on success.

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

The Simple PKI Request MUST NOT be used if a proof-of-identity needs
to construct enrollment request and enrollment response messages.
Section 4 will cover how to build the enrollment request and response
messages.

3.1. PKIData Object be included.

The new content object PKIData has been defined for this protocol.
This new object is Simple PKI Request cannot be used as if the body private key is not
capable of producing some type of signature (i.e. DH keys can use
the signature algorithms in [DH-POP] for production of the full
signature).

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

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

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

where Extension is imported from [PKIXCERT] and ExtensionReq is
identified by:

id-cct-PKIData

id-ExtensionReq OBJECT IDENTIFIER ::= {id-pkix id-cct(12) 2 }

The ASN.1 structure corresponding {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}

Servers MUST be able to this new content type is:

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

controlSequence consists of a sequence of control attributes. The
control attributes defined process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers are not required to be able to
process other X.509v3 extensions transmitted using this document protocol, nor
are found in section
5. As control sequences they required to be able to process private extensions. Servers
are defined by OIDs, other parties can
define additional control attributes. Unrecognized OIDs not required to put all client-requested extensions into a
certificate. Servers are permitted to modify client-requested
extensions. Servers MUST
result in no part of NOT alter an extension so as to invalidate

Schaad & Myers Expires May 22, 2008 [Page 12]

Internet-Draft CMC: Structures November 2007

the request being successfully processed.

reqSequence consists of a sequence original intent of requests. The requests can be a CertificateRequest (PKCS10 request), client-requested extension. (For example,
changing key usage from keyAgreement to digitalSignature.) If a CertReqMsg or an
externally defined
certification request (orm). Details on is denied due to the first two
request types are found in sections 3.3.1 inability to handle a
requested extension and 3.3.2 respectively.
If an externally defined request message a PKI Response is present, but returned, the server does not understand MUST
return a PKI Response with a CMCFailInfo value with the request (or will not process it), value
unsupportedExt.

3.2. Full PKI Request

The Full PKI Request provides the most functionality and flexibility.

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

When a server process a Full PKI Request, a PKI Response MUST be
returned. The PKI Response returned 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 is:

Simple PKI Response if the enrollment protocol. The {OID, any} pair of values
allows for arbitrary definition of material. Data objects was successful and only
certificates are
placed here while returned. (A CMCStatusInfoV2 control objects are placed in the
controlSequence field. See section 3.7 for more details.

Schaad & Myers Expires September 3, 2006 [Page 10]

Internet-Draft CMS: Structures March 2006

Processing of this object by a recipient with
success is as follows:

1. All control attributes should be examined implied.)

Full PKI Response if the enrollment was successful and processed information
is returned in an
appropriate manner. The appropriate processing may be either addition to
do complete processing at this time, ignore certificates, if the control attribute enrollment is
pending, or to place if the control attribute on a to-do list for later
processing.

2. An implicit control attribute enrollment failed.

If SignedData is then processed for each item in used, the reqSequence. Again this may signature can be generated using either immediate processing
the private key material of an embedded signature certification
request (i.e., included in the TaggedRequest tcr or addition to a to-do list for later processing.

No processing is required for cmsSequence crm fields), or otherMsgSequence members a
previously certified signature key. If the private key of a
signature certification request used, then:

a. The certification request containing the element. If items are present and are not referenced by corresponding public key
MUST include a
control sequence, they are to be ignored.

3.2. ResponseBody Object Subject Key Identifier extension.

b. The new content object ResponseBody has been defined for this
protocol. This new object is used as the body subjectKeyIdentifier form of the full PKI
response message. The new body is identified by:

id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 } signerIdentifier in
SignerInfo MUST be used.

c. The ASN.1 structure corresponding to this body content type is:

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

controlSequence consists value of a sequence the subjectKeyIdentifier form of control attributes. The
control attributes defined in this document are found SignerInfo MUST be
the Subject Key Identifier specified in section
3.5. Other parties can define additional control attributes.

cmsSequence consists of a sequence the corresponding
certification request. (The subjectKeyIdentifier form of [CMS] message objects. This
protocol only uses EnvelopedData, SignedData, EncryptedData and
AuthenticatedData. See section 3.6 for more details.

otherMsgSequence allows
SignerInfo is used here because no certificates have yet been
issued for other arbitrary items to be placed into the enrollment protocol. The {OID, any} pair of values allows signing key.) If the request key is used for
arbitrary definition of material. Data objects are placed here
while control objects are placed
signing, there MUST be only one SignerInfo in the controlSequence field.
See section 3.7 for more details.

Processing of this object by a recipient SignedData.

If AuthenticatedData is as follows: used, then:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 11] 13]

Internet-Draft CMS: CMC: Structures March 2006

1. All control attributes should be examined and processed in an
appropriate manner. November 2007

a. The appropriate processing may Password Recipient Info option of RecipientInfo MUST be either to
do complete processing at this time, ignore the control attribute
or used.

b. A randomly generated key is used to place compute the control attribute MAC value on a to-do list the
encapsulated content.

c. The input 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 key derivation algorithm is based on the consumer a concatenation of
the element identifier (encoded as UTF8) 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 shared-secret.

When creating a
control sequence, they are PKI Request to be ignored.

3.3. Certification Requests (PKCS10/CRMF)

Certification Requests are based on either PKCS10 renew or CRMF messages.
Section 3.3.1 specifies mandatory and optional requirements for
clients and servers dealing with PKCS10 request messages. Section
3.3.2 specifies mandatory and optional requirements for clients rekey a certificate:

a. The Identification and
servers dealing with CRMF request messages.

All Identity Proof controls are absent. The
same information is provided by the use of an existing
certificate requests directly encoded into from a single PKIData
object SHOULD be for CA when signing the same identity. RAs PKI Request. In this case
the CA that batch processing
are expected to place issued the signed PKIData sequences received into original certificate and the
cmsSequence of CA the PKIData object it generates.

3.3.1. PKCS10 Request Body

Servers MUST be able to understand and process PKCS10 request bodies.
Clients MUST produce a PKCS10
request body when using is made to will usually be the Simple
Enrollment Request message. Clients MAY produce same, but could have a PKCS10 request
body when using
common operator.

b. CAs and RAs can impose additional restrictions on the Full Enrollment Request message.

When producing signing
certificate used. They may require that the most recently issued
signing certificate for a PKCS10 request body, clients client be used.

c. Some CAs may prevent renewal operations (i.e., reuse of the same
keys). In this case the CA MUST produce return a PKCS10
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 PKI Response with
noKeyReuse as the CMCFailInfo failure code.

3.2.1. PKIData content type

The PKIData content type is used 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 Full PKI Request. A PKIData
content type is returned, identified by:

id-cct-PKIData ::= {id-pkix id-cct(12) 2 }

The ASN.1 structure corresponding to the CA
MUST respond with PKIData content type is:

The fields in PKIData have the failInfo attribute following meaning:

controlSequence is a sequence of badRequest. controls. The client MAY incorporate one or more standard X.509 v3 extensions controls defined in any PKCS10 request as an ExtensionReq attribute. An ExtensionReq
attribute is
this document are found in Section 6. Controls can be defined as by
other parties. Details on the TaggedAttribute structure can be
found in Section 3.2.1.1.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 12] 14]

Internet-Draft CMS: CMC: Structures March 2006

ExtensionReq ::= SEQUENCE OF Extension

where Extension is imported from [PKIXCERT] and ExtensionReq November 2007

reqSequence is
identified by {pkcs-9 14}.

Servers MUST a sequence of certification requests. The
certification requests can be able to process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers a CertificationRequest (PKCS #10), a
CertReqMsg (CRMF) or an externally defined PKI request. Full
details are not required to be able to
process other V3 X.509 extensions transmitted using this protocol,
nor are they required to be able to process other, private
extensions. Servers are not required to put all client-requested
extensions into a certificate. Servers are permitted to modify
client-requested extensions. Servers MUST NOT alter an extension so
as to invalidate the original intent of a client-requested extension.
(For example, changing key usage from key exchange to signing.) found in Section 3.2.1.2. If a an externally defined
certification request is denied due to the inability to handle a
requested extension and a response is returned, present, but the server MUST
respond with does not
understand the failInfo attribute certification request (or will not process it), a
CMCStatus of unsupportedExt.

3.3.2. CRMF Request Body

Servers noSupport MUST be able to understand returned for the certification
request item and process CRMF no other certification request body.
Clients MAY produce are processed.

cmsSequence is a CRMF message body when using the Full
Enrollment Request message.

This memo imposes the following additional changes on the
construction and processing sequence of CRMF messages:

o When CRMF [CMS] message bodies objects. See
Section 3.2.1.3 for more details.

otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are used referred to by one or more controls. This
allows for controls to use large amounts of data without the data
being embedded in the Full Enrollment Request
message, each CRMF message MUST include both control. See Section 3.2.1.4 for more
details.

All certification requests encoded into a single PKIData SHOULD be
for the subject and
publicKey fields in same identity. RAs that batch process (see Section 6.17) are
expected to place the CertTemplate. As in PKI Requests received into the case cmsSequence of a
PKIData.

Processing of PKCS10
requests, the subject may be encoded PKIData by a recipient is as NULL, but MUST be present.

o When both CRMF and CMC follows:

1. All controls exist with equivalent
functionality, the CMC control SHOULD should be used. examined and processed in an appropriate
manner. The CMC appropriate processing is to complete processing at
this time, to ignore the control
MUST override or to place the CRMF control.

o The regInfo field MUST NOT be used control on a CRMF message. Equivalent
functionality is provided
to-do list for later processing. Controls can be processed in
any order; the regInfo control attribute
(section 5.12).

o The indirect method of proving POP order in the sequence is not supported significant.

2. Items in this
protocol. One of the other methods (including reqSequence are not referenced by a control. These
items, which are certification requests, also need to be
processed. As with controls, the direct method
described in this document) MUST appropriate processing can be used instead if POP
either immediate processing or addition to a to-do list for later
processing.

3. Finally the to-do list is
desired. The value of encrCert in SubsequentMessage MUST NOT be
used.

o Since processed. In many cases the subject to-do
list will be ordered by grouping specific tasks together.

No processing is required for cmsSequence or otherMsgSequence members
of PKIData if they are present and publicKeyValues are always present, the
POPOSigningKeyInput MUST NOT be used when computing not referenced by a control.
In this case, the value for cmsSequence and otherMsgSequence members are
ignored.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 13] 15]

Internet-Draft CMS: CMC: Structures March 2006

POPSigningKey.

A server is not required November 2007

3.2.1.1. Control Syntax

The actions to use all be performed for a PKI Request/Response are based on
the included controls. Each control consists of an object identifier
and a value based on the object identifier.

The syntax of a control is:

TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}

AttributeValue ::= ANY

The fields in TaggedAttribute have the following meaning:

bodyPartID is a unique integer that identifies this control.

attrType is the OID that identifies the control.

attrValues is the data values suggested used in processing the control. The
structure of the data is dependent on the specific control.

The final server MUST fail the processing of an entire PKIData if any
included control is not recognized, that control is not already
marked as processed by a Control Processed control (see Section 6.19)
and no other error is generated. The PKI Response MUST include a
CMCFailInfo value with the
client value badRequest and the bodyList MUST
contain the bodyPartID of the invalid or unrecognized control(s). A
server is the final server if and only if it is not passing the PKI
Request on to another server. A server is not considered to be the
final server if the server would have passed the PKI Request on, but
instead it returned a processing error.

The controls defined by this document are found in Section 6.

3.2.1.2. Certification Request Formats

Certification Requests are based on PKCS #10, CRMF or Other Request
formats. Section 3.2.1.2.1 specifies the requirements for clients
and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the
requirements for clients and servers dealing with CRMF.
Section 3.2.1.2.3 specifies the requirements for clients and servers
dealing with Other Request.

Schaad & Myers Expires May 22, 2008 [Page 16]

Internet-Draft CMC: Structures November 2007

TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}

The fields in TaggedRequest have the following meaning:

tcr is a certification request that uses the PKCS #10 syntax.
Details on PKCS #10 are found in Section 3.2.1.2.1.

crm is a certification request that uses the CRMF syntax. Details
on CRMF are found in Section 3.2.1.2.2.

orm is an externally defined certification request. One example is
an attribute certification request. The fields of this structure
are:

bodyPartID is the identifier number for this certification
request. Details on body part identifiers are found in
Section 3.2.2.

requestMessageType identifies the certificate template. Servers MUST be able to process
all extensions defined, but not prohibited in [PKIXCERT]. Servers other request type. These
values are not required to be able to process defined outside of this document.

requestMessageValue is the data associated with the other V3 X.509 extension
transmitted using request
type.

3.2.1.2.1. PKCS #10 Certification Syntax

A certification request based on PKCS #10 uses the following ASN.1
structure:

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

The fields in TaggedCertificationRequest have the following meaning:

bodyPartID is the identifier number for this protocol, nor certification request.
Details on body part identifiers are they required to be able to
process other, private extensions. Servers found in Section 3.2.2.

Schaad & Myers Expires May 22, 2008 [Page 17]

Internet-Draft CMC: Structures November 2007

certificationRequest contains the PKCS #10 based certification
request. Its fields are permitted to modify
client-requested extensions. Servers described in [PKCS10].

When producing a certification request based on PKCS #10, clients
MUST NOT alter an extension so
as to invalidate produce the original intent of certification request with a client-requested extension.
(For example change key usage from key exchange to signing.) If subject name and public
key. Some PKI products are operated using a
certificate request is denied due to the inability central repository of
information to handle assign subject names upon receipt of a
requested extension, certification
request. To accommodate this mode of operation, the server subject field in
a CertificationRequest MAY be NULL, but MUST respond be present. CAs that
receive a CertificationRequest with a failInfo
attribute of unsupportedExt.

3.3.3. Production of Diffie-Hellman Public Key Certification Requests

Part of NULL subject field MAY reject
such certification requests. If rejected and a certification request PKI Response is a signature over
returned, the request;
Diffie-Hellman is CA MUST return a key agreement algorithm and cannot be used to
directly produce the required signature object. [DH-POP] provides
two ways to produce PKI Response with the necessary signature value. This document
also defines a signature algorithm that does not provide a POP value,
but can be used to produce CMCFailInfo
value with the necessary signature value.

3.3.3.1. No-Signature Signature Mechanism

Key management (encryption/decryption) private keys cannot always be
used to produce some type of signature value as they can be in a
decrypt only device. badRequest.

3.2.1.2.2. CRMF Certification requests require that Syntax

A CRMF message uses the
signature field be populated. This section provides a signature
algorithm specifically for that purposes. The following object
identifier ASN.1 structure (defined in [CRMF]
and signature value are used to identify this signature
type:

id-alg-noSignature OBJECT IDENTIFIER included here for convenience):

CertReqMsg ::= {id-pkix id-alg(6) 2}

NoSignatureValue SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }

CertRequest ::= OCTET STRING

The parameters SEQUENCE {
certReqId INTEGER, -- ID for id-alg-noSignature MUST be present matching request and MUST be
encoded as NULL. NoSignatureValue contains the hash reply
certTemplate CertTemplate, --Selected fields of the
certification request. It is important cert to realize that there is no
security associated with this signature type. If this signature type
is be issued
controls Controls OPTIONAL } -- Attributes affecting issuance

CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }

The fields in CertReqMsg are explained in [CRMF].

This document imposes the following additional restrictions on a certification request and the Certification Authority policy
requires proof-of-possession
construction and processing of the private key, the POP mechanism
defined in section 5.7 MUST be used. CRMF certification requests:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 14] 18]

Internet-Draft CMS: CMC: Structures March 2006

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

CMC compliant implementations MAY support section 3 of [DH-POP].

3.4. Body Part Identifiers

Each element of November 2007

When a PKIData or PKIResponse message has an associated
body part identifier. The body part identifier is Full PKI Request includes a 4-octet integer
encoded in CRMF certification request,
both the certReqIds field for CertReqMsg objects (in a
TaggedRequest) or subject and publicKey fields in the bodyPartID CertTemplate MUST be
defined. The subject field of can be encoded as NULL, but MUST be
present.

When both CRMF and CMC controls exist with equivalent
functionality, the other objects. CMC control SHOULD be used. The
body part identifier CMC control
MUST override the CRMF control.

The regInfo field MUST NOT be unique within used on a single PKIData or
PKIResponse object. Body part identifiers can be duplicated CRMF certification
request. Equivalent functionality is provided in
different layers (for example a the CMC message embedded within another). regInfo
control (Section 6.12).

The body part Identifier indirect method of zero proving POP is reserved 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 designate use all of the current
PKIData object. This value is used in control attributes such as values suggested by the
Add Extensions Control
client in the pkiDataReference field to refer CRMF certification request. Servers MUST be able to a
request
process all extensions defined, but not prohibited in the current PKIData object.

Some control attribute, such as the CMC Status Info attribute, will
also use body part identifiers [PKIXCERT].
Servers are not required to refer be able to elements in the previous
message. This allows an error process other X.509v3
extension transmitted using this protocol, nor are they required to
be explicit about the attribute or
request able to which process private extensions. Servers are permitted to
modify client-requested extensions. Servers MUST NOT alter an
extension so as to invalidate the error applies.

3.5. Control Attributes

The overall control flow original intent of how a message is processed in this
document client-
requested extension. (For example change key usage from keyAgreement
to digitalSignature.) If a certification request is based on denied due to
the control attributes. Each control attribute
consists of an object identifier and inability to handle a value based on requested extension, the object
identifier.

The final server MUST fail
respond with a Full PKI Response with a CMCFailInfo value with the processing
value of an entire PKIData
message if any included control attribute is not recognized and that
control is not already marked as processed by id-cmc-
controlProcessed. The response MUST unsupportedExt.

3.2.1.2.3. Other Certification Request

This document allows for other certification request formats to be the error badRequest and
bodyList MUST contain the bodyPartID of the invalid or unrecognized
control attribute(s). A server is the final server if
defined and only if
(1) it used as well. An example of an other certification
request format is not generating a error response one for another reason Attribute Certificates. These other
certification request formats are defined by specifying an OID for
identification and (2)
it is not going the structure to process and pass contain the request on data to another server
for processing.

The syntax of a control attribute is be passed.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 15] 19]

Internet-Draft CMS: CMC: Structures March 2006

TaggedAttribute November 2007

3.2.1.3. Content Info Objects

The cmsSequence field of the PKIData and PKIResponse messages
contains zero or more tagged content info objects. The syntax for
this structure is:

TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
contentInfo ContentInfo
}

The fields in TaggedContentInfo have the following meaning:

bodyPartID is a unique integer that is used to reference identifies this control
attribute. The id of 0 is reserved for use as the reference to
the current PKIData content info
object.

attrType

contentInfo is the OID defining the associated data a ContentInfo object (defined in attrValues

attrValues contains the set of data values [CMS]).

The four content types used in processing the
control attribute.

The set cmsSequence are AuthenticatedData,
Data, EnvelopedData and SignedData. All of control attributes that these content types are
defined by this memo are found in section 5.

3.6. Content Info objects [CMS].

3.2.1.3.1. Authenticated Data

The cmsSequence field AuthenticatedData content type provides a method of doing pre-
shared secret based validation of data being sent between two
parties. Unlike SignedData it does not specify which party actually
generated the PKIRequest and PKIResponse messages
contains zero or more tagged content info objects. The syntax information.

AuthenticatedData provides origination authentication in those
circumstances where a shared-secret exists, but a PKI based trust has
not yet been established. No PKI based trust may have been
established because a trust anchors has not been installed on the
client or no certificate exists for
this structure is

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

bodyPartID is a unique integer that signing key.

AuthenticatedData content type is used to reference by this content
info object. document for:

The id of 0 id-cmc-authData control (Section 6.16), and

As the top-level wrapper in environments where an encryption only
key is reserved for use being certified.

This content type can include both PKIData and PKIResponse as the reference
encapsulated content types. These embedded content types can contain
additional controls that need to
the current PKIData object.

contentInfo contains a ContentInfo object (defined in [CMS]). be processed.

Schaad & Myers Expires May 22, 2008 [Page 20]

Internet-Draft CMC: Structures November 2007

3.2.1.3.2. Data

The four contents used in this location are SignedData,
EnvelopedData, AuthenticatedData and Data.

EnvelopedData provides for shrouding of data. Data content type allows for general transport of unstructured
data.

SignedData object from [CMS]

The Data content type is also used by this document for:

Holding the encrypted random value y for POP proof in the
encrypted POP control (see Section 6.7).

3.2.1.3.3. Enveloped Data

The EnvelopedData content type provides for shrouding of data.

The EnvelopedData content type is the primary confidentiality method
for sensitive information in this specification to protocol. EnvelopedData can
provide encryption of an entire PKI Request (see Section 5).
EnvelopedData can also be used to wrap private key material for authentication as well as serving as key
archival. If the general
transport wrapper decryption on an EnvelopedData fails, the Full PKI
Response with a CMCFailInfo value with a value of requests badMessageCheck and responses.

Schaad & Myers Expires September 3, 2006 [Page 16]

Internet-Draft CMS: Structures March 2006

AuthenticatedData provides
a method of doing pass phrase based
validation bodyPartId of data being sent between two parties. Unlike
SignedData it does not specify which party actually generated the
information.

3.6.1. 0.

3.2.1.3.4. Signed Data

The signedData object is used in two different locations when
constructing enrollment messages. SignedData content type provides for authentication and
integrity.

The signedData object SignedData content type is used as a by this document for:

The outer wrapper for a PKIData as part of the enrollment request message. PKI Request.

The
signedData object is also used as the outer part of an enrollment
response message. wrapper for a PKI Response.

As part of processing a message PKI Request/Response, the signature(s) MUST
be verified. If the signature does not verify, verify and the body PKI Request/
Response contains anything other than a status response, CMC Status Info control, a new message
Full PKI Response containing a status
response CMC Status Info control MUST be
returned using a CMCFailInfo with a value of badMessageCheck and a bodyPart
bodyPartId of 0.

For the enrollment response the signedData wrapper PKI Response, SignedData allows the server to sign the
returning data, if any exists, and to carry the certificates and CRLs for
corresponding to the enrollment request. PKI Request. If no data is being returned
beyond the certificates, no signerInfo objects are
placed in the signedData object.

3.6.2. Enveloped Data

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 certificates 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 CRLs, 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 EncapsulatedInfo and SignerInfo
fields are not yet been established. This is currently only used for
the id-cmc-authData 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. populated.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 17] 21]

Internet-Draft CMS: CMC: Structures March 2006

3.7. November 2007

3.2.1.4. Other Message Bodies

The other message body portion otherMsgSequence field of the message PKI Request/Response allows for
arbitrary data objects to be carried as part of a message. PKI Request/
Response. This is intended to contain a data object that is not
already wrapped in a CMS contentInfo object. cmsSequence field Section 3.2.1.3. The data
object is ignored unless a control attribute references the data object by
bodyPartID.

OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }

The fields in OtherMsg have the following meaning:

bodyPartID contains is the unique id of identifying this object data object.

otherMsgType contains is the OID defining both that defines the usage type of this message body

otherMsgValue is the data.

3.2.2. Body Part Identification

Each element of a PKIData or PKIResponse has an associated body part and
identifier. The body part identifier is a 4-octet integer using the syntax
ASN.1 of:

bodyIdMax INTEGER ::= 4294967295

BodyPartID ::= INTEGER(0..bodyIdMax)

Body part identifiers are encoded in the certReqIds field for
CertReqMsg objects (in a TaggedRequest) or in the bodyPartID field of
the other objects. The body part identifier MUST be unique within a
single PKIData or PKIResponse. Body part identifiers can be
duplicated in different layers (for example a PKIData embedded within
another).

The bodyPartId value associated with this of 0 is reserved for use as the reference to the
current PKIData object.

Some controls, such as the Add Extensions control (Section 6.5.2) use
the body part

otherMsgValue identifier in the pkiDataReference field to refer to a
PKI Request in the current PKIData. Some controls, such as the
Extended CMC Status Info control (Section 6.1.1), will also use body
part identifiers to refer to elements in the previous PKI Request/
Response. This allows an error to be explicit about the control or

Schaad & Myers Expires May 22, 2008 [Page 22]

Internet-Draft CMC: Structures November 2007

PKI Request to which the error applies.

A BodyPartList contains a list of body parts in a PKI Request/
Response (i.e. the data associated with Batch Request control in Section 6.17). The ASN.1
type BodyPartList is defined as:

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

A BodyPartPath contains a path of body part identifiers moving
through nesting (i.e. the message body
part.

3.8. Modify Certificate Request control in
Section 6.5.1). The ASN.1 type BodyPartPath is defined as:

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

3.2.3. CMC Unsigned Attributes Data Attribute

There is sometimes a need to include data in an enrollment message a PKI Request designed
to be removed by an RA during processing. An example of this is the
inclusion of an encrypted private key, where a key archive agent
removes the encrypted private key before sending it on to the CA.
One side effect of this desire is the fact that every RA which encapsulates
this information needs to move the data so that it is not covered by the RA
that RA's signature. (A client request, PKI Request, encapsulated by an RA
cannot have the unsigned attribute a signed control 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-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}

CMCUnsignedData ::= SEQUENCE {
bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}

Schaad & Myers Expires September 3, 2006 [Page 18]

Internet-Draft CMS: Structures March 2006

There MUST be at most one CMCUnsignedData attribute in the
UnsignedAttribute sequence of a SignerInfo structure. The attribute
can have any number of attribute values greater than zero. 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(s).

Schaad & Myers Expires September 3, 2006 [Page 19]

Internet-Draft CMS: Structures March 2006

4. PKI Messages

This section discusses the details of putting together the different
enrollment request and response messages.

4.1. Simple Enrollment Request

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,
breaking the PKCS10 MUST be signed with
that private key. If RA's signature.) The CMC Unsigned Data attribute
addresses this form of the enrollment request problem.

The CMC Unsigned Data attribute contains information that is used for not
directly signed by a D-H key, then the D-H POP mechanism described client. When an RA encounters this attribute in [DH-POP] MUST be
used.

Servers MUST support
the Simple Enrollment Request message. If the
Simple Enrollment Request message unsigned or unauthenticated attribute field of a request it is used, servers MUST return the
Simple Enrollment Response message (see Section 4.3) if
aggregating, the
enrollment request CMC Unsigned Data attribute is granted. If removed from 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-of-
identity needs prior to be included.

Many advanced services specified placing it in this memo are not supported by
the Simple Enrollment Request message.

4.2. Full PKI Request

The Full Enrollment Request provides the most functionality a cmsSequence and
flexibility. Clients SHOULD use placed in the Full Enrollment Request message
when enrolling. Servers MUST support
unsigned or unauthenticated attributes of the Full Enrollment Request
message. An enrollment response (full RA's signed or simple as appropriate) MUST
be returned to all Full Enrollment Requests.
authenticated data wrapper.

The Full Enrollment Request message consists of a PKIData object
wrapped in a signedData CMS object. CMC Unsigned Data attribute is identified by:

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

The objects in CMC Unsigned Data attribute has the PKIData are
ordered as follows:

1. All Control Attributes,

2. All certification requests,

3. All CMS objects,

4. All other messages.

Each object ASN.1 definition:

CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}

The fields in CMCUnsignedData have the PKIData sequence is identified by a Body Part following meaning:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 20] 23]

Internet-Draft CMS: CMC: Structures March 2006

Identifier. If duplicate ids are found, November 2007

bodyPartPath is the server MUST return path pointing to the
error badRequest control associated with a bodyPartID
this data. When an RA moves the control in an unsigned or
unauthenticated attribute up one level as part of 0.

The signedData object wrapping the PKIData may be signed either by
data in a new SignedData or AuthenticatedData, the private key material body part
identifier of the signature certification request, or
by a previously certified signature key. If embedded item in the private key of a
signature certification request PKIData is being used, then: pre-pended to
the certification request containing bodyPartPath sequence.

identifier is the corresponding public key
MUST include a Subject Key Identifier extension, OID that defines the subjectKeyIdentifier form of signerInfo associated data.

content is the data.

There MUST be used, and at most one CMC Unsigned Data attribute in the value
UnsignedAttribute sequence of a SignerInfo or in the subjectKeyIdentifier form
UnauthenticatedAttribute sequence of an AuthenticatedData.
UnsignedAttribute consists of a set of values, the attribute can have
any number of signerInfo values greater than zero in that set. If the CMC
Unsigned Data attribute is in one SignerInfo or AuthenticatedData, it
MUST be appear with the Subject Key Identifier specified same values(s) in all SignerInfo and
AuthenticatedData items.

Schaad & Myers Expires May 22, 2008 [Page 24]

Internet-Draft CMC: Structures November 2007

4. PKI Responses

Two types of PKI Responses exist. This section gives the corresponding
certification request.

(The subjectKeyIdentifier form details on
both types.

4.1. Simple PKI Response

Clients MUST be able to process the Simple PKI Response. The Simple
PKI Response consists of signerInfo is used here because a SignedData with no EncapsulatedContentInfo
and no SignerInfo. The certificates have yet been issued for requested in the signing key.) If PKI Response
are returned in the
request key is used for signing, there certificate field of the SignedData.

Clients MUST be only NOT assume the certificates are in any order. Servers
SHOULD include all intermediate certificates needed to form complete
certification paths to one signerInfo
object or more trust anchors, not just the newly
issued certificate(s). The server MAY additionally return CRLs in
the signedData object.

When creating a message CRL bag. Servers MAY include the self-signed certificates.
Clients MUST NOT implicitly trust included self-signed certificate(s)
merely due to renew a certificate, its presence in the following should
be taken into consideration:

1. The identification and identityProof control statements are not
required. The same information is provided by certificate bag. In the use of an
existing event
clients receive a new self-signed certificate from the CA when signing server,
clients SHOULD provide a mechanism to enable the enrollment
message.

2. CAs and LRAs may impose additional restrictions on user to use the signing
certificate used. They may require as a trust anchor. (The Publish Trust Anchors control
Section 6.15 should be used in the event that the most recently issued
signing certificate for an entity be used.

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 server intends the CA MUST return
NOKEYREUSE
client to accept one or more certificates as trust anchors. This
requires the failure code.

4.3. Simple Enrollment Response

Servers SHOULD use of the simple enrollment response message whenever
possible. Full PKI Response message.)

4.2. Full PKI Response

Clients MUST be able to process the simple enrollment
response message. a Full PKI Response.

The simple enrollment response message Full PKI Response consists of a signedData object with no signerInfo objects on it. SignedData encapsulating a
PKIResponse content type. The certificates requested issued in a PKI Response
are returned in the certificate bag certificates field of the
signedData object.

Schaad & Myers Expires September 3, 2006 [Page 21]

Internet-Draft CMS: Structures March 2006 immediately
encapsulating SignedData.

Clients MUST NOT assume the certificates are in any order. Servers
SHOULD include all intermediate certificates needed to form complete
chains to one or more trust anchors, not just the newly issued
certificate(s). The server MAY additionally return CRLs in the CRL
bag. Servers MAY include 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 MAY provide a
mechanism to enable the user to explicitly trust use the certificate.

4.4. Full PKI Response

Servers MUST return full PKI response messages if a) certificate as a full PKI
request message failed or b) additional services other than returning
certificates are required. Servers MAY return full PKI responses
with failure information
trust anchor. (The Publish Trust Anchors control Section 6.15 exists
for simple PKI requests. Following section
4.3 above, servers returning only certificates and a success status
to the client SHOULD use purpose of allowing for distribution of trust anchor
certificates. If a trusted anchor publishes a new trusted anchor,
this is one case where automated trust of the simple PKI response message.

Clients MUST new trust anchor could

Schaad & Myers Expires May 22, 2008 [Page 25]

Internet-Draft CMC: Structures November 2007

be able to process a full allowed.)

4.2.1. PKIResponse Content Type

The PKIResponse content type is used for the Full PKI response message. Response. The full enrollment response message consists of a signedData object
encapsulating a responseBody object.
PKIResponse content type is identified by:

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

The ASN.1 structure corresponding to the PKIResponse content type is:

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

ReponseBody ::= PKIResponse

Note: In [RFC2797], this ASN.1 type was named ResponseBody. It has
been renamed to PKIResponse for clarity and the old name kept as a responseBody object all
Control Attributes MUST precede all CMS objects.
synonym.

The fields in PKIResponse have the following meaning:

controlSequence is a sequence of controls. The certificates
granted controls defined in an enrollment response
this document are returned found in Section 6. Controls can be defined by
other parties. Details on the certificates
field of the immediately encapsulating signedData object.

Clients MUST NOT assume the certificates TaggedAttribute structure are found
in any order. Servers
SHOULD include all intermediate certificates needed Section 3.2.1.1.

cmsSequence is a sequence of [CMS] message objects. See
Section 3.2.1.3 for more details.

otherMsgSequence is a sequence of arbitrary data objects. Data
objects placed here are referred to form complete
chains by one or more trust anchors, not just the newly issued
certificate(s). The server MAY additionally return CRLs in the CRL
bag. Servers MAY include the self-signed certificates. Clients MUST
NOT implicitly trust included self-signed certificate(s) merely due controls. This
allows for controls to its presence in the certificate bag. In use large amounts of data without the event clients receive
a new self-signed certificate from data
being embedded in the server, clients SHOULD provide control. See Section 3.2.1.4 for more
details.

Processing of PKIResponse by a mechanism recipient is as follows:

1. All controls should be examined and processed in an appropriate
manner. The appropriate processing is to enable complete processing at
this time, to ignore the user control or to explicitly trust place the certificate.
(The publish trust root control exists on a
to-do list for later processing.

2. Additional processing of non-element items includes the purpose saving of allowing
certificates and CRLs present in wrapping layers. This type of

Schaad & Myers Expires May 22, 2008 [Page 26]

Internet-Draft CMC: Structures November 2007

processing is based on the consumer of the element and should not
be relied on by generators.

No processing is required for distribution cmsSequence or otherMsgSequence members
of root certificates. If a trusted root publishes the PKIResponse, if items are present and are not referenced by a
new trusted root,
control. In this is one case where automated trust of case, the new
root could cmsSequence and otherMsgSequence members
are to be allowed.)

4.5. ignored.

Schaad & Myers Expires May 22, 2008 [Page 27]

Internet-Draft CMC: Structures November 2007

5. Application of Encryption to a PKI Message Request/Response

There are occasions where when a PKI request Request or response message Response must be encrypted
in order to prevent any disclosure of information about in the enrollment PKI Request/
Response from being accessible to unauthorized entities. This
section describes the means used to encrypt a Full PKI message. This section is
not applicable to a simple enrollment message.

Schaad & Myers Expires September 3, 2006 [Page 22]

Internet-Draft CMS: Structures March 2006 Requests and
Responses (Simple PKI Requests cannot be encrypted). Data portions
of PKI Requests and Responses that are placed in the cmsSequence
field can be encrypted separately.

Confidentiality is provided by wrapping the PKI message Request/Response (a signedData
object)
SignedData) in a CMS EnvelopedData object. an EnvelopedData. The nested content type in the
EnvelopedData is id-signedData. id-SignedData. Note that this is different from
S/MIME where there is a MIME layer placed between the encrypted and
signed data objects. data. It is recommended that if an enveloped data EnvelopedData layer is
applied to a PKI message, Request/Response, a second signing signature layer be placed
outside of the enveloped data EnvelopedData layer. The following figure shows how
this nesting would be done:

Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIData

Note: PKIResponse can be substituted for PKIData in the above figure.

Options 1 and 2 provide the benefit of preventing prevent leakage of sensitive data by encrypting the information. LRAs
Full PKI Request/Response. An RA that receives a PKI Request that it
cannot decrypt MAY reject the PKI Request unless it can remove process the
enveloped data wrapping, and replace or forward
PKI Request without further
processing. knowledge of the contents (i.e., all it does is
amalgamate multiple PKI Requests and forwards them to a server).
After the RA removes the envelope and completes processing, it may
then apply a new EnvelopedData layer to protect PKI Requests for
transmission to the next processing agent. Section 6 7 contains more
information about LRA RA processing.

Full PKI Messages MAY Requests/Responses can be encrypted or transmitted in the
clear. Servers MUST provided support for all three versions. options.

Alternatively, an authenticated, secure channel could exist between
the parties requiring encryption. that require confidentiality. Clients and servers MAY
use such channels instead of the technique described above to provide
secure, private communication of PKI request Simple and response messages. Full PKI Requests/
Responses.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 23] 28]

Internet-Draft CMS: CMC: Structures March 2006

5. Control Attributes

Control attributes November 2007

6. Controls

Controls are carried as part of both Full PKI requests Requests and
responses. Responses.
Each control attribute is encoded as a unique Object
Identifier OID followed by that the data for the
control attribute. (see syntax in Section 3.2.1.1. The encoding of the data is
based on the control attribute object
identifier. control. Processing systems would first detect the OID
(TaggedAttribute attrType) and process the corresponding attribute control
value (TaggedAttribute attrValues) prior to processing the message
body.

The OIDs are all defined under the following arc:

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

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

The following table lists the names, OID and syntactic structure for
each of the control attributes documented controls described in this memo. document.

Schaad & Myers Expires May 22, 2008 [Page 29]

Internet-Draft CMC: Structures November 2007

Schaad & Myers Expires May 22, 2008 [Page 30]

Internet-Draft CMC: Structures November 2007

5.1. | Section 6.5.1 |
| | c31 | | |
| | | | |
| id-cmc-controlProcesse | id-cm | ControlsProcesse | Section 6.19 |
| d | c32 | d | |
| | | | |
| id-cmc-identityProof | id-cm | IdentityProofV2 | Section 6.2.2 |
| | c33 | | |
+------------------------+-------+------------------+---------------+

Table 1: CMC Status Info Control Attributes

6.1. CMC Status Info Controls

The CMC status info control is used in full PKI Response messages to Status Info controls return information about the processing status of a client request.
client/server request/response. Two

Schaad & Myers Expires September 3, 2006 [Page 24]

Internet-Draft CMS: Structures March 2006 controls are described in this
section. The first Extended CMC Status Info control is the preferred
control; the second CMC Status Info control is included for backwards
compatibility with RFC 2797.

Servers MAY emit multiple CMC status info controls referring to a
single body part. Clients MUST be able to deal with multiple CMC
status info controls in a response message. PKI Response. Servers MUST use the
CMCStatusInfoEx
Extended CMC Status Info control, but MAY additionally use the CMCStatusInfo CMC
Status Info control. Clients MUST be able to process the CMCStatusInfoEx Extended
CMC Status Info control.

5.1.1.

6.1.1. Extended CMC Status Info Control Attribute

This

The Extended CMC Status Info control uses is identified by the OID:

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

The Extended CMC Status Info control has the following ASN.1 definition:

CMCStatusInfoEx

Schaad & Myers Expires May 22, 2008 [Page 31]

Internet-Draft CMC: Structures November 2007

CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}

OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}

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

ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue }
} OPTIONAL ANY DEFINED BY failInfoOID
}

BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID
}

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

cMCStatus is described

The fields in section 5.1.3

bodyList CMCStatusInfoV2 have the following meaning:

cMCStatus contains the list of references to body parts returned status value. Details are in
Section 6.1.3.

bodyList identifies the request
message controls or other elements to which this the
status information value applies. If an error is
being returned for a simple enrollment message, body list will
contain a Simple PKI
Request, this field is the bodyPartID choice of BodyPartReference
with the single integer of value '1'.

Schaad & Myers Expires September 3, 2006 [Page 25]

Internet-Draft CMS: Structures March 2006 1.

statusString contains a string with additional description information. This
string is human readable.

otherInfo contains additional information that expands on the CMC
status code returned in the cMCStatus field.

The fields in OtherStatusInfo have the following meaning:

Schaad & Myers Expires May 22, 2008 [Page 32]

Internet-Draft CMC: Structures November 2007

failInfo is described in section 5.1.4. Section 6.1.4. It provides a detailed an error
on code
that details what the failure was. occurred. This choice is present only
if cMCStatus
is contains the value failed.

extendedFailInfo is provided

pendInfo contains information about when and how the client should
request for other users the result of this request. It is present when the enrollment
protocol
cMCStatus is either pending or partial. pendInfo uses the
structure PendInfo, which has the fields:

pendToken is the token used in the Query Pending control
Section 6.13.

pendTime contains the suggested time the server wants to provided their own be
queried about the status of the certification request.

extendedFailInfo includes application dependent detail error codes.
information. This choice is present only if cMCStatus is contains
the value failed. Caution should be used in when defining new values
as they may not be correctly recognized by all clients and
servers. The failInfo CMCFailInfo value of internalCA error internalCAError may be assumed
if the extended error is not recognized.

pendToken is This field uses the token to be used in type
ExtendedFailInfo. ExtendedFailInfo has the queryPending control
attribute.

pendTime fields:

failInfoOID contains the suggested time the server wants to be queried
about the status an OID that is associated with a set of
extended error values.

failInfoValue contains an extended error code from the request. defined
set of extended error codes.

If the cMCStatus field is success, the Extended CMC Status Info Control
control MAY be omitted unless it is the only item in the response message. If no status
exists for a certificate request or other item requiring processing,
then the value of success response.

6.1.2. CMC Status Info Control

The CMC Status Info control is to be assumed.

5.1.2. identified by the OID:

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

The CMC Status Info Control Attribute

The CMC status info control is used in full PKI Response messages to
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 has the following ASN.1 definition:

CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID, BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}

cMCStatus is described in section 5.1.3

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 26] 33]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

The fields in CMCStatusInfo have the following meaning:

cMCStatus contains the returned status value. Details are in
Section 6.1.3.

bodyList contains the list of body parts in the request message controls or other element to which this the
status information value applies. If an error is being returned for a simple enrollment message, body list will contain Simple
PKI Request, this field contains a single integer of value '1'. 1.

statusString contains a string with additional description information. This
string is human readable.

otherInfo provides additional information that expands on the CMC
status code returned in the cMCStatus field.

failInfo is described in section 5.1.4. Section 6.1.4. It provides a detailed an error
on
code that details what the failure was. occurred. This choice is
present only if cMCStatus is failed.

pendInfo uses the PendInfo ASN.1 structure in Section 6.1.1. It
contains information about when and how the client should
request for results on this request. The pendInfo field MUST
be populated for a cMCStatus value of pending or partial.
Further details can be found in Section 6.1.1 (Extended CMC
Status Info Control) and Section 6.13 (Query Pending Control).

If the cMCStatus field is success, the CMC Status Info Control control MAY be
omitted unless if it is the only item in the response message. response. If no status exists
for a certificate request Simple or other item requiring processing, Full PKI Request, then the value of success is to be
assumed.

5.1.3.

6.1.3. CMCStatus values

CMCStatus is a field in the CMCStatusInfo structure. Extended CMC Status Info and CMC Status
Info controls. This field contains a code representing the success
or failure of a specific
operation. a specific operation. CMCStatus has the ASN.1
structure:

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

Schaad & Myers Expires May 22, 2008 [Page 34]

Internet-Draft CMC: Structures November 2007

The values of CMCStatus has have the ASN.1 structure of:

CMCStatus ::= INTEGER { following meaning:

success (0),
-- indicates the request was granted
-- reserved (1),
-- not used, defined where or the original structure action was defined
completed.

failed (2),
-- you don't get what you want, more indicates the request was not granted or the action was not
completed. More information is included elsewhere in the
message
response.

pending (3),
-- indicates the request body part PKI Request has not yet been processed,
-- requester to be processed. The
requestor is responsible to poll back on this
-- Full PKI request.
pending may only be return returned for certificate a certification request
operations.

noSupport (4),
-- indicates the requested operation is not supported supported.

confirmRequired (5),
-- conformation using the confirmCertAcceptance indicates a Confirm Certificate Acceptance control is
required
--
Section 6.14 must be returned before use of the certificate can be used.

popRequired (6)
-- A certificate requires indicates an indirect POP operation.
-- Info operation is required
Section 6.3.1.3.

partial indicates a partial PKI Response is returned. The requestor
is responsible to poll back for the indirect POP in this message.
}

5.1.4. unfulfilled portions of the
Full PKI Request.

6.1.4. CMCFailInfo

CMCFailInfo is a field in the Extended CMC Status Info and CMC Status
Info controls. CMCFailInfo conveys more detailed information
relevant to the interpretation of a failure condition. The
CMCFailInfo has the following ASN.1 structure:

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

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 27] 35]

Internet-Draft CMS: CMC: Structures March 2006

structure: November 2007

}

The values of CMCFailInfo ::= INTEGER { have the following meanings:

badAlg (0),
-- Unrecognized indicates unrecognized or unsupported algorithm algorithm.

badMessageCheck (1),
-- indicates integrity check failed failed.

badRequest (2),
-- indicates transaction not permitted or supported supported.

badTime (3),
-- Message indicates message time field was not sufficiently close to
the system
time time.

badCertId (4),
-- No indicates no certificate could be identified matching the
provided
criteria criteria.

unsuportedExt (5),
-- A indicates a requested X.509 extension is not supported
by the recipient CA.

mustArchiveKeys (6),
-- Private indicates private key material must be supplied supplied.

badIdentity (7),
-- Identification Attribute indicates identification control failed to verify verify.

popRequired (8),
-- Server indicates server requires a POP proof before issuing certificate
certificate.

popFailed (9),
-- indicates POP processing failed failed.

noKeyReuse (10),
-- Server indicates server policy does not allow key re-use reuse.

internalCAError (11), indicates that the CA had an unknown internal
failure.

tryLater (12), indicates that the server is not accepting requests at this
time and the client should try at a later time.

authDataFail (13)
-- Failure indicates failure occurred during processing of
authenticated data
}

Additional failure reasons MAY be defined for closed environments
with a need.

If additional failure reasons are needed, this they SHOULD
be done by using an use the
ExtendedFailureInfo item in the Extended Fail CMC Status Info item control.
However for closed environments they can be defined using this type.
Such codes MUST be in the CMCStatusInfoEx
structure.

5.2. range from 1000 to 1999.

6.2. Identification and IdentityProof Control Attributes Identity Proof Controls

Some CAs and LRAs RAs require that a proof of identity proof-of-identity be included in a
certification request. Many different ways of doing this exist with

Schaad & Myers Expires May 22, 2008 [Page 36]

Internet-Draft CMC: Structures November 2007

different degrees of security and reliability. Most people are familiar
with the request of a bank bank's request to provide your mother's maiden name as a form
of identity proof. The reasoning behind requiring a proof-of-
identity can be found in Appendix C of [CRMF].

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

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

6.2.1. Identity Proof Version 2 Control

The Identity Proof Version 2 control is identified by the OID:

id-cmc-identityProofV2 ::= { id-cmc 33 }

The Identity Proof Version 2 control has the ASN.1 definition:

IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}

The fields of IdentityProofV2 have the following meaning:

hashAlgID is the identifier and parameters for the hash algorithm
used to convert the shared-secret into a key for the certificate requestor MAC
algorithm.

macAlgID is the identifier and the verifying
authority. If clients support full request messages, clients MUST
implement this method parameters for the message
authentication code algorithm used to compute the value of the
witness field.

witness is the identity proof. Servers MUST provide this

Schaad & Myers Expires September 3, 2006 [Page 28]

Internet-Draft CMS: Structures March 2006

method and MAY also have bilateral methods of similar strength
available.

The CMC required method starts with an out-of-band transfer of a token
(the
shared secret). 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

Schaad & Myers Expires May 22, 2008 [Page 37]

Internet-Draft CMC: Structures November 2007

as follows:

1. The PKIData reqSequence field of the PKIData object (encoded exactly as it appears in
the request message Full PKI Request including the sequence type and length) is
the value to be validated.

2. A SHA1 hash of the token shared-secret as a UTF8 string is computed. computed using
hashAlgID.

3. An HMAC-SHA1 value A MAC is then computed over using the value produced in Step 1, 1 as described in [HMAC], using the hash of
message and the token value from Step 2 as the shared secret value. key.

4. The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the witness value of in
the identityProof attribute. Identity Proof Version 2 control.

When the server verifies the identityProof attribute, Identity Proof Version 2 control, it
computes the
HMAC-SHA1 MAC value in the same way and compares it to the identityProof
attribute witness
value contained in the enrollment request. PKI Request.

If a server fails the verification of an identityProof attribute and
the server returns a response message, Identity Proof Version 2
control, the failInfo attribute CMCFailInfo value MUST be present in the response Full PKI
Response and MUST have a value of badIdentity.

Reuse of the shared-secret on enrollment certification request retries makes it easier for allows
the client and server to prevent getting out maintain the same view of sync. acceptable
identity proof values. However, reuse of the shared-secret can
potentially open the door for some types of attacks.

Implementations MUST be able to support tokens at least 16 characters
long. Guidance on the amount of entropy actually obtained from a
given length token based on character sets can be found in Appendix A
of [PASSWORD].

6.2.2. Identity Proof Control

The Identity Proof control is identified by the OID:

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

The Identity Proof control has the ASN.1 definition:

IdentifyProof ::= OCTET STRING

This control is process in the same way as the Identity Proof Version
2 control. In this case the hash algorithm is fixed to SHA-1 and the
MAC algorithm is fixed to HMAC-SHA1.

Schaad & Myers Expires May 22, 2008 [Page 38]

Internet-Draft CMC: Structures November 2007

6.2.3. Identification Control

Optionally, servers MAY require the inclusion of the unprotected
identification attribute
Identification control with an identification attribute. Identification Proof control. The
identification attribute
Identification control is intended to contain either a text string
or a numeric quantity, such as a random number, which
assists the server in locating the shared secret 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. Identity Proof control. If the identification Identification
control attribute is included in the message, Full PKI Request, the derivation of the shared secret
key in step 2 (from Section 6.2.1 is altered so that the hash of the
concatenation of the token shared-secret and the UTF8
encoded identity value
(without the type and length bytes) identity value are hashed rather than just the token.

Schaad & Myers Expires September 3, 2006 [Page 29]

Internet-Draft CMS: Structures March 2006

5.2.1.
shared-secret.

The Identification control is identified by the OID:

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

The Identification control has the ASN.1 definition:

Identification ::= UTF8String

6.2.4. Hardware Shared Secret Shared-Secret Token Generation

The shared secret shared-secret between the end-entity EE and the identity verify server is sometimes transferred computed
using a hardware device that generates a series of tokens based on some shared secret value. tokens. The user EE
can therefore prove their identity by transferring this token in
plain text along with a name string. The above protocol can be used
with a hardware shared-secret token generation device by the
following modifications:

1. The identification attribute Identification control MUST be included and MUST contain the
hardware-generated token.

2. The shared secret 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.

4. The entire certification request MUST be shrouded in some fashion
to prevent eavesdropping. Although the token is time critical,
an active eavesdropper cannot be permitted to extract the token
and submit a different certification request with the same token
value.

Schaad & Myers Expires May 22, 2008 [Page 39]

Internet-Draft CMC: Structures November 2007

6.3. Linking Identity and POP Information

In a PKI Full Request message PKI Request, identity information about the creator/
author of the message client is
carried in the signature of the CMS SignedData object containing all of the certificate
certification requests. Proof-
of-possession Proof-of-possession information for key pairs requesting certification,
pairs, however, is carried separately for each PKCS#10 PKCS #10 or CRMF message.
certification request. (For keys capable of generating a digital
signature, the POP is provided by the signature on the PKCS#10 PKCS #10 or
CRMF request. For encryption-only keys the controls described in
Section 5.7 below 6.7 are used.) In order to prevent substitution-style attacks we
attacks, the protocol must guarantee that the same entity generated
both the POP and proof-of-
identity proof-of-identity information.

This section describes two mechanisms for linking identity and POP
information: witness values cryptographically derived from the
shared-secret (Section 5.3.1) 6.3.1.3) and shared-secret/subject DN matching
(Section 5.3.2). 6.3.2). Clients and servers MUST support the witness value
technique. Clients and servers MAY support shared-secret/subject DN
matching or other bilateral techniques of similar strength. The idea
behind both mechanisms is to force the client to sign some data into
each certificate certification request that can be directly associated with the
shared-secret; this will defeat attempts to include certificate certification
requests from different entities in a single Full PKI Request
message.

5.3.1. Witness values Request.

6.3.1. Cryptographic Linkage

The first technique that links identity and POP information forces
the client to include a piece of information cryptographically-
derived from the shared-secret as a signed extension within each
certification request (PKCS #10 or CRMF).

6.3.1.1. POP Link Witness Version 2 Controls

The POP Link Witness Version 2 control is identified by the OIDs:

id-cmc-popLinkWitnessV2 ::= { id-cmc XX }

The POP Link Witness Version 2 control has the ASN.1 definition:

PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}

The first technique for doing identity-POP linking works by forcing fields of PopLinkWitnessV2 have the meaning:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 30] 40]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

keyGenAlgorithm contains the client algorithm used to include a piece of information cryptographically-
derived from generate the shared-secret token as key for
the MAC algorithm. This will generally be a signed extension within
each certificate request (PKCS#10 or CRMF) message. hash algorithm, but
could be a more complex algorithm.

macAlgorithm contains the algorithm used to create the witness
value.

witness contains the computed witness value.

This technique is useful if null subject DNs are used (because, for
example, the server can generate the subject DN for the certificate
based only on the shared secret). 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
least 512 bits in length.

2. A SHA1 hash of the token The key is computed. computed from the shared-secret using the algorithm in
keyGenAlgorithm.

3. An HMAC-SHA1 value A MAC is then computed over the random value produced in Step 1, as described in [HMAC],
using the hash of the
token from key computed in Step 2 as the shared secret. 2.

4. The random value produced in Step 1 is encoded as the value of a
popLinkRandom control attribute.
POP Link Random control. This control attribute MUST be included in the
Full PKI Request message. Request.

5. The 160-bit HMAC-SHA1 result from MAC value produced in Step 3 is encoded as placed in either the value POP Link
Witness control or the witness field of a popLinkWitness extension to the certificate request.

1. POP Link Witness V2
control.

* For CRMF, popLinkWitness the POP Link Witness/POP Link Witness V2 control is
included in the controls section field of the CertRequest structure.

* For PKCS#10, popLinkWitness PKCS #10, the POP Link Witness/POP Link Witness V2 control
is included in the attributes
section field of the CertificationRequest
CertificationRequestInfo structure.

Upon receipt, servers MUST verify that each certificate certification request
contains a copy of the popLinkWitness POP Link Witness/POP Link Witness V2 control
and that its value was derived using the above method from the
shared-secret and the random string included in the specified manner from POP Link Random
control.

The Identification control (see Section 6.2.3) or the subject DN of a
certification request can be used to help identify which shared-
secret was used.

Schaad & Myers Expires May 22, 2008 [Page 41]

Internet-Draft CMC: Structures November 2007

6.3.1.2. POP Link Witness Control

The POP Link Witness control is identified by the OIDs:

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

The POP Link Witness control has the ASN.1 definition:

PopLinkWitness ::= OCTET STRING

For this control, SHA-1 is used as the key generation algorithm.
HMAC-SHA1 is used as the mac algorithm.

6.3.1.3. POP Link Random Control

The POP Link Random control is identified by the shared secret OIDs:

The POP Link Random and POP Link Witness controls are identified by
the random string
included in the popLinkRandom OIDs:

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

The POP Link Random control attribute.

5.3.2. has the ASN.1 definition:

PopLinkRandom ::= OCTET STRING

6.3.2. Shared-secret/subject DN matching linking

The second technique for doing identity-POP linking to link identity and POP information is to link
a particular subject distinguished name (subject DN) to the shared-
secrets that are distributed out-of-band and to require that clients
using the shared-secret to prove identity include that exact subject
DN in every certificate certification request. It is expected that many client-
server connections using that use 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.) certification request.)

When the shared secret shared-secret is generated and transferred out-of-band to

Schaad & Myers Expires September 3, 2006 [Page 31]

Internet-Draft CMS: Structures March 2006
initiate the registration process (Section 5.2), 6.2), a particular subject
DN is also associated with the shared secret shared-secret and communicated to the
client. (The subject DN generated MUST be unique per entity in
accordance with the CA policy; a null subject DN cannot be used. A
common practice could be to place the identification value as part of
the subject DN.) When the client generates the Full PKI Request
message, Request, it
MUST use these two pieces of information as follows:

1. The client MUST include the specific subject DN that it received
along with the shared secret shared-secret as the subject name in every
certificate

Schaad & Myers Expires May 22, 2008 [Page 42]

Internet-Draft CMC: Structures November 2007

certification request (PKCS#10 (PKCS #10 and/or CRMF) in the Full PKI
Request. The subject names in the certification requests MUST
NOT be null.

2. The client MUST include the identityProof an Identity Proof control attribute
(Section 5.2), or Identity
Proof Version 2(Section 6.2.2), derived from the shared secret, shared-secret,
in the Full PKI Request.

The server receiving this message MUST (a) validate the identityProof Identity
Proof control attribute and then, (b) check that the subject DN included in
each certificate certification request matches that associated with the shared shared-
secret. If either of these checks fails the certificate certification request
MUST be rejected.

5.3.3.

6.3.3. Renewal and Re-Key Messages

When doing a renewal or re-key message, certification request, linking
identity and POP information is simple. The client copies the
subject DN in (a) the for a current signing certificate
referenced by into the CMS SignerInfo object, and (b) all certificate
requests within subject name
field of each certification request that is made. The POP for the
each certification request message MUST match according will now cover that information. The
outmost signature layer is created using the current signing
certificate, which allows the original identity to be associated with
the certification request. Since the
standard name match rules described in [PKIXCERT].

5.4. the current signing
certificate and the names in the certification requests match, the
necessary linking has been achieved.

6.4. Data Return Control Attribute

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

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

An example of using this feature

The Data Return control is for a identified by the OID:

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

The Data Return control has the ASN.1 definition:

Schaad & Myers Expires May 22, 2008 [Page 43]

Internet-Draft CMC: Structures November 2007

DataReturn ::= OCTET STRING

A client could use this control to place an identifier marking the
exact source of the private key material.

Schaad & Myers Expires September 3, 2006 [Page 32]

Internet-Draft CMS: Structures March 2006 This might be the
identifier of a hardware device containing the private key.

5.5.

6.5. RA Certificate Modification Controls

These extensions controls exist for RAs/LRAs RAs to be able to modify the contents of a requestors certificate. This
certification request. Modifications might be necessary for various
reasons. The
reasons include: addition of certificate extensions dealing with policies and
correcting naming information for or modification
of subject and alternative and/or subject
names are two such reasons. alternative names.

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

5.5.1.

6.5.1. Modify Certificate Request Control

The Modify Certificate Request control is used by LRAs/RAs in order RAs to change various
fields in an EE a requested certificate. This

The Modify Certificate Request control allows for the specification of fields in is identified by the certificate
other than extensions. This attribute uses OID:

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

The Modify Certificate Request has the following ASN.1 definition:

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

pkiDataReference field contains

The fields in ModCertTemplate have the list of body part ids that define following meaning:

pkiDataReference is the path of to the embedded request message. PKI Request containing
certification request(s) to be modified.

certReferences field is a list of references refers to one or more of certification requests in the
payloads contained within a PKIData element.
PKI Request referenced by pkiDataReference to be modified. Each element
BodyPartID of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg. CertReqMsg (CRMF). By
definition, the listed certificate extensions included in the

Schaad & Myers Expires May 22, 2008 [Page 44]

Internet-Draft CMC: Structures November 2007

certTemplate field are to
be applied to every element certification request
referenced in the certReferences sequence. If a request
corresponding to bodyPartID cannot be found, the error CMCFailInfo with
a value of badRequest is returned referencing that references this control
attribute. control.

replace specifies if the data target certification request is to be replace with what is here,
modified by replacing or
if the fields in the original certificate request are to be
removed. deleting fields. If replace the value is FALSE, any field defined TRUE,
the data in this control replaces the
certTemplate field data in the target
certification request. If the value is removed from proposed certificate. For FALSE, the

Schaad & Myers Expires September 3, 2006 [Page 33]

Internet-Draft CMS: Structures March 2006

extensions field, only those extensions which are defined data in the
template certificate are removed.
target certification request is deleted. The use of action is slightly
different for the replace extensions field
set to FALSE of certTemplate, each extension
is be considered to be a rare event treated individually rather than as generally the
field would just be replaced with a correct value. single unit.

certTemplate contains is a certificate template object. Items are to be
omitted from the certificate template unless the value present object [CRMF]. If a field is
to
present and replace the value found the is TRUE, it replaces that field in the requested certificate
template.
certification request. If a the field is present in and replace is
FALSE, the extensions field of in the
template, that extension would either replace certification request is removed. If the same existing
field is absent, no action is performed. Each extension or be added to the set of extensions in the requested
certificate. is
treated as a single field.

Servers MUST be able to process all extensions defined, but not
prohibited, in [PKIXCERT]. Servers are not required to be able to
process every V3 X.509 X.509v3 extension transmitted using this protocol, nor
are they required to be able to process other, private extensions.
Servers are not required to put all LRA-requested RA-requested extensions into a
certificate. Servers are permitted to modify LRA-requested RA-requested
extensions. Servers MUST NOT alter an extension so as to reverse the
meaning of a client-requested extension. If a certification request
is denied due to the inability to handle a requested extension and a
response
Full PKI Response is returned, the server MUST return a failInfo attribute CMCFailInfo
value with the value of unsupportedExt.

If a certification request is the target of multiple Modify
Certificate Template controls exist in an
enrollment message, Request controls, the exact behavior is left up to the certificate
issuer policy. However it is recommended is:

o If control A exists in a layer that contains the following policy
be used. These rules would layer of control
B, control A MUST override control B. In other words, controls
should be applied from the innermost layer to individual extensions
within an Add Extensions control attribute (as opposed to an "all or
nothing" approach).

1. the outermost layer.

o If control A and control B are in the conflict is within a single same PKIData object, (i.e. the
certificate request would be rejected with an error of
badRequest.

2. If same
wrapping layer), the conflict order of application is between different PKIData objects, the
outermost version non-determinate.

The same order of the extension would be application is used (allowing an LRA
to override the extension requested by if a certification request is
the end-entity).

5.5.2. target of both a Modify Certificate Request control and an Add
Extensions control.

Schaad & Myers Expires May 22, 2008 [Page 45]

Internet-Draft CMC: Structures November 2007

6.5.2. Add Extensions Control

The Add Extensions control has been depreciated deprecated in favor of the Modify
Certificate Template Request control. It was replaced so that fields in the certificate template
certification request other than extensions could be modified.

The Add Extensions control attribute is used by LRAs in order RAs to specify additional
extensions that are to be placed on included in certificates.

Schaad & Myers Expires September 3, 2006 [Page 34]

Internet-Draft CMS: Structures March 2006

This attribute uses

The Add Extensions control is identified by the OID:

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

The Add Extensions control has the following ASN.1 definition:

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

The fields in AddExtensions have the following meaning:

pkiDataReference field contains the body part id identity of the embedded
request message.
certification request.

certReferences field is a list of references to one or more of the
payloads
certification requests contained within a PKIData. Each element body part
identifier of the certReferences sequence MUST be equal to either
the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
certReqId of the CertRequest within a CertReqMsg. CertReqMsg (CRMF). By
definition, the listed extensions are to be applied to every element
certification request referenced in the certReferences sequence.
If a certification request corresponding to bodyPartID cannot be
found, the error CMCFailInfo with a value of badRequest is returned
referencing this control
attribute. control.

extensions field contains the is a sequence of extensions to be applied to the
referenced certificate certification requests.

Schaad & Myers Expires May 22, 2008 [Page 46]

Internet-Draft CMC: Structures November 2007

denied due to the inability to handle a requested extension and a
response is returned, the server MUST return a failInfo attribute CMCFailInfo with the
value of unsupportedExt.

If multiple Add Extensions statements controls exist in an enrollment message, a Full PKI Request, the
exact behavior is left up to the certificate issuer CA policy. However it is
recommended that the following policy be used. These rules would be
applied to individual extensions within an Add Extensions control attribute (as
opposed to an "all or nothing" approach).

1. If the conflict is within a single PKIData object, PKIData, the
certificate certification
request would be rejected with an error a CMCFailInfo value of badRequest.

Schaad & Myers Expires September 3, 2006 [Page 35]

Internet-Draft CMS: Structures March 2006

2. If the conflict is between different PKIData objects, PKIData, the outermost
version of the extension would be used (allowing an LRA RA to
override the extension requested by the end-entity).

5.6. extension).

6.6. Transaction Management Control Attributes Identifier, Sender and Recipient Nonce Controls

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

The transactionId attribute Transaction Identifier control is identified by the OID:

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

The Transaction Identifier control has the ASN.1 definition:

TransactionId ::= INTEGER

The Transaction Identifier control identifies a given transaction.
It is used between by client and server to manage the state of an operation.
Clients MAY include a transactionID attribute Transaction Identifier control in request messages. request. If
the original request contains a transactionID attribute, Transaction Identifier control, all
subsequent request requests and response messages responses 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. Transaction
Identifier control.

Replay protection can be is supported through the use of sender the Sender and
recipient nonces.
Recipient Nonces controls. If nonces are used, in the first message
of a transaction, no recipientNonce a Recipient Nonce control is not transmitted; a senderNonce
Sender Nonce control is
instantiated included by the message transaction originator and
retained for later reference. The recipient of a sender nonce Sender Nonce
control reflects this value back to the originator as a recipientNonce Recipient
Nonce control and includes it's its own
senderNonce. Sender Nonce control. Upon
receipt by the transaction originator of this
message, response, the

Schaad & Myers Expires May 22, 2008 [Page 47]

Internet-Draft CMC: Structures November 2007

transaction originator compares the value of recipientNonce Recipient Nonce control
to its retained value. If the values match, the message can be
accepted for further security processing. The received value for senderNonce a
Sender Nonce control is also retained for inclusion in the next
message associated with the same transaction.

The senderNonce Sender Nonce and recipientNonce attribute can be used to provide
application-level replay prevention. Recipient controls are identified by the OIDs:

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

The Sender Nonce control has the ASN.1 definition:

SenderNonce ::= OCTET STRING

The Recipient Nonce control has the ASN.1 definition:

RecepientNonce ::= OCTET STRING

Clients MAY include a
senderNonce Sender Nonce control in the initial request message. Originating messages
include only a value for senderNonce. PKI
Request. If a message includes a
senderNonce, Sender Nonce control, the response
MUST include the transmitted value of the previously received senderNonce Sender
Nonce control as recipientNonce a Recipient Nonce control and include a 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

Everything described in this section is optional to implement, for
both servers as
its Sender Nonce control.

6.7. Encrypted and clients. Decrypted POP Controls

Servers MAY require this POP method be

Schaad & Myers Expires September 3, 2006 [Page 36]

Internet-Draft CMS: Structures March 2006 used only if another POP
method is unavailable. Servers SHOULD reject all certification
requests contained within a PKIData if any required POP is missing
for any element within the PKIData.

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

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

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

Schaad & Myers Expires May 22, 2008 [Page 48]

Internet-Draft CMC: Structures November 2007

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

3. Client decrypts the POP challenge using the private key that
corresponds to the presented public key and sends it the plaintext
back to the server.

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

CMC defines two different attributes. controls. The first deals with the
encrypted challenge sent from the server to the user in step 2. The
second deals with the decrypted challenge sent from the client to the
server in step 3.

The encryptedPOP attribute Encrypted POP control is used to send the encrypted challenge
from the server to the client. As such, it is encoded client as a tagged
attribute within the controlSequence part of a ResponseBody. the PKIResponse. (Note that
we assume
it is assumed that the message sent in Step 1 above is an enrollment
request is a Full PKI
Request and that the response in step 2 is a Full Enrollment PKI Response
including a failureInfo CMCFailInfo specifying that a POP is explicitly required,
and providing the POP challenge in the encryptedPOP attribute.)

Schaad & Myers Expires September 3, 2006 [Page 37]

Internet-Draft CMS: Structures March 2006 control.)

The Encrypted POP control is identified by the OID:

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

The Encrypted POP control has the ASN.1 definition:

EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms contentInfo, ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}

The Decrypted POP control is identified by the OID:

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

The Decrypted POP control has the ASN.1 definition:

DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}

Schaad & Myers Expires May 22, 2008 [Page 49]

Internet-Draft CMC: Structures November 2007

The encrypted POP algorithm works as follows:

1. The server generates a random value y and associates it with the
request.

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

request is the certificate request in the original certification request
message (it is included
here so the client need not key a copy of the request),

cms is an EnvelopedData object, EnvelopedData, the encapsulated content type being id-
data and the content being the POP Proof Value, this value
needs to be long enough that one cannot reverse the value y. from
the witness hash. If the certificate certification request contains a subject key identifier
Subject Key Identifier (SKI) extension, then the recipient
identifier SHOULD be the SKI. If the issuerAndSerialNumber
form is used, the IsserName IssuerName MUST be encoded as NULL and the
SerialNumber as the bodyPartID of the
certificate certification request,

thePOPAlgID contains identifies the algorithm to be used in computing the
return POP value,

witnessAlgID contains identifies the hash algorithm used on y to create
the field witness,

witness contains is the hashed value of y. POP proof value.

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

Schaad & Myers Expires September 3, 2006 [Page 38]

Internet-Draft CMS: Structures March 2006 of popFailed.

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

bodyPartID refers to the certificate certification request in the new
enrollment message,

2. PKI
Request,

thePOPAlgID is copied from the encryptedPOP,

thePOP contains the possession proof. This value is computed by
thePOPAlgID using the value y and request referenced in
(4a). the request.

Schaad & Myers Expires May 22, 2008 [Page 50]

Internet-Draft CMC: Structures November 2007

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
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 state
that a CA needs to keep in order to verify the returned POP value.
This
The following describes one of many possible ways of addressing the
problem by reducing the amount of state kept on the CA to a single
(or small set) of values.

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

2. For certificate certification request R, server computes y = F(x,R). F can
be, for example, HMAC-SHA1(x,R). All that's important for
statelessness is that y be consistently computable with only
known state constant x and function F, other inputs coming from
the cert certification request structure. y should not be predictable
based on knowledge of R, thus the use of a OWF One-Way-Function like
HMAC-SHA1.

Schaad & Myers Expires September 3, 2006 [Page 39]

Internet-Draft CMS: Structures March 2006

5.8. LRA

6.8. RA POP Witnesses Witness Control Attribute

In an enrollment a certification request scenario involving that involves an LRAs RA, the CA may
allow (or require) that the LRA to RA perform the POP protocol with the
entity
requesting certification. that generated the certification request. In this case case, the LRA
RA needs a way to inform the CA it has done the POP. This The RA POP
Witness control attribute has been created
to address addresses this issue.

The ASN.1 structure for the LRA RA POP witness Witness control is as follows: identified by the OID:

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

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

LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID

Schaad & Myers Expires May 22, 2008 [Page 51]

Internet-Draft CMC: Structures November 2007

}

The fields in LraPOPWitness have the following meaning:

pkiDataBodyid field contains the body part id identifier of the nested CMS body
object
TaggedContentInfo containing the client's full request message. Full PKI Request.
pkiDataBodyid is set to 0 if the request is in the current PKIRequest body.
PKIData.

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

If a certificate certification server does not allow for an LRA RA to do the POP
verification, it returns an error a CMCFailInfo with the value of POPFAILURE. popFailed.
The CA MUST NOT start a challenge-response to re-verify the POP
itself.

5.9.

6.9. Get Certificate Control Attribute

Everything described in this section is optional to implement.

The get certificate Get Certificate control attribute is used to retrieve a previously issued certificates
certificate from a repository of certificates. certificate repository. A Certificate
Authority, CA, an LRA RA 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 where a low-end IP router that does
not retain its own certificate in non-volatile memory.) fully deployed
directory is either infeasible or undesirable.

The get certificate Get Certificate control is identified by the OID:

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

The Get Certificate control attribute has the following ASN.1
structure: definition:

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

The service responding to fields in GetCert have the following meaning:

issuerName is the name of the certificate issuer.

serialNumber identifies the certificate to be retrieved.

The server that responds to this request will place places the requested

Schaad & Myers Expires September 3, 2006 [Page 40]

Internet-Draft CMS: Structures March 2006
certificate in the certificates field of a SignedData object. SignedData. If the
get certificate attribute Get
Certificate control is the only control in a Full PKI Request
message, Request, the

Schaad & Myers Expires May 22, 2008 [Page 52]

Internet-Draft CMC: Structures November 2007

response would should be a Simple Enrollment PKI Response.

5.10.

6.10. Get CRL Control Attribute

Everything described in this section is optional to implement.

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

The get Get CRL control is identified by the OID:

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

The Get CRL control attribute has the following ASN.1 structure: definition:

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

The fields in a GetCRL have the following meanings:

issuerName is the name of the CRL issuer.

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

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

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

A service server responding to the this request will place places the requested CRL in the
crls field of a SignedData object. SignedData. If the get Get CRL attribute control is the only
control in a full enrollment message, Full PKI Request, the response would should be a simple enrollment response. Simple PKI
Response.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 41] 53]

Internet-Draft CMS: CMC: Structures March 2006

5.11. November 2007

6.11. Revocation Request Control Attribute

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

The revocation request Revocation Request control is identified by the OID:

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

The Revocation Request control attribute has the following ASN.1
syntax: definition:

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

The fields of RevokeRequest have the following meaning:

issuerName contains is the issuerName of the certificate to be revoked.

serialNumber contains is the serial number of the certificate to be
revoked revoked.

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

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

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

comment contains is a human readable comment.

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

(Note that in some situations a Registration Authority may be
delegated authority to revoke certificates on behalf of some
population within its scope control. In these situations the CA

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 42] 54]

Internet-Draft CMS: CMC: Structures March 2006

would accept November 2007

It is possible to sign the LRA's digital signature on revocation for the request to revoke lost certificate with a
certificate, independent of whether
different certificate in some circumstances. A client can sign a
revocation for an encryption key with a signing certificate if the end entity still had access
name information matches. Similarly an administrator or RA can be
assigned the ability to revoke the private component certificate of a third party.
Acceptance of the key pair.) revocation by the server depends on local policy in
these cases.

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

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

A full response message Full PKI Response MUST be returned for a revocation request.

5.12.

6.12. Registration and Response Information Control Attributes Controls

The regInfo Registration Information control attribute is allows for clients and LRAs to pass
additional information as part a Full PKI request. Request.

The regInfo Registration Information control is identified by the OID:

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

The Registration Information control
attribute uses has the ASN.1 structure: definition:

RegInfo ::= OCTET STRING

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

The Response Information control allows a server (or LRA) needs to return additional
information back to a requestor
in response to data submitted in a regInfo attribute, then that data
is returned as part of a responseInfo Full PKI Response.

The Response Information control attribute. is identified by the OID:

Schaad & Myers Expires May 22, 2008 [Page 55]

Internet-Draft CMC: Structures November 2007

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

The content of Response Information control has the ASN.1 definition:

ResponseInfo ::= OCTET STRING for response information

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

5.13.

6.13. Query Pending Control Attribute

In some environments, process requirements for manual intervention or
other identity checking checks can cause a delay in returning the
certificate related to a certificate request. return of the certificate. The query pending
attribute
Query Pending control allows for a client clients to query a server about the
state of a pending certificate certification request. The server returns a token
pendToken as part of the CMCStatusInfo attribute Extended CMC Status Info and the CMC Status
Info controls (in the otherInfo field). The client

Schaad & Myers Expires September 3, 2006 [Page 43]

Internet-Draft CMS: Structures March 2006

puts copies the token
pendToken into the query pending attribute Query Pending control to identify the correct
certification request to the server. The server can also return returns a suggested
time for the client to query for the state of a pending
certificate certification
request.

The ASN.1 structure used Query Pending control is identified by the query pending OID:

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

The Query Pending control attribute is: has the ASN.1 definition:

QueryPending ::= OCTET STRING

If a server returns a pending state or partial CMCStatusInfo (the
transaction is still pending), the otherInfo MAY be omitted. If it the
otherInfo is not omitted then omitted, the same value of 'pendInfo' MUST be returned (the token MUST NOT change during the
request).

5.14. same as
the original pendInfo value.

6.14. Confirm Certificate Acceptance Control

Some Certification Authorities CAs require that clients give a positive
conformation confirmation that the
certificates issued to it the EE are acceptable. The Confirm
Certificate Acceptance control attribute is used for that purpose. If the CMCStatusInfo CMC
Status Info on a certificate response PKI Response is confirmRequired, then the client
MUST return a Confirm Certificate
attribute Acceptance control contained in a full enrollment response message.
Full PKI Request.

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

Schaad & Myers Expires May 22, 2008 [Page 56]

Internet-Draft CMC: Structures November 2007

The Confirm Certificate Acceptance control is identified by the OID:

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

The Confirm Control Acceptance control has been received before using the certificate for any
purpose.

The confirm certificate acceptance structure is: ASN.1 definition:

CMCCertId ::= IssuerAndSerialNumber

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

Servers MUST return a full enrollment response Full PKI Response for a confirm
certificate acceptance Confirm Certificate
Acceptance control.

Note that if the Certification Authority CA includes this attribute, control, there will be two full
round trips of messages.

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

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

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

Schaad & Myers Expires September 3, 2006 [Page 44]

Internet-Draft CMS: Structures March 2006

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

5.15.

6.15. Publish Trust Roots

This Anchors Control

The Publish Trust Anchors control allows for the distribution of set
trust roots anchors from a central authority to an end-entity.

What EE. The same control is included
also used to update the set of trust anchors. Trust anchors are
distributed in the form of certificates. These are expected, but not
required, to be self-signed certificates. Information is extracted
from these certificates to set the inputs to the certificates
validation algorithm in section 6.1.1 of [PKIXCERT].

The Publish Trust Anchors control is identified by the OID:

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

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

Schaad & Myers Expires May 22, 2008 [Page 57]

Internet-Draft CMC: Structures November 2007

PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}

The fields in PublishTrustAnchors have the following meaning:

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

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

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

While it is recommended that the sender place the certificates that
are to be treated as trusted roots, and a set of in the PKI Response, it is not required as the
certificates
that are no longer to should be treated as trusted roots. obtainable using normal discovery techniques.

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

This attribute uses the following ASN.1 definition:

PublishTrustRoots ::= SEQUENCE {
seqNumber INTEGER,
rootHashes SEQUENCE OF OCTET STRING
}

seqNumber contains an increasing integer specifying where in the
sequence of updates this item is.

rootHashes contains the hashes for the certificates that are to be
treated as trust roots by the client.

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

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

NOTE: Clients which that handle this attribute control must use extreme care in
validating that the operation is permissible. Incorrect handling of
this attribute control allows for an attacker to change the set of trusted
roots trust
anchors on the client.

Schaad & Myers Expires September 3, 2006 [Page 45]

Internet-Draft CMS: Structures March 2006

5.16. Provide Autenticated

6.16. Authenticated Data Control

The Authenticated Data

This control allows for an authority a server to provide data back
to the user client in an authenticated manner. In general, one would expect This control uses the
Authenticated Data structure to allow for validation of the data.
This control is used where the client has a shared-secret and a
secret identifier with the server, but where a trust anchor has not

Schaad & Myers Expires May 22, 2008 [Page 58]

Internet-Draft CMC: Structures November 2007

yet been downloaded onto the client so that a signing certificate for
the
same passphrase server cannot be validated. The specific case that this control
was created for use with the Publish Trust Anchors control
Section 6.15, but may be used in other cases as well.

The Authenticated Data control is identified by the identity proof operation. This attribute
uses OID:

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

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

AuthPublish ::= BodyPartID

The bodyPartID

AuthPublish is a body part identifier that refers to a member of the
cmsSequence either a
ResponseBody element for the current PKI Response or PKIData sequence. PKI Data. The
cmsSequence element within the is AuthenticatedData. The encapsulated content
is an
AuthenticatedData structure with a id-cct-PKIData content. Only id-cct-PKIData, there will then be controls in the
id-Publish-Roots control is currently expected
controlSequence that would need to be in this
sequence. processed (one example being
the Publish Trust Anchors control Section 6.15).

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

5.17.

6.17. Batch Process Identification

With the processing rules on message bodies, items which have been
batched Request and Response Controls

These controls allow for an RA to collect multiple requests together must be identified as such. Additionally
into a single Full PKI Request and forward it to a CA. The server
would then process the
returned batched responses must also be identified as such. requests and return the results in a Full PKI
Response.

The batchRequests Batch Request control attribute is used to identify the elements
in identified by the cmsSequence section that contain batched up requests to be
processed. OID:

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

The batchResponses Batch Response control attribute is used to identify the set of
elements in identified by the cmsSequence which correspond to batched responses.

When a server processes a batchRequests control, it may return OID:

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

Both the
items being processed either as individual messages or in a batched
response (identifying Batch Request and Batch Response controls have the elements ASN.1
definition:

BodyPartList ::= SEQUENCE of BodyPartID

The data associated with these controls is a batchResponses control). set of body part
identifiers. The preferable behavior is to batch the responses back to collection of requests/responses are individually
placed in the client
submitting cmsSequence of the batched request. If only partial responses can be
generated at this time, PKIData/PKIResponse. The body part
identifiers of these elements are then placed in the body part list.

Schaad & Myers Expires May 22, 2008 [Page 59]

Internet-Draft CMC: Structures November 2007

When a server SHOULD generate processes a batchResponse
with complete responses where available and QueryPending Batch Request control, it MAY return the
responses
where a complete response is not ready. in one or more PKI Responses. A QueryPending responses CMCStatus value of partial
is returned on all but the entire request SHOULD only last PKI Response. The CMCStatus would be returned
success if processing based on the
top level message itself (or on the status of Batch Requests control was processed, the requestor) is
involved in responses
are created with their own CMCStatus code. Errors on individual
requests are not propagated up to the pending processing.

5.18. top level.

6.18. Publication Information Control

This

The Publication Information control allows for modifying publication
of already issued certificates, both for publishing and removal from
publication. A common usage for this control is to remove an
existing certificate

Schaad & Myers Expires September 3, 2006 [Page 46]

Internet-Draft CMS: Structures March 2006 from publication during a re-key operation.
This control should always be processed after the issuance of new
certificates and revocation requests. This control should not be
processed if a certificate failed to be issued.

The attribute uses Publication Information control is identified by the OID:

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

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

CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo

PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }

-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)

SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}

The fields in CMCPublicationInfo have the following meaning:

Schaad & Myers Expires May 22, 2008 [Page 60]

Internet-Draft CMC: Structures November 2007

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

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

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

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

dontPublish indicates that the PKI should not publish the
certificate (this may indicate that the information how where and how requester intends to
publish the certificates
should be published. The action certificate him/herself). dontPublish has the
added connotation of remove removing from publication if the
certificate if it is already published.

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

pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the
PKI SHOULD publish the certificate.

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

6.19. Control Processed Control

The PKIPublicationInfo control is used to control publication of
certificates at the time of issue.

5.19. Control Processed

This control exists to allow allows an RA to single indicate to subsequent processors
of the
control sections processors that a specific control has already been
processed. This permits an RA in the middle of a processing stream
to process a control defined either in a local context or in a
subsequent document. This

The Control Processed control uses is identified by the OID:

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

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

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

Schaad & Myers Expires May 22, 2008 [Page 61]

Internet-Draft CMC: Structures November 2007

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

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 47] 62]

Internet-Draft CMS: CMC: Structures March 2006

6. Local November 2007

7. Registration Authorities

This specification permits the use of Local Registration Authorities
(LRAs). RAs. An LRA RA sits between the end-entity EE
and the Certification
Authority. CA. From the end-entity's EE's perspective, the LRA RA appears to be the Certification Authority CA
and from the server the LRA RA appears to be a client. LRAs RAs receive the enrollment messages,
PKI Requests, perform local processing and then forward them onto Certificate Authorities.
CAs. Some of the types of local processing that an LRA RA can perform
include:

o batching Batching multiple enrollment messages PKI Requests together,

o Performing challenge/response POP proofs,

o addition of Adding private or standardized certificate extensions to all
certification requests,

o archival of Archiving private key material,

o routing of Routing requests to different CAs.

When an LRA RA receives an enrollment message a PKI Request it has three options: it may
forward the message PKI Request without modification, it may add a new
wrapping layer to the message, PKI Request, or it may remove one or more
existing layers and add a new wrapping layer.

When an LRA RA adds a new wrapping layer to a message PKI Request it creates a
new
PKIData object. PKIData. The new layer contains any control attributes controls required (for
example if the LRA RA does the POP proof for an encryption key or the addExtension Add
Extension control attribute to modify an enrollment
request) a PKI Request) and the client enrollment message. PKI
Request. The client enrollment
message PKI Request is placed in the cmsSequence if it
is a Full Enrollment
message PKI Request and in the reqSequence if it is a Simple Enrollment message. PKI
Request. If an LRA RA is batching multiple client messages PKI Requests together,
then each client enrollment message PKI Request is placed into the appropriate location
in the LRA's RA's PKIData object along with all relevant control attributes.

(If controls.

If multiple LRAs RAs are in the path between the end-entity EE and the
Certification Authority, CA, this will
lead to multiple wrapping layers on the message.) request.

In processing a PKI Request, an enrollment message, an LRA RA MUST NOT alter any
certificate request body certification
requests (PKCS #10 or CRMF) as any alteration would invalidate the
signature on the certification request and thus the POP for the
private key.

An example of how this would look is illustrated by the following
figure:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 48] 63]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

SignedData (by LRA) RA)
PKIData
controlSequence
LRA
RA added control statements
reqSequence
Zero or more Simple CertificationRequests PKI Requests from clients
cmsSequence
Zero or more Full PKI messages Requests from clients
SignedData (by (signed by client)
PKIData

Under some circumstances an LRA RA is required to remove wrapping layers.
The following sections look at the processing required if encryption
layers and signing layers need to be removed.

6.1.

7.1. Encryption Removal

There are two cases that require an LRA RA to remove or change encryption
in an enrollment message. a PKI Request. In the first case the encryption was applied for
the purposes of protecting the entire
enrollment request PKI Request from unauthorized
entities. If the CA does not have a recipient info Recipient Info entry in the
encryption layer, the LRA RA MUST remove the encryption layer. The LRA RA
MAY add a new encryption layer with or without adding a new signing
layer.

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

6.2.

7.2. Signature Layer Removal

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

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

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 49] 64]

Internet-Draft CMS: CMC: Structures March 2006

7. November 2007

8. Security Considerations

Initiation of a secure communications channel between an end-entity
and a CA or LRA RA (and, similarly, between an LRA RA and another LRA RA or CA)
necessarily requires an out-of-band trust initiation mechanism. For
example, a secure channel may be constructed between the end-
entity end-entity
and the CA via IPSEC IPsec [IPsec] or TLS. TLS [TLS]. Many such schemes exist
and the choice of any particular scheme for trust initiation is
outside the scope of this document. Implementers of this protocol
are strongly encouraged to consider generally accepted principles of
secure key management when integrating this capability within an
overall security architecture.

Mechanisms for thwarting replay attacks may be required in particular
implementations of this protocol depending on the operational
environment. In cases where the CA maintains significant state
information, replay attacks may be detectable without the inclusion
of the optional nonce mechanisms. Implementers of this protocol need
to carefully consider environmental conditions before choosing
whether or not to implement the senderNonce and recipientNonce
attributes
controls described in section 5.6. Section 6.6. Developers of state-constrained
PKI clients are strongly encouraged to incorporate the use of these
attributes.

Under no circumstances should
controls.

Extreme care needs to be taken when archiving a signing key. The
holder of the archived key be archived. Doing so
allows may have the archiving entity ability to potentially use the key for forging to
generate forged signatures. There are however reasons why a signing
key should be archived. An archived CA signing key can be recovered
in the event of failure to continue to produced CRLs following a
disaster.

Due care must be taken prior to archiving keys. Once a key is given
to an archiving entity, the archiving entity could use the keys in a
way not conducive to the archiving entity. Users should be made
especially aware that proper verification is made of the certificate
used to encrypt the private key material.

Clients and servers need to do some checks on cryptographic
parameters prior to issuing certificates to make sure that weak
parameters are not used. A description of the small subgroup attack
is provided in [X942]. Methods of avoiding the small subgroup attack
can be found in [SMALL-GROUP]. CMC implementations ought to be aware
of this attack when doing parameter validations.

When using a shared-secret for authentication purposes, the shared-
secret should be generated using good random number techniques. techniques
[RANDOM]. User selection of the secret allows for dictionary attacks
to be mounted.

Schaad & Myers Expires May 22, 2008 [Page 65]

Internet-Draft CMC: Structures November 2007

Extreme care must be used when processing the Publish Trust Roots
attribute. Anchors
control. Incorrect processing can lead to the practice of slamming
where an attacker changes practice of slamming
where an attacker changes the set of trusted anchors in order to
weaken security.

One method of controlling the use of the Publish Trust Anchors
control is as follows. The client needs to associate with each trust
anchor accepted by the client the source of the trust anchor.
Additionally the client should associate with each trust anchor the
types of messages that the trust anchor is valid for. (I.e., is the
trust anchor used for validating S/MIME messages, TLS or CMC
enrollment messages.)

When a new message is received with a Publish Trust Anchor control,
the client would accept the set of new trust anchors for specific
applications only if the signature validates, the signer of the
message has the required policy approval for updating the trust
anchors and local policy also would allow updating the set of trusted roots in order to weaken

Schaad & Myers Expires September 3, 2006 [Page 50]

Internet-Draft CMS: Structures March 2006

security. trust anchors.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 51] 66]

Internet-Draft CMS: CMC: Structures March 2006

8. November 2007

9. IANA Considerations

This document defines a number of control objects. These are
identified by Object Identifiers (OIDs). The objects are defined
from an arc delegated by IANA to the PKIX Working Group. No further
action by IANA is necessary for this document or any anticipated
updates.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 52] 67]

Internet-Draft CMS: CMC: Structures March 2006

9. November 2007

10. Acknowledgments

The authors and the PKIX Working Group are greatful grateful for the
participation of Xiaoui Lui and Jeff Weinstein in helping to author
the original versions of this document.

The authors would like to thank Brian LaMacchia for his work in
developing and writing up many of the concepts presented in this
document. The authors would also like to thank Alex Deacon and Barb
Fox for their contributions.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 53] 68]

Internet-Draft CMS: CMC: Structures March 2006

10. November 2007

11. References

10.1.

11.1. Normative References

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.

[CRMF] Schaad, J., "Internet X.509 Certificate Certification Request message Message
Format", RFC 4211, January 2005.

[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 2875, June 2000.

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2104, February 1997.

[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC 2314, October 1997.

[PKIXCERT]
Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.

10.2.

11.2. Informational References

[CMC-TRANS]
Schaad, J. and M. Myers, "CMC Transport",
draft-ietf-pkix-cmc-trans-00.txt , December 2004.

[CMC-MUST]
Schaad, J. and M. Myers, "CMC Compliance",
draft-ietf-pkix-cmc-must-00.txt , December 2004.

[DH] Kaliski, B., "PKCS 3: Diffie-Hellman Key Agreement v1.4",
Lost 1900.

[IPsec] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

[PASSWORD]
Burr, W., Dodson, D., and W. Polk, "Electronic
Authentication Guideline", NIST SP 800-63, April 2006.

Schaad & Myers Expires May 22, 2008 [Page 69]

Internet-Draft CMC: Structures November 2007

[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5",
PKCS #1, March 1998.

[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5",
RFC 2315, October 1997.

[PKCS8] Laboratories, RSA., "PKCS#8: Private-Key Information
Syntax Standard, Version 1.2", November 1993.

[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5",

[RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker,
""Randomness Requirements for Security", BCP 106,
RFC 2314, October 1997. 4086, June 2005.

[SMALL-GROUP]
Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.

[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and

Schaad & Myers Expires September 3, 2006 [Page 54]

Internet-Draft CMS: Structures March 2006
L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, March 1998.

[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. 3851, July 2004.

[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.

[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.

[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
April 2000.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 55] 70]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

Appendix A. ASN.1 Module

EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) }

DEFINITIONS IMPLICIT TAGS :: ::=
BEGIN

-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.

IMPORTS

-- PKIX Part 1 - Implicit From [PKIXCERT]
CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)}

-- PKIX Part 1 - Explicit From [PKIXCERT]
AlgorithmIdentifier, Extension, Name
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)}

-- Cryptographic Message Syntax FROM [CMS]
ContentInfo, Attribute, IssuerAndSerialNumber
FROM CryptographicMessageSyntax2004 { 1 2 840 113549 1 9 16 0 24} iso(1) member-body(2)
usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24)}

-- CRMF FROM [CRMF]
CertReqMsg, PKIPublicationInfo
FROM PKIXCRMF {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-crmf(5)};

-- Global Types
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.

id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

Schaad & Myers Expires May 22, 2008 [Page 71]

Internet-Draft CMC: Structures November 2007

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

Schaad & Myers Expires September 3, 2006 [Page 56]

Internet-Draft CMS: Structures March 2006

-- The following controls have the type OCTET STRING

id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}

-- The following controls have the type UTF8String

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

-- The following controls have the type INTEGER

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

-- The following controls have the type OCTET STRING

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

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

id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }

bodyIdMax INTEGER ::= 4294967295

BodyPartID ::= INTEGER(0..bodyIdMax)

TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}

AttributeValue ::= ANY

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 57] 72]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

AttributeValue ::= ANY

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

CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}

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

OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }

-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }

ResponseBody ::= PKIResponse

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

Schaad & Myers Expires May 22, 2008 [Page 73]

Internet-Draft CMC: Structures November 2007

}

-- Used to return status state in a response

Schaad & Myers Expires September 3, 2006 [Page 58]

Internet-Draft CMS: Structures March 2006

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

CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}

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

CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
-- reserved (1), -- use is deprecated.
failed (2),
-- 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
failed (2),
pending (3),
noSupport (4),
-- the requested operation is not supported
confirmRequired (5),
-- confirmation using the confirmCertAcceptance control is
-- required
popRequired (6)
-- A certificate request requires an indirect POP operation.
-- Info for the indirect POP in this message. (6),
partial (7)
}

CMCFailInfo ::= INTEGER {
badAlg (0),
-- 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.

Schaad & Myers Expires September 3, 2006 [Page 59]

Internet-Draft CMS: Structures March 2006
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),
authDataFail (13)
-- Failure occurred during processing of authenticated data
}

-- Used for LRAs RAs to add extensions to certificate certification requests

Schaad & Myers Expires May 22, 2008 [Page 74]

Internet-Draft CMC: Structures November 2007

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

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

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

EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}

DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}

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

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

Schaad & Myers Expires September 3, 2006 [Page 60]

Internet-Draft CMS: Structures March 2006
}

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

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

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

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

Schaad & Myers Expires May 22, 2008 [Page 75]

Internet-Draft CMC: Structures November 2007

reasons ReasonFlags OPTIONAL }

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

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

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

CMCCertId ::= IssuerAndSerialNumber

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

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

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

-- The following exists to allow Diffie-Hellman Certificate Certification Requests Messages to be
-- be well-formed

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

NoSignatureValue ::= OCTET STRING

-- Unauthenticated attribute to carry removable data.

Schaad & Myers Expires September 3, 2006 [Page 61]

Internet-Draft CMS: Structures March 2006
-- This will be used in the key archive draft among others.

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

CMCUnsignedData ::= SEQUENCE {
bodyPartPath SEQUENCE SIZE (1..MAX) OF BodyPartID, BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}

-- Replaces CMC Status Info
--

id-cmc-statusInfoEx

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

CMCStatusInfoEx

Schaad & Myers Expires May 22, 2008 [Page 76]

Internet-Draft CMC: Structures November 2007

CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}

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

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

-- Allow for distribution of trust roots anchors
--

id-cmc-trustedRoots

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

PublishTrustRoots

PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
rootHashes
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}

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

Schaad & Myers Expires September 3, 2006 [Page 62]

Internet-Draft CMS: Structures March 2006

AuthPublish ::= BodyPartID

-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}

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

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

CMCPublicationInfo ::= SEQUENCE {

Schaad & Myers Expires May 22, 2008 [Page 77]

Internet-Draft CMC: Structures November 2007

hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
}

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

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

-- Inform follow on servers that one or more controls have already been processed

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

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

-- Identity Proof control w/ algorithm agility

id-cmc-identityProofV2 ::= { id-cmc 33 }

IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}

id-cmc-popLinkWitnessV2 ::= { id-cmc XX }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}

END

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 63] 78]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

Appendix B. Enrollment Message Flows

This section is informational. The purpose of this section is to
present, in an abstracted version, the messages that would flow
between the client and server for several different common cases.

Appendix B.1. Request of a Signing Certificate

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

Message from client to server:

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

Response from server to client:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 64] 79]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

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

Appendix B.2. Single Certificate Certification Request, But Modified by RA

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

Message from client to RA:

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

Message from RA to CA:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 65] 80]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.

Response from the CA to the RA:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 66] 81]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

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

{102, id-cmc-statusInfoEx, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoEx, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoEx, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA

Response from RA to client:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 67] 82]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

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

Appendix B.3. Indirect POP for an RSA certificate

This section looks at the messages that would flow in the event that
an enrollment is done for an encryption only certificate using an
indirect POP method. For simplicity it is assumed that the
certificate
certification requestor already has a signing only certificate

The fact that a second round trip is required is implicit rather than
explicit. The server determines this based on fact that no other POP
exists for the certificate certification request.

Message #1 from client to server:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 68] 83]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionID, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataRetrun, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requestor's signing cert

Response #1 from server to client:

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 69] 84]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoEx, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionID, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipipentInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 70] 85]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

ContentInfo.contentType = id-SignedData id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionID, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataRetrun, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requestor's signing cert

Response from server to client:

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

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 71] 86]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

Signed by CA

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 72] 87]

Internet-Draft CMC: Structures November 2007

Appendix C. Production of Diffie-Hellman Public Key Certification
Requests

Part of a certification request is a signature over the request;
Diffie-Hellman is a key agreement algorithm and cannot be used to
directly produce the required signature object. [DH-POP] provides
two ways to produce the necessary signature value. This document
also defines a signature algorithm that does not provide a POP value,
but can be used to produce the necessary signature value.

Appendix C.1. No-Signature Signature Mechanism

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

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

NoSignatureValue ::= OCTET STRING

The parameters for id-alg-noSignature MUST be present and MUST be
encoded as NULL. NoSignatureValue contains the hash of the
certification request. It is important to realize that there is no
security associated with this signature type. If this signature type
is on a certification request and the Certification Authority policy
requires proof-of-possession of the private key, the POP mechanism
defined in Section 6.7 MUST be used.

Schaad & Myers Expires May 22, 2008 [Page 88]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

Appendix C. D. Change History

RFC Editor - please remove this appendix prior to publishing.

RFC 27XX to -00

1. Addition of CMCStatusInfoEx Extended CMC Status Info

From -00 to -01

1. Removal of Transport section to a new document.

2. Removal of Compliance section to a new document.

From -01 to -02

1. Add processing rules for PKIData and PKIResponse processing.

2. Add unsigned attribute for holding data (to be used by key
archival).

3. Add trust root identification control.

4. Add Server to Client identity proof method.

5. Add controls to identify batch processing, needed by rules added
in item 1.

From -02 to -03

1. Add unpublish control

2. Added use of AuthenticatedData structure from CMS

3. Insert Appendix B - Enrollment Message Flows

4. Add Modify Certificate Certification Request control

From -03 to -04

1. Change author list.

2. Add IANA Considerations section

3. Correct module names in ASN.1

4. Add id-cmc-controlProcessed control with associated changes.

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 73] 89]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

From -04 to -05

1. Change Trust Root to Trust Anchor.

Schaad & Myers Expires May 22, 2008 [Page 90]

Internet-Draft CMC: Structures November 2007

Authors' Addresses

Jim Schaad
Soaring Hawk Consulting
PO Box 675
Gold Bar, WA 98251

Phone: (425) 785-1031
Email: jimsch@exmsft.com

Michael Myers
TraceRoute Security, Inc.

Email: myers@coastside.inc

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 74] 91]

Internet-Draft CMS: CMC: Structures March 2006 November 2007

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).

Schaad & Myers Expires September 3, 2006 May 22, 2008 [Page 75] 92]

----