[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5272

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


                Certificate Management Messages over CMS
                    draft-ietf-pkix-2797-bis-04.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.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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

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



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

Internet-Draft               CMS: Structures                  March 2006


       Standard), and

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

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Protocol Requirements  . . . . . . . . . . . . . . . . . .  4
     1.2.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Protocol Flow Charts . . . . . . . . . . . . . . . . . . .  8
   3.  Protocol Elements  . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  PKIData Object . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  ResponseBody Object  . . . . . . . . . . . . . . . . . . . 11
     3.3.  Certification Requests (PKCS10/CRMF) . . . . . . . . . . . 12
       3.3.1.  PKCS10 Request Body  . . . . . . . . . . . . . . . . . 12
       3.3.2.  CRMF Request Body  . . . . . . . . . . . . . . . . . . 13
       3.3.3.  Production of Diffie-Hellman Public Key
               Certification Requests . . . . . . . . . . . . . . . . 14
     3.4.  Body Part Identifiers  . . . . . . . . . . . . . . . . . . 15
     3.5.  Control Attributes . . . . . . . . . . . . . . . . . . . . 15
     3.6.  Content Info objects . . . . . . . . . . . . . . . . . . . 16
       3.6.1.  Signed Data  . . . . . . . . . . . . . . . . . . . . . 17
       3.6.2.  Enveloped Data . . . . . . . . . . . . . . . . . . . . 17
       3.6.3.  Authenticated Data . . . . . . . . . . . . . . . . . . 17
     3.7.  Other Message Bodies . . . . . . . . . . . . . . . . . . . 18
     3.8.  Unsigned Attributes  . . . . . . . . . . . . . . . . . . . 18
   4.  PKI Messages . . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.1.  Simple Enrollment Request  . . . . . . . . . . . . . . . . 20
     4.2.  Full PKI Request . . . . . . . . . . . . . . . . . . . . . 20
     4.3.  Simple Enrollment Response . . . . . . . . . . . . . . . . 21
     4.4.  Full PKI Response  . . . . . . . . . . . . . . . . . . . . 22
     4.5.  Application of Encryption to a PKI Message . . . . . . . . 22
   5.  Control Attributes . . . . . . . . . . . . . . . . . . . . . . 24
     5.1.  CMC Status Info Control Attributes . . . . . . . . . . . . 24
       5.1.1.  Extended CMC Status Info Control Attribute . . . . . . 25
       5.1.2.  CMC Status Info Control Attribute  . . . . . . . . . . 26
       5.1.3.  CMCStatus values . . . . . . . . . . . . . . . . . . . 27
       5.1.4.  CMCFailInfo  . . . . . . . . . . . . . . . . . . . . . 27
     5.2.  Identification and IdentityProof Control Attributes  . . . 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 Identity and POP Information . . . . . . . . . . . 30
       5.3.1.  Witness values derived from the shared-secret  . . . . 30
       5.3.2.  Shared-secret/subject DN matching  . . . . . . . . . . 31
       5.3.3.  Renewal and Re-Key Messages  . . . . . . . . . . . . . 32
     5.4.  Data Return Control Attribute  . . . . . . . . . . . . . . 32
     5.5.  RA Certificate Modification Controls . . . . . . . . . . . 33
       5.5.1.  Modify Certificate Request Control . . . . . . . . . . 33
       5.5.2.  Add Extensions Control . . . . . . . . . . . . . . . . 34
     5.6.  Transaction Management Control Attributes  . . . . . . . . 36
     5.7.  Proof-of-possession (POP) for encryption-only keys . . . . 36
     5.8.  LRA POP Witnesses Control Attribute  . . . . . . . . . . . 40
     5.9.  Get Certificate Control Attribute  . . . . . . . . . . . . 40
     5.10. Get CRL Control Attribute  . . . . . . . . . . . . . . . . 41
     5.11. Revocation Request Control Attribute . . . . . . . . . . . 42
     5.12. Registration and Response Information Control
           Attributes . . . . . . . . . . . . . . . . . . . . . . . . 43
     5.13. Query Pending Control Attribute  . . . . . . . . . . . . . 43
     5.14. Confirm Certificate Acceptance . . . . . . . . . . . . . . 44
     5.15. Publish Trust Roots  . . . . . . . . . . . . . . . . . . . 45
     5.16. Provide Autenticated Data  . . . . . . . . . . . . . . . . 46
     5.17. Batch Process Identification . . . . . . . . . . . . . . . 46
     5.18. Publication Information Control  . . . . . . . . . . . . . 46
     5.19. Control Processed  . . . . . . . . . . . . . . . . . . . . 47
   6.  Local Registration Authorities . . . . . . . . . . . . . . . . 48
     6.1.  Encryption Removal . . . . . . . . . . . . . . . . . . . . 49
     6.2.  Signature Layer Removal  . . . . . . . . . . . . . . . . . 49
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 50
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 52
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 53
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 54
     10.2. Informational References . . . . . . . . . . . . . . . . . 54
   Appendix A.   ASN.1 Module . . . . . . . . . . . . . . . . . . . . 56
   Appendix B.   Enrollment Message Flows . . . . . . . . . . . . . . 64
   Appendix B.1. Request of a Signing Certificate . . . . . . . . . . 64
   Appendix B.2. Single Certificate Request, But Modified by RA . . . 65
   Appendix B.3. Indirect POP for an RSA certificate  . . . . . . . . 68
   Appendix C.   Change History . . . . . . . . . . . . . . . . . . . 73
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74
   Intellectual Property and Copyright Statements . . . . . . . . . . 75










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

Internet-Draft               CMS: Structures                  March 2006


1.  Introduction

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

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

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

   A small number of additional services are defined to supplement the
   core certificate 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

   o  The protocol is to be based as much as possible on the existing
      CMS, PKCS#10 and CRMF specifications.

   o  The protocol must support the current industry practice of a
      PKCS#10 request followed by a PKCS#7 response as a subset of the
      protocol.

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

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

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

   o  The mandatory algorithms must superset the required algorithms for
      S/MIME.





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

Internet-Draft               CMS: Structures                  March 2006


   o  The protocol will contain POP methods.  Optional provisions for
      multiple-round trip POP will be made if necessary.

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

   o  The protocol needs to support arbitrary chains of local
      registration authorities as intermediaries between certificate
      requesters and issuers.

1.2.  Notation

   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 a single round trip of messages.  In the simplest case an
   enrollment request is sent from the client to the server and an
   enrollment response is then returned from the server 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 messages and two
   different response messages.

   Public key certification requests can be based on either the PKCS10
   or CRMF object.  The two different request messages are (a) the bare
   PKCS10 (in the event that no other services are needed), and (b) the
   PKCS10 or CRMF message wrapped in a CMS encapsulation as part of a
   PKIData object.

   Public key certification responses are based on the CMS signedData
   object.  The response may be either (a) a degenerate CMS signedData
   object (in the event no other services are needed), or (b) a
   ResponseBody object wrapped in a CMS signedData object.

   No special services are provided for doing either renewal (new
   certificates with the same key) or re-keying (new certificates on new
   keys) of clients.  Instead a renewal/re-key message looks the same as
   any enrollment message, with the identity proof being supplied by
   existing certificates from the CA.

   No special services are provided to distinguish between doing a re-
   keying operation and obtaining a new certificate (generally for a new
   purpose).  A control to unpublish a certificate would normally be
   included in a replacement operation, and be omitted if a new
   certificate was desired.  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.

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

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




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

Internet-Draft               CMS: Structures                  March 2006


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

2.1.  Terminology

   There are several different terms, abbreviations and acronyms used in
   this document that we define here for convenience and consistency of
   usage:

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

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

   CA refers to a Certification Authority.  A Certification Authority is
      the entity that performs the actual issuance of a certificate.

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

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

   PKCS#10 refers the Public Key Cryptography Standard #10.  This is one
      of a set of standards defined by RSA Laboratories in the 1980s.
      PKCS#10 defines a Certificate Request Message syntax.

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

   CMS refers to the Cryptographic Message Syntax RFC [CMS].  This
      document provides for basic cryptographic services including
      encryption and signing with and without key management.

   POP is an acronym for "Proof of Possession".  POP refers to a value
      that can be used to prove that the private key corresponding to a
      public key is in the possession and can be used by an end-entity.

   Transport wrapper refers to the outermost CMS wrapping layer.






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

Internet-Draft               CMS: Structures                  March 2006


2.2.  Protocol Flow Charts

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

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

    +----------+                            +------------------+
    | PKCS #10 |                            | CMS "certs-only" |
    +----------+--------------+             |     message      |
    |                         |             +------------------+------+
    | Certificate Request     |             |                         |
    |                         |             | CMS Signed Data,        |
    | Subject Name            |             |   no signerInfo         |
    | Subject Public Key Info |             |                         |
    |   (K_PUB)               |             | signedData contains one |
    | Attributes              |             | or more certificates in |
    |                         |             | the "certificates"      |
    +-----------+-------------+             | portion of the          |
                | signed with |             | signedData.             |
                | matching    |             |                         |
                | K_PRIV      |             | encapsulatedContentInfo |
                +-------------+             | is empty.               |
                                            |                         |
                                            +--------------+----------+
                                                           | unsigned |
                                                           +----------+

                Figure 1: Simple PKI Request and Response Messages




















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

Internet-Draft               CMS: Structures                  March 2006


    Full PKI Request                        Full PKI Response
    -----------------------                 ------------------------
    +----------------+                      +----------------+
    | CMS signedData |                      | CMS signedData |
    |     object     |                      |     object     |
    +----------------+--------+             +----------------+--------+
    |                         |             |                         |
    | PKIData object          |             | ResponseBody object     |
    |                         |             |                         |
    | Sequence of:            |             | Sequence of:            |
    | <enrollment attribute>* |             | <enrollment attribute>* |
    | <certification request>*|             | <CMS object>*           |
    | <CMS objects>*          |             | <other message>*        |
    | <other message>*        |             |                         |
    |                         |             | where * == zero or more |
    | where * == zero or more |             |                         |
    |                         |             | All certificates issued |
    | Certificate requests    |             | as part of the response |
    | are CRMF or PKCS#10     |             | are included in the     |
    | objects. Attributes are |             | "certificates" portion  |
    | (OID, ANY defined by    |             | of the signedData.      |
    | OID) pairs.             |             | Relevant CA certs and   |
    |                         |             | CRLs can be included as |
    +-------+-----------------+             | well.                   |
            | signed (keypair |             |                         |
            | used may be pre-|             +---------+---------------+
            | existing or     |                       | signed by the |
            | identified in   |                       | CA or an LRA  |
            | the request)    |                       +---------------+
            +-----------------+

               Figure 2: Full PKI Request and Response Messages

   Figure 2 shows the Full Enrollment Request and Response messages.
   The contents of these messages are detailed in Sections 4.2 and 4.4
   below.















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

Internet-Draft               CMS: Structures                  March 2006


3.  Protocol Elements

   This section covers each of the different elements that may be used
   to construct enrollment request and enrollment response messages.
   Section 4 will cover how to build the enrollment request and response
   messages.

3.1.  PKIData Object

   The new content object PKIData has been defined for this protocol.
   This new object is used as the body of the full PKI request message.
   The new body is identified by:

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

   The ASN.1 structure corresponding 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 in this document are found in section
      5.  As control sequences are defined by OIDs, other parties can
      define additional control attributes.  Unrecognized OIDs MUST
      result in no part of the request being successfully processed.

   reqSequence consists of a sequence of requests.  The requests can be
      a CertificateRequest (PKCS10 request), a CertReqMsg or an
      externally defined request (orm).  Details on the first two
      request types are found in sections 3.3.1 and 3.3.2 respectively.
      If an externally defined request message is present, but the
      server does not understand the request (or will not process it), a
      CMCStatus of noSupport MUST be returned for the request item and
      no requests processed.

   cmsSequence consists of a sequence of [CMS] message objects.  This
      protocol uses EnvelopedData, SignedData, EncryptedData and
      AuthenticatedData.  See section 3.6 for more details.

   otherMsgSequence allows for other arbitrary data items to be placed
      into the enrollment protocol.  The {OID, any} pair of values
      allows for arbitrary definition of material.  Data objects are
      placed here while control objects are placed in the
      controlSequence field.  See section 3.7 for more details.



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

Internet-Draft               CMS: Structures                  March 2006


   Processing of this object by a recipient is as follows:

   1.  All control attributes should be examined and processed in an
       appropriate manner.  The appropriate processing may be either to
       do complete processing at this time, ignore the control attribute
       or to place the control attribute on a to-do list for later
       processing.

   2.  An implicit control attribute is then processed for each item in
       the reqSequence.  Again this may be either immediate processing
       or addition to a to-do list for later processing.

   No processing is required for cmsSequence or otherMsgSequence members
   of the element.  If items are present and are not referenced by a
   control sequence, they are to be ignored.

3.2.  ResponseBody Object

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

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

   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 of a sequence of control attributes.  The
      control attributes defined in this document are found in section
      3.5.  Other parties can define additional control attributes.

   cmsSequence consists of a sequence of [CMS] message objects.  This
      protocol only uses EnvelopedData, SignedData, EncryptedData and
      AuthenticatedData.  See section 3.6 for more details.

   otherMsgSequence allows for other arbitrary items to be placed into
      the enrollment protocol.  The {OID, any} pair of values allows for
      arbitrary definition of material.  Data objects are placed here
      while control objects are placed in the controlSequence field.
      See section 3.7 for more details.

   Processing of this object by a recipient is as follows:




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

Internet-Draft               CMS: Structures                  March 2006


   1.  All control attributes should be examined and processed in an
       appropriate manner.  The appropriate processing may be either to
       do complete processing at this time, ignore the control attribute
       or to place the control attribute on a to-do list for later
       processing.

   2.  Additional processing of non-element items includes the saving of
       certificates and CRLs present in wrapping layers.  This type of
       processing is based on the consumer of the element and should not
       be relied on by generators.

   No processing is required for cmsSequence or otherMsgSequence members
   of the element.  If items are present and are not referenced by a
   control sequence, they are to be ignored.

3.3.  Certification Requests (PKCS10/CRMF)

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

   All certificate requests directly encoded into a single PKIData
   object SHOULD be for the same identity.  RAs that batch processing
   are expected to place the signed PKIData sequences received into the
   cmsSequence of the PKIData object it generates.

3.3.1.  PKCS10 Request Body

   Servers MUST be able to understand and process PKCS10 request bodies.
   Clients MUST produce a PKCS10 request body when using the Simple
   Enrollment Request message.  Clients MAY produce a PKCS10 request
   body when using the Full Enrollment Request message.

   When producing a PKCS10 request body, clients MUST produce a PKCS10
   message body containing a subject name and public key.  Some
   certification products are operated using a central repository of
   information to assign subject names upon receipt of a public key for
   certification.  To accommodate this mode of operation, the subject
   name in a CertificationRequest MAY be NULL, but MUST be present.  CAs
   that receive a CertificationRequest with a NULL subject name MAY
   reject such requests.  If rejected and a response is returned, the CA
   MUST respond with the failInfo attribute of badRequest.

   The client MAY incorporate one or more standard X.509 v3 extensions
   in any PKCS10 request as an ExtensionReq attribute.  An ExtensionReq
   attribute is defined as



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

Internet-Draft               CMS: Structures                  March 2006


         ExtensionReq ::= SEQUENCE OF Extension

   where Extension is imported from [PKIXCERT] and ExtensionReq is
   identified by {pkcs-9 14}.

   Servers MUST be able to process all extensions defined, but not
   prohibited, in [PKIXCERT].  Servers are not required to be able to
   process other V3 X.509 extensions transmitted using this protocol,
   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.)  If a
   certification request is denied due to the inability to handle a
   requested extension and a response is returned, the server MUST
   respond with the failInfo attribute of unsupportedExt.

3.3.2.  CRMF Request Body

   Servers MUST be able to understand and process CRMF request body.
   Clients MAY produce a CRMF message body when using the Full
   Enrollment Request message.

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

   o  When CRMF message bodies are used in the Full Enrollment Request
      message, each CRMF message MUST include both the subject and
      publicKey fields in the CertTemplate.  As in the case of PKCS10
      requests, the subject may be encoded as NULL, but MUST be present.

   o  When both CRMF and CMC controls exist with equivalent
      functionality, the CMC control SHOULD be used.  The CMC control
      MUST override the CRMF control.

   o  The regInfo field MUST NOT be used on a CRMF message.  Equivalent
      functionality is provided in the regInfo control attribute
      (section 5.12).

   o  The indirect method of proving POP is not supported in this
      protocol.  One of the other methods (including the direct method
      described in this document) MUST be used instead if POP is
      desired.  The value of encrCert in SubsequentMessage MUST NOT be
      used.

   o  Since the subject and publicKeyValues are always present, the
      POPOSigningKeyInput MUST NOT be used when computing the value for



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

Internet-Draft               CMS: Structures                  March 2006


      POPSigningKey.

   A server is not required to use all of the values suggested by the
   client in the certificate template.  Servers MUST be able to process
   all extensions defined, but not prohibited in [PKIXCERT].  Servers
   are not required to be able to process other V3 X.509 extension
   transmitted using this protocol, nor are they required to be able to
   process other, private extensions.  Servers are permitted to modify
   client-requested extensions.  Servers MUST NOT alter an extension so
   as to invalidate the original intent of a client-requested extension.
   (For example change key usage from key exchange to signing.)  If a
   certificate request is denied due to the inability to handle a
   requested extension, the server MUST respond with a failInfo
   attribute of unsupportedExt.

3.3.3.  Production of Diffie-Hellman Public Key Certification Requests

   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.

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.  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 5.7 MUST be used.






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

Internet-Draft               CMS: 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 a PKIData or PKIResponse message has an associated
   body part identifier.  The body part identifier is a 4-octet integer
   encoded in the certReqIds field for CertReqMsg objects (in a
   TaggedRequest) or in the bodyPartID field of the other objects.  The
   body part identifier MUST be unique within a single PKIData or
   PKIResponse object.  Body part identifiers can be duplicated in
   different layers (for example a CMC message embedded within another).
   The body part Identifier of zero is reserved to designate the current
   PKIData object.  This value is used in control attributes such as the
   Add Extensions Control in the pkiDataReference field to refer to a
   request in the current PKIData object.

   Some control attribute, such as the CMC Status Info attribute, will
   also use body part identifiers to refer to elements in the previous
   message.  This allows an error to be explicit about the attribute or
   request to which the error applies.

3.5.  Control Attributes

   The overall control flow of how a message is processed in this
   document is based on the control attributes.  Each control attribute
   consists of an object identifier and a value based on the object
   identifier.

   The final server MUST fail the processing 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 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 and only if
   (1) it is not generating a error response for another reason and (2)
   it is not going to process and pass the request on to another server
   for processing.

   The syntax of a control attribute is






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

Internet-Draft               CMS: Structures                  March 2006


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

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

   attrType is the OID defining the associated data in attrValues

   attrValues contains the set of data values used in processing the
      control attribute.

   The set of control attributes that are defined by this memo are found
   in section 5.

3.6.  Content Info objects

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

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

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

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

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

   EnvelopedData provides for shrouding of data.

   Data allows for general transport of unstructured data.

   SignedData object from [CMS] is also used in this specification to
      provide for authentication as well as serving as the general
      transport wrapper of requests and responses.






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

Internet-Draft               CMS: Structures                  March 2006


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

3.6.1.  Signed Data

   The signedData object is used in two different locations when
   constructing enrollment messages.  The signedData object is used as a
   wrapper for a PKIData as part of the enrollment request message.  The
   signedData object is also used as the outer part of an enrollment
   response message.

   As part of processing a message the signature(s) MUST be verified.
   If the signature does not verify, and the body contains anything
   other than a status response, a new message containing a status
   response MUST be returned using a CMCFailInfo with a value of
   badMessageCheck and a bodyPart of 0.

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

3.6.2.  Enveloped Data

   EnvelopedData is the primary method of providing confidentiality for
   sensitive information in this protocol.  The protocol currently uses
   EnvelopedData to provide encryption of an entire request (see section
   4.5).  The envelopedData object would also be used to wrap private
   key material for key archival.  If the decryption on an envelopedData
   failes, the response is a CMCFailInfo with a value of badMessageCheck
   and a bodyPart of 0.

   Servers MUST implement envelopedData according to [CMS].  There is an
   ambiguity (about encrypting content types other than id-data) in the
   PKCS7 specification that has lead to non-interoperability.

3.6.3.  Authenticated Data

   AuthenticatedData is used for providing origination authentication in
   those circumstances where a shared-secret exists, but a PKI trust
   anchor has not yet been established.  This is currently only used for
   the 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.




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

Internet-Draft               CMS: Structures                  March 2006


3.7.  Other Message Bodies

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

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

   bodyPartID contains the unique id of this object

   otherMsgType contains the OID defining both the usage of this body
      part and the syntax of the value associated with this body part

   otherMsgValue contains the data associated with the message body
      part.

3.8.  Unsigned Attributes

   There is sometimes a need to include data in an enrollment message
   designed to be removed during processing.  An example of this is the
   inclusion of an encrypted private key, where a key archive agent
   removes the encrypted private key before sending it on to the CA.
   One side effect of this desire is the fact that every RA which
   encapsulates this information needs to move the data so that it is
   not covered by the RA signature.  (A client request, encapsulated by
   an RA cannot have the unsigned attribute removed by the key archive
   agent without breaking the RA's signature.)  This attribute addresses
   that problem.

   This attribute is used to contain the information that is not
   directly signed by a user.  When an RA finds a message that has this
   attribute in the unsigned or unauthenticated attribute fields of the
   CMS objects it is aggregating, they are removed from the embedded CMS
   objects and propagated up to the RA CMS object.

   id-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, the PKCS10 MUST be signed with
   that private key.  If this form of the enrollment request is used for
   a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be
   used.

   Servers MUST support the Simple Enrollment Request message.  If the
   Simple Enrollment Request message is used, servers MUST return the
   Simple Enrollment Response message (see Section 4.3) if the
   enrollment request is granted.  If the enrollment request fails, the
   Full Enrollment Response MAY be returned or no response MAY be
   returned.

   The Simple Enrollment Request message MUST NOT be used if a proof-of-
   identity needs to be included.

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

4.2.  Full PKI Request

   The Full Enrollment Request provides the most functionality and
   flexibility.  Clients SHOULD use the Full Enrollment Request message
   when enrolling.  Servers MUST support the Full Enrollment Request
   message.  An enrollment response (full or simple as appropriate) MUST
   be returned to all Full Enrollment Requests.

   The Full Enrollment Request message consists of a PKIData object
   wrapped in a signedData CMS object.  The objects in the PKIData are
   ordered as follows:

   1.  All Control Attributes,

   2.  All certification requests,

   3.  All CMS objects,

   4.  All other messages.

   Each object in the PKIData sequence is identified by a Body Part



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

Internet-Draft               CMS: Structures                  March 2006


   Identifier.  If duplicate ids are found, the server MUST return the
   error badRequest with a bodyPartID of 0.

   The signedData object wrapping the PKIData may be signed either by
   the private key material of the signature certification request, or
   by a previously certified signature key.  If the private key of a
   signature certification request is being used, then:

      the certification request containing the corresponding public key
      MUST include a Subject Key Identifier extension,

      the subjectKeyIdentifier form of signerInfo MUST be used, and

      the value of the subjectKeyIdentifier form of signerInfo MUST be
      the Subject Key Identifier specified in the corresponding
      certification request.

   (The subjectKeyIdentifier form of signerInfo is used here because no
   certificates have yet been issued for the signing key.)  If the
   request key is used for signing, there MUST be only one signerInfo
   object in the signedData object.

   When creating a message to renew a certificate, the following should
   be taken into consideration:

   1.  The identification and identityProof control statements are not
       required.  The same information is provided by the use of an
       existing certificate from the CA when signing the enrollment
       message.

   2.  CAs and LRAs may impose additional restrictions on the signing
       certificate used.  They may require that the most recently issued
       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 the CA MUST return
       NOKEYREUSE as the failure code.

4.3.  Simple Enrollment Response

   Servers SHOULD use the simple enrollment response message whenever
   possible.  Clients MUST be able to process the simple enrollment
   response message.  The simple enrollment response message consists of
   a signedData object with no signerInfo objects on it.  The
   certificates requested are returned in the certificate bag of the
   signedData object.




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

Internet-Draft               CMS: Structures                  March 2006


   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 provide
   a mechanism to enable the user to explicitly trust the certificate.

4.4.  Full PKI Response

   Servers MUST return full PKI response messages if a) 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 for simple PKI requests.  Following section
   4.3 above, servers returning only certificates and a success status
   to the client SHOULD use the simple PKI response message.

   Clients MUST be able to process a full PKI response message.

   The full enrollment response message consists of a signedData object
   encapsulating a responseBody object.  In a responseBody object all
   Control Attributes MUST precede all CMS objects.  The certificates
   granted in an enrollment response are returned in the certificates
   field of the immediately encapsulating signedData object.

   Clients MUST NOT assume the certificates are in any order.  Servers
   SHOULD include all intermediate certificates needed to form complete
   chains one or more trust anchors, not just the newly issued
   certificate(s).  The server MAY additionally return CRLs in the CRL
   bag.  Servers MAY include the self-signed certificates.  Clients MUST
   NOT implicitly trust included self-signed certificate(s) merely due
   to its presence in the certificate bag.  In the event clients receive
   a new self-signed certificate from the server, clients SHOULD provide
   a mechanism to enable the user to explicitly trust the certificate.
   (The publish trust root control exists for the purpose of allowing
   for distribution of root certificates.  If a trusted root publishes a
   new trusted root, this is one case where automated trust of the new
   root could be allowed.)

4.5.  Application of Encryption to a PKI Message

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



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

Internet-Draft               CMS: Structures                  March 2006


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

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

   Options 1 and 2 provide the benefit of preventing leakage of
   sensitive data by encrypting the information.  LRAs can remove the
   enveloped data wrapping, and replace or forward without further
   processing.  Section 6 contains more information about LRA
   processing.

   PKI Messages MAY be encrypted or transmitted in the clear.  Servers
   MUST provided support for all three versions.

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






















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

Internet-Draft               CMS: Structures                  March 2006


5.  Control Attributes

   Control attributes are carried as part of both PKI requests and
   responses.  Each control attribute is encoded as a unique Object
   Identifier followed by that data for the control attribute.  The
   encoding of the data is based on the control attribute object
   identifier.  Processing systems would first detect the OID and
   process the corresponding attribute value prior to processing the
   message body.

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

      Control Attribute               OID            Syntax
      -----------------             ----------     --------------
      id-cmc-statusInfo              id-cmc 1       CMCStatusInfo
      id-cmc-identification          id-cmc 2       UTF8String
      id-cmc-identityProof           id-cmc 3       OCTET STRING
      id-cmc-dataReturn              id-cmc 4       OCTET STRING
      id-cmc-transactionId           id-cmc 5       INTEGER
      id-cmc-senderNonce             id-cmc 6       OCTET STRING
      id-cmc-recipientNonce          id-cmc 7       OCTET STRING
      id-cmc-addExtensions           id-cmc 8       AddExtensions
      id-cmc-encryptedPOP            id-cmc 9       EncryptedPOP
      id-cmc-decryptedPOP            id-cmc 10      DecryptedPOP
      id-cmc-lraPOPWitness           id-cmc 11      LraPOPWitness
      id-cmc-getCert                 id-cmc 15      GetCert
      id-cmc-getCRL                  id-cmc 16      GetCRL
      id-cmc-revokeRequest           id-cmc 17      RevokeRequest
      id-cmc-regInfo                 id-cmc 18      OCTET STRING
      id-cmc-responseInfo            id-cmc 19      OCTET STRING
      id-cmc-queryPending            id-cmc 21      OCTET STRING
      id-cmc-popLinkRandom           id-cmc 22      OCTET STRING
      id-cmc-popLinkWitness          id-cmc 23      OCTET STRING
      id-cmc-confirmCertAcceptance   id-cmc 24      CMCCertId
      id-cmc-statusInfoEx            id-cmc 25      CMCStatusInfoEx
      id-cmc-trustedRoots            id-cmc 26      PublishTrustRoots
      id-cmc-authData                id-cmc 27      AuthPublish
      id-cmc-batchRequests           id-cmc 28      BodyPartList
      id-cmc-batchResponses          id-cmc 29      BodyPartList
      id-cmc-publishCert             id-cmc 30      CMCPublicationInfo
      id-cmc-modCertTemplate         id-cmc 31      ModCertTemplate
      id-cmc-controlProcessed        id-cmc 32      ControlsProcessed

5.1.  CMC Status Info Control Attributes

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



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

Internet-Draft               CMS: Structures                  March 2006


   controls are described in this section.  The first is the preferred
   control; the second is included for backwards compatibility with RFC
   2797.

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

5.1.1.  Extended CMC Status Info Control Attribute

   This control uses the following ASN.1 definition:

      CMCStatusInfoEx ::= 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         SEQUENCE SIZE (1..MAX) OF BodyPartID
      }

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

   cMCStatus is described in section 5.1.3

   bodyList contains the list of references to body parts in the request
      message to which this status information applies.  If an error is
      being returned for a simple enrollment message, body list will
      contain a single integer of value '1'.






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

Internet-Draft               CMS: Structures                  March 2006


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

   failInfo is described in section 5.1.4.  It provides a detailed error
      on what the failure was.  This choice is present only if cMCStatus
      is failed.

   extendedFailInfo is provided for other users of the enrollment
      protocol to provided their own error codes.  This choice is
      present only if cMCStatus is failed.  Caution should be used in
      defining new values as they may not be correctly recognized by all
      clients and servers.  The failInfo value of internalCA error may
      be assumed if the extended error is not recognized.

   pendToken is the token to be used in the queryPending control
      attribute.

   pendTime contains the suggested time the server wants to be queried
      about the status of the request.

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

5.1.2.  CMC Status Info Control Attribute

   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 the following ASN.1
   definition:

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

   cMCStatus is described in section 5.1.3







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

Internet-Draft               CMS: Structures                  March 2006


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

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

   failInfo is described in section 5.1.4.  It provides a detailed error
      on what the failure was.  This choice is present only if cMCStatus
      is failed.

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

5.1.3.   CMCStatus values

   CMCStatus is a field in the CMCStatusInfo structure.  This field
   contains a code representing the success or failure of a specific
   operation.  CMCStatus has the ASN.1 structure of:

      CMCStatus ::= INTEGER {
           success                (0),
           -- request was granted
           -- reserved            (1),
           -- not used, defined where the original structure was defined
           failed                 (2),
           -- you don't get what you want, more information elsewhere in the
message
           pending                (3),
           -- the request body part has not yet been processed,
           -- requester is responsible to poll back on this
           -- pending may only be return for certificate request operations.
           noSupport              (4),
           -- the requested operation is not supported
           confirmRequired        (5),
           -- conformation using the confirmCertAcceptance control is
required
           -- before use of certificate
           popRequired            (6)
           -- A certificate requires an indirect POP operation.
           -- Info for the indirect POP in this message.
      }

5.1.4.   CMCFailInfo

   CMCFailInfo conveys information relevant to the interpretation of a
   failure condition.  The CMCFailInfo has the following ASN.1



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

Internet-Draft               CMS: Structures                  March 2006


   structure:

      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 system
time
           badCertId         (4),
           -- No certificate could be identified matching the provided
criteria
           unsuportedExt     (5),
           -- A requested X.509 extension is not supported by the recipient
CA.
           mustArchiveKeys   (6),
           -- Private key material must be supplied
           badIdentity       (7),
           -- Identification Attribute failed to verify
           popRequired       (8),
           -- Server requires a POP proof before issuing certificate
           popFailed         (9),
           -- POP processing failed
           noKeyReuse        (10),
           -- Server policy does not allow key re-use
           internalCAError   (11),
           tryLater          (12),
           authDataFail      (13)
           --  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 SHOULD
   be done by using an Extended Fail Info item in the CMCStatusInfoEx
   structure.

5.2.  Identification and IdentityProof Control Attributes

   Some CAs and LRAs require that a proof of identity be included in a
   certification request.  Many different ways of doing this exist with
   different degrees of security and reliability.  Most people are
   familiar with the request of a bank to provide your mother's maiden
   name as a form of identity proof.

   CMC provides one method of proving the client's identity based on a
   shared secret between the certificate requestor and the verifying
   authority.  If clients support full request messages, clients MUST
   implement this method of identity proof.  Servers MUST provide this



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 method starts with an out-of-band transfer of a token (the
   shared secret).  The shared-secret should be generated in a random
   manner.  The distribution of this token is beyond the scope of this
   document.  The client then uses this token for an identity proof as
   follows:

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

   2.  A SHA1 hash of the token is computed.

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

   4.  The 160-bit HMAC-SHA1 result from Step 3 is then encoded as the
       value of the identityProof attribute.

   When the server verifies the identityProof attribute, it computes the
   HMAC-SHA1 value in the same way and compares it to the identityProof
   attribute contained in the enrollment request.

   If a server fails the verification of an identityProof attribute and
   the server returns a response message, the failInfo attribute MUST be
   present in the response and MUST have a value of badIdentity.  Reuse
   of the shared-secret on enrollment retries makes it easier for the
   client and to prevent getting out of sync.  However, reuse of the
   shared-secret can potentially open the door for some types of
   attacks.

   Optionally, servers MAY require the inclusion of the unprotected
   identification attribute with an identification attribute.  The
   identification attribute is intended to contain either a text string
   or a numeric quantity, such as a random number, which assists the
   server in locating the shared secret needed to validate the contents
   of the identityProof attribute.  Numeric values MUST be converted to
   text string representations prior to encoding as UTF8-STRINGs in this
   attribute.  If the identification control attribute is included in
   the message, the derivation of the shared secret in step 2 is altered
   so that the hash of the concatenation of the token and the UTF8
   encoded (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.  Hardware Shared Secret Token Generation

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

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

   2.  The shared secret value used above is the same hardware-generated
       token.

   3.  All certification requests MUST have a subject name and the
       subject name MUST contain the fields required to identify the
       holder of the hardware token device.

5.3.  Linking Identity and POP Information

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

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

5.3.1.  Witness values derived from the shared-secret

   The first technique for doing identity-POP linking works by forcing



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

Internet-Draft               CMS: Structures                  March 2006


   the client to include a piece of information cryptographically-
   derived from the shared-secret token as a signed extension within
   each certificate request (PKCS#10 or CRMF) message.  This technique
   is useful if null subject DNs are used (because, for example, the
   server can generate the subject DN for the certificate based only on
   the shared secret).  Processing begins when the client receives the
   shared-secret token out-of-band from the server.  The client then
   computes the following values:

   1.  The client generates a random byte-string, R, which SHOULD be at
       least 512 bits in length.

   2.  A SHA1 hash of the token is computed.

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

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

   5.  The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value
       of a popLinkWitness extension to the certificate request.

       1.  For CRMF, popLinkWitness is included in the controls section
           of the CertRequest structure.

       2.  For PKCS#10, popLinkWitness is included in the attributes
           section of the CertificationRequest structure.

   Upon receipt, servers MUST verify that each certificate request
   contains a copy of the popLinkWitness and that its value was derived
   in the specified manner from the shared secret and the random string
   included in the popLinkRandom control attribute.

5.3.2.  Shared-secret/subject DN matching

   The second technique for doing identity-POP linking 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 request.  It is expected that many client-
   server connections using shared-secret based proof-of-identity will
   use this mechanism.  (It is common not to omit the subject DN
   information from the certificate request messages.)

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



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

Internet-Draft               CMS: Structures                  March 2006


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

   1.  The client MUST include the specific subject DN that it received
       along with the shared secret as the subject name in every
       certificate request (PKCS#10 and/or CRMF) in the Full PKI
       Request.  The subject names in the requests MUST NOT be null.

   2.  The client MUST include the identityProof control attribute
       (Section 5.2), derived from the shared secret, in the Full PKI
       Request.

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

5.3.3.  Renewal and Re-Key Messages

   In a renewal or re-key message, the subject DN in (a) the certificate
   referenced by the CMS SignerInfo object, and (b) all certificate
   requests within the request message MUST match according to the
   standard name match rules described in [PKIXCERT].

5.4.  Data Return Control Attribute

   The 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.  Data placed in a data return statement is considered to be
   opaque to the server.  The same control is used for both requests and
   responses.  If the data return statement appears in an enrollment
   message, the server MUST return it as part of the enrollment response
   message.

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

   An example of using this feature is for a client to place an
   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.  RA Certificate Modification Controls

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

   Two controls exist for this purpose.  The first Modify Certificate
   Template has the full control for allowing modification of any field
   in the certificate.  The second Add Extensions control only allows
   for the addition of extensions.

5.5.1.  Modify Certificate Request Control

   The Modify Certificate Request control is used by LRAs/RAs in order
   to change various fields in an EE requested certificate.  This
   control allows for the specification of fields in the certificate
   other than extensions.  This attribute uses the following ASN.1
   definition:

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

   pkiDataReference field contains the list of body part ids that define
      the path of the embedded request message.

   certReferences field is a list of references to one or more of the
      payloads contained within a PKIData element.  Each element of the
      certReferences sequence MUST be equal to either the bodyPartID of
      a TaggedCertificationRequest or the certReqId of the CertRequest
      within a CertReqMsg.  By definition, the listed extensions are to
      be applied to every element referenced in the certReferences
      sequence.  If a request corresponding to bodyPartID cannot be
      found, the error badRequest is returned referencing this control
      attribute.

   replace specifies if the data is to be replace with what is here, or
      if the fields in the original certificate request are to be
      removed.  If replace is FALSE, any field defined in the
      certTemplate field is removed from proposed certificate.  For the



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

Internet-Draft               CMS: Structures                  March 2006


      extensions field, only those extensions which are defined in the
      template certificate are removed.  The use of the replace field
      set to FALSE is be considered to be a rare event as generally the
      field would just be replaced with a correct value.

   certTemplate contains a certificate template object.  Items are to be
      omitted from the certificate template unless the value present is
      to replace the value found the in the requested certificate
      template.  If a field is present in the extensions field of the
      template, that extension would either replace the same existing
      extension or be added to the set of extensions in the requested
      certificate.

   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 extension transmitted using this protocol, nor
   are they required to be able to process other, private extensions.
   Servers are not required to put all LRA-requested extensions into a
   certificate.  Servers are permitted to modify LRA-requested
   extensions.  Servers MUST NOT alter an extension so as to reverse the
   meaning of a client-requested extension.  If a certification request
   is denied due to the inability to handle a requested extension and a
   response is returned, the server MUST return a failInfo attribute
   with the value of unsupportedExt.

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

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

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

5.5.2.  Add Extensions Control

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

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



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

Internet-Draft               CMS: Structures                  March 2006


   This attribute uses the following ASN.1 definition:

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

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

   certReferences field is a list of references to one or more of the
      payloads contained within a PKIData.  Each element of the
      certReferences sequence MUST be equal to either the bodyPartID of
      a TaggedCertificationRequest or the certReqId of the CertRequest
      within a CertReqMsg.  By definition, the listed extensions are to
      be applied to every element referenced in the certReferences
      sequence.  If a request corresponding to bodyPartID cannot be
      found, the error badRequest is returned referencing this control
      attribute.

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

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

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

   1.  If the conflict is within a single PKIData object, the
       certificate request would be rejected with an error 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, the
       outermost version of the extension would be used (allowing an LRA
       to override the extension requested by the end-entity).

5.6.  Transaction Management Control Attributes

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

   The transactionId attribute identifies a given transaction.  It is
   used between client and server to manage the state of an operation.
   Clients MAY include a transactionID attribute in request messages.
   If the original request contains a transactionID attribute, all
   subsequent request and response messages MUST include the same
   transactionID attribute.  A server MUST use only transactionIds in
   the outermost PKIdata object.  TransactionIds on inner PKIdata
   objects are for intermediate entities.

   Replay protection can be supported through the use of sender and
   recipient nonces.  If nonces are used, in the first message of a
   transaction, no recipientNonce is transmitted; a senderNonce is
   instantiated by the message originator and retained for later
   reference.  The recipient of a sender nonce reflects this value back
   to the originator as a recipientNonce and includes it's own
   senderNonce.  Upon receipt by the transaction originator of this
   message, the originator compares the value of recipientNonce to its
   retained value.  If the values match, the message can be accepted for
   further security processing.  The received value for senderNonce is
   also retained for inclusion in the next message associated with the
   same transaction.

   The senderNonce and recipientNonce attribute can be used to provide
   application-level replay prevention.  Clients MAY include a
   senderNonce in the initial request message.  Originating messages
   include only a value for senderNonce.  If a message includes a
   senderNonce, the response MUST include the transmitted value of the
   previously received senderNonce as recipientNonce and include new
   value for senderNonce.  A server MUST use only nonces in the
   outermost PKIdata object.  Nonces on inner PKIdata objects are for
   intermediate entities.

5.7.  Proof-of-possession (POP) for encryption-only keys

   Everything described in this section is optional to implement, for
   both servers and clients.  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 requests contained within a PKIData if any required POP is
   missing for any element within the PKIData.

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

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

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

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

   3.  Client decrypts the POP challenge and sends it back to the
       server.

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

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

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











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

Internet-Draft               CMS: Structures                  March 2006


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

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

   The encrypted POP algorithm works as follows:

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

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

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

       2.  cms is an EnvelopedData object, the content type being id-
           data and the content being the value y.  If the certificate
           request contains a subject key identifier (SKI) extension,
           then the recipient identifier SHOULD be the SKI.  If the
           issuerAndSerialNumber form is used, the IsserName MUST be
           encoded as NULL and the SerialNumber as the bodyPartID of the
           certificate request,

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

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

       5.  witness contains the hashed value of y.

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



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

Internet-Draft               CMS: Structures                  March 2006


       of popFailed.

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

       1.  bodyPartID refers to the certificate request in the new
           enrollment message,

       2.  thePOPAlgID is copied from the encryptedPOP,

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

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

   When defining the algorithms for thePOPAlgID and witnessAlgID care
   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 describes one of many possible ways of addressing the problem by
   reducing the amount of state kept on the CA to a single (or small
   set) of values.

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

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






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

Internet-Draft               CMS: Structures                  March 2006


5.8.  LRA POP Witnesses Control Attribute

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

   The ASN.1 structure for the LRA POP witness is as follows:

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

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

   bodyIds contains a list of certificate requests for which the LRA 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 server does not allow for an LRA to do the POP
   verification, it returns an error of POPFAILURE.  The CA MUST NOT
   start a challenge-response to re-verify the POP itself.

5.9.  Get Certificate Control Attribute

   Everything described in this section is optional to implement.

   The get certificate control attribute is used to retrieve previously
   issued certificates from a repository of certificates.  A Certificate
   Authority, an LRA or an independent service may provide this
   repository.  The clients expected to use this facility are those
   operating in a resource-constrained environment.  (An example of a
   resource-constrained client would be a low-end IP router that does
   not retain its own certificate in non-volatile memory.)

   The get certificate control attribute has the following ASN.1
   structure:

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

   The service responding to the request will place 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.  If the
   get certificate attribute is the only control in a Full PKI Request
   message, the response would be a Simple Enrollment Response.

5.10.  Get CRL Control Attribute

   Everything described in this section is optional to implement.

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

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

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

   The fields in a GetCRL have the following meanings:

   issuerName is the name of the CRL issuer.

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

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

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

   A service responding to the request will place the requested CRL in
   the crls field of a SignedData object.  If the get CRL attribute is
   the only control in a full enrollment message, the response would be
   a simple enrollment response.






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

Internet-Draft               CMS: Structures                  March 2006


5.11.  Revocation Request Control Attribute

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

   The revocation request control attribute has the following ASN.1
   syntax:

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

   issuerName contains the issuerName of the certificate to be revoked.

   serialNumber contains the serial number of the certificate to be
      revoked

   reason contains 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 the suggested value for the Invalidity Date
      CRL Extension.  The CA can use this value at its discretion in
      building the CRL.

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

   comment contains a human readable comment.

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

   (Note that in some situations a Registration Authority may be
   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              [Page 42]

Internet-Draft               CMS: Structures                  March 2006


   would accept the LRA's digital signature on the request to revoke a
   certificate, independent of whether the end entity still had access
   to the private component of the key pair.)

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

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

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

5.12.  Registration and Response Information Control Attributes

   The regInfo control attribute is for clients and LRAs to pass
   additional information as part a PKI request.  The regInfo control
   attribute uses the ASN.1 structure:

      RegInfo ::= OCTET STRING

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

   If a server (or LRA) needs to return information back to a requestor
   in response to data submitted in a regInfo attribute, then that data
   is returned as a responseInfo control attribute.  The content of the
   OCTET STRING for response information is based on bilateral agreement
   between the client and server.

5.13.  Query Pending Control Attribute

   In some environments, process requirements for manual intervention or
   other identity checking can cause a delay in returning the
   certificate related to a certificate request.  The query pending
   attribute allows for a client to query a server about the state of a
   pending certificate request.  The server returns a token as part of
   the CMCStatusInfo attribute (in the otherInfo field).  The client



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

Internet-Draft               CMS: Structures                  March 2006


   puts the token into the query pending attribute to identify the
   correct request to the server.  The server can also return a
   suggested time for the client to query for the state of a pending
   certificate request.

   The ASN.1 structure used by the query pending control attribute is:

      QueryPending ::= OCTET STRING

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

5.14.  Confirm Certificate Acceptance

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

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

   The confirm certificate acceptance structure is:

      CMCCertId ::= IssuerAndSerialNumber

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

   Servers MUST return a full enrollment response for a confirm
   certificate acceptance control.

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

   1.  The client sends the request to the CA.

   2.  The CA returns the certificate and this attribute.

   3.  The client sends a response message to the CA with a
       CMCStatusInfoEx control either accepting or rejecting the
       certificate.




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

Internet-Draft               CMS: Structures                  March 2006


   4.  The CA sends a response message to the client with a
       CMCStatusInfoEx of success.

5.15.  Publish Trust Roots

   This control allows for distribution of trust roots from a central
   authority to an end-entity.

   What is included in the control as data is the set of certificates
   that are to be treated as trusted roots, and a set of certificates
   that are no longer to be treated as trusted roots.

   Prior to accepting the change in trust roots, a client MUST do the at
   least following: Validate the signature on the message to a current
   trusted root, check with policy to ensure that the signer is
   permitted to use the attribute, 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, it is
   up to local policy to determine how the different trust lists should
   be combined.  Clients SHOULD be able to handle the update of trust
   lists multiple trust list independently.

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






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

Internet-Draft               CMS: Structures                  March 2006


5.16.  Provide Autenticated Data

   This control allows for an authority to provide data back to the user
   in an authenticated manner.  In general, one would expect that the
   same passphrase used in the identity proof operation.  This attribute
   uses the following ASN.1 definition:

      AuthPublish ::= BodyPartID

   The bodyPartID refers to a member of the cmsSequence either a
   ResponseBody or PKIData sequence.  The element within the is an
   AuthenticatedData structure with a id-cct-PKIData content.  Only the
   id-Publish-Roots control is currently expected to be in this
   sequence.

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

5.17.  Batch Process Identification

   With the processing rules on message bodies, items which have been
   batched together must be identified as such.  Additionally the
   returned batched responses must also be identified as such.

   The batchRequests control attribute is used to identify the elements
   in the cmsSequence section that contain batched up requests to be
   processed.

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

   When a server processes a batchRequests control, it may return the
   items being processed either as individual messages or in a batched
   response (identifying the elements with a batchResponses control).
   The preferable behavior is to batch the responses back to the client
   submitting the batched request.  If only partial responses can be
   generated at this time, the server SHOULD generate a batchResponse
   with complete responses where available and QueryPending responses
   where a complete response is not ready.  A QueryPending responses on
   the entire request SHOULD only be returned if processing based on the
   top level message itself (or on the status of the requestor) is
   involved in the pending processing.

5.18.  Publication Information Control

   This 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 the following ASN.1 definition:

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

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

   pubInfo contains the information how where and how the certificates
      should be published.  The action dontPublish has the added
      connotation of remove from publication if the certificate is
      already published.

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

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

5.19.  Control Processed

   This control exists to allow an RA to single to subsequent processors
   of the control sections 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 control uses the following ASN.1
   definition::

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

   bodyList contains 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              [Page 47]

Internet-Draft               CMS: Structures                  March 2006


6.  Local Registration Authorities

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

   o  batching multiple enrollment messages together,

   o  challenge/response POP proofs,

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

   o  archival of private key material,

   o  routing of requests to different CAs.

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

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

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

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

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



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

Internet-Draft               CMS: Structures                  March 2006


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

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

6.1.  Encryption Removal

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

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

6.2.  Signature Layer Removal

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

   If an LRA removes a signing layer from a message, all control
   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.





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

Internet-Draft               CMS: Structures                  March 2006


7.  Security Considerations

   Initiation of a secure communications channel between an end-entity
   and a CA or LRA (and, similarly, between an LRA and another LRA or
   CA) necessarily requires an out-of-band trust initiation mechanism.
   For example, a secure channel may be constructed between the end-
   entity and the CA via IPSEC or TLS.  Many such schemes exist and the
   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 described in section 5.6.  Developers of state-constrained
   PKI clients are strongly encouraged to incorporate the use of these
   attributes.

   Under no circumstances should a signing key be archived.  Doing so
   allows the archiving entity to potentially use the key for forging
   signatures.

   Due care must be taken prior to archiving keys.  Once a key is given
   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.  User
   selection of the secret allows for dictionary attacks to be mounted.

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



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

Internet-Draft               CMS: Structures                  March 2006


   security.


















































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

Internet-Draft               CMS: Structures                  March 2006


8.  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              [Page 52]

Internet-Draft               CMS: Structures                  March 2006


9.  Acknowledgments

   The authors and the Working Group are greatful 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              [Page 53]

Internet-Draft               CMS: Structures                  March 2006


10.  References

10.1.  Normative References

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

   [CRMF]     Schaad, J., "Internet X.509 Certificate Request 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.

   [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.  Informational References

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

   [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", RFC 2314, October 1997.

   [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.

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











































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

Internet-Draft               CMS: Structures                  March 2006


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}

   -- 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) }

   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 }


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

    bodyIdMax INTEGER ::= 4294967295

    BodyPartID ::= INTEGER(0..bodyIdMax)

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

    AttributeValue ::= ANY




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

Internet-Draft               CMS: Structures                  March 2006


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

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

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

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

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

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

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

   -- Used to return status state in a response




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
       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.
   }

   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 to add extensions to certificate requests
   id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}

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


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

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

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

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

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



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,
       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 OF Extension

   -- The following exists to allow Diffie-Hellman Certificate Requests
Messages to be
   -- well-formed

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

   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,
       identifier          OBJECT IDENTIFIER,
       content             ANY DEFINED BY identifier
   }

   --  Replaces CMC Status Info
   --

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

   CMCStatusInfoEx ::= 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         SEQUENCE SIZE (1..MAX) OF BodyPartID
   }

   --  Allow for distribution of trust roots
   --

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

   PublishTrustRoots ::= SEQUENCE {
       seqNumber      INTEGER,
       rootHashes     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 OF BodyPartID


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

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

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

   ModCertTemplate ::= SEQUENCE {
       pkiDataReference             BodyPartList,
       certReferences               SEQUENCE OF BodyPartID,
       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
   }

   END
















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

Internet-Draft               CMS: Structures                  March 2006


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
   request.

   Message from client to server:

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

   Response from server to client:













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

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {102, id-cmc-statusInfoEx, {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 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 request before passing it on the CA.

   Message from client to RA:

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

   Message from RA to CA:






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

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           { 102, id-cmc-batchRequests, { 1, 2} }
           { 103, id-cmc-addExtensions,
             { {1, 201, {id-ce-certificatePolicies, anyPolicy}}
               {1, 201, {id-ce-subjectAltName, {extension data}}
               {2, XXX, {id-ce-subjectAltName, {extension data}}}
         cmsSequence
           { 1, <Message from client to RA #1> }
           { 2, <Message from client to RA #2> }
     SignedData.SignerInfos
       SignerInfo
         sid = RA key.

   Response from the CA to the RA:
































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

Internet-Draft               CMS: Structures                  March 2006


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

           {102, id-cmc-statusInfoEx, {failed, 2, badIdentity}}
         cmsSequence
           { bodyPartID = 999
             contentInfo
               ContentInfo.contentType = id-SignedData
               ContentInfo.content
                 SignedData.encapContentInfo
                   eContentType = id-ct-PKIResponse
                   eContent
                     controlSequence
                      {102, id-cmc-statusInfoEx, {success, 201}}
                 certificates
                   Newly issued certificate
                   Other certificates
                 SignedData.SignerInfos
                   Signed by CA
           }
           { bodyPartID = 998,
             contentInfo
               ContentInfo.contentType = id-SignedData
               ContentInfo.content
                 SignedData.encapContentInfo
                   eContentType = id-ct-PKIResponse
                   eContent
                     controlSequence
                       {102, id-cmc-statusInfoEx, {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              [Page 67]

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {102, id-cmc-statusInfoEx, {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 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 request.

   Message #1 from client to server:


























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

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-transactionID, 10132985123483401}
           {103, id-cmc-senderNonce, 10001}
           {104, id-cmc-dataRetrun, <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              [Page 69]

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {101, id-cmc-statusInfoEx, {failed, 201, popRequired}}
           {102, id-cmc-transactionID, 10132985123483401}
           {103, id-cmc-senderNonce, 10005}
           {104, id-cmc-recipientNonce, 10001}
           {105, id-cmc-encryptedPOP, {
              request {
                certRequest
                  certReqId = 201
                   certTemplate
                     subject = <My DN from my signing cert>
                     publicKey = My Public Key
                     extensions
                       {id-ce-keyUsage, keyEncipherment}
                   popo
                     keyEncipherment
                     subsequentMessage
              }
              cms
                contentType = id-envelopedData
                content
                  recipipentInfos.riid.issuerSerialNumber = <NULL, 201>
                  encryptedContentInfo
                    eContentType = id-data
                    eContent = <Encrypted value of 'y'>
              thePOPAlgID = HMAC-SHA1
              witnessAlgID = SHA-1
              witness <hashed value of 'y'>}}
           {106, id-cmc-dataReturn, <packet of binary data identifying
                                     where the key in question is.>}
     certificates
       Newly issued certificate
       Other certificates
     SignedData.SignerInfos
       Signed by CA











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

Internet-Draft               CMS: Structures                  March 2006


   ContentInfo.contentType = id-SignedData
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIData
       eContent
         controlSequence
           {102, id-cmc-transactionID, 10132985123483401}
           {103, id-cmc-senderNonce, 100101}
           {104, id-cmc-dataRetrun, <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
   ContentInfo.content
     SignedData.encapContentInfo
       eContentType = id-ct-PKIResponse
       eContent
         controlSequence
           {101, id-cmc-transactionID, 10132985123483401}
           {102, id-cmc-statusInfoEx, {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              [Page 71]

Internet-Draft               CMS: Structures                  March 2006


       Signed by CA


















































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

Internet-Draft               CMS: Structures                  March 2006


Appendix C.  Change History

   RFC 27XX to -00

   1.  Addition of CMCStatusInfoEx

   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 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              [Page 73]

Internet-Draft               CMS: Structures                  March 2006


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              [Page 74]

Internet-Draft               CMS: Structures                  March 2006


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 Statement

   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.




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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/