tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5272

 Errata 
Proposed STD
Pages: 83
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: PKIX

Certificate Management over CMS (CMC)

Part 1 of 4, p. 1 to 23
None       Next RFC Part

Obsoletes:    2797
Updated by:    6402


Top       ToC       Page 1 
Network Working Group                                          J. Schaad
Request for Comments: 5272                       Soaring Hawk Consulting
Obsoletes: 2797                                                 M. Myers
Category: Standards Track                      TraceRoute Security, Inc.
                                                               June 2008


                 Certificate Management over CMS (CMC)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

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

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

   2.  The need for a PKI enrollment protocol for encryption only keys
       due to algorithm or hardware design.

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

Top       Page 2 
Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Protocol Requirements  . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Terminology . . . . . . . . . . . . . . . . .  5
     1.3.  Changes since RFC 2797 . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Protocol Requests/Responses  . . . . . . . . . . . . . . .  9
   3.  PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
     3.2.  Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
       3.2.1.  PKIData Content Type . . . . . . . . . . . . . . . . . 13
         3.2.1.1.  Control Syntax . . . . . . . . . . . . . . . . . . 14
         3.2.1.2.  Certification Request Formats  . . . . . . . . . . 15
           3.2.1.2.1.  PKCS #10 Certification Syntax  . . . . . . . . 16
           3.2.1.2.2.  CRMF Certification Syntax  . . . . . . . . . . 17
           3.2.1.2.3.  Other Certification Request  . . . . . . . . . 18
         3.2.1.3.  Content Info Objects . . . . . . . . . . . . . . . 19
           3.2.1.3.1.  Authenticated Data . . . . . . . . . . . . . . 19
           3.2.1.3.2.  Data . . . . . . . . . . . . . . . . . . . . . 20
           3.2.1.3.3.  Enveloped Data . . . . . . . . . . . . . . . . 20
           3.2.1.3.4.  Signed Data  . . . . . . . . . . . . . . . . . 20
         3.2.1.4.  Other Message Bodies . . . . . . . . . . . . . . . 21
       3.2.2.  Body Part Identification . . . . . . . . . . . . . . . 21
       3.2.3.  CMC Unsigned Data Attribute  . . . . . . . . . . . . . 22
   4.  PKI Responses  . . . . . . . . . . . . . . . . . . . . . . . . 23
     4.1.  Simple PKI Response  . . . . . . . . . . . . . . . . . . . 23
     4.2.  Full PKI Response  . . . . . . . . . . . . . . . . . . . . 24
       4.2.1.  PKIResponse Content Type . . . . . . . . . . . . . . . 24
   5.  Application of Encryption to a PKI Request/Response  . . . . . 25
   6.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
       6.1.1.  Extended CMC Status Info Control . . . . . . . . . . . 28
       6.1.2.  CMC Status Info Control  . . . . . . . . . . . . . . . 30
       6.1.3.  CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
       6.1.4.  CMCFailInfo  . . . . . . . . . . . . . . . . . . . . . 32
     6.2.  Identification and Identity Proof Controls . . . . . . . . 33
       6.2.1.  Identity Proof Version 2 Control . . . . . . . . . . . 33
       6.2.2.  Identity Proof Control . . . . . . . . . . . . . . . . 35
       6.2.3.  Identification Control . . . . . . . . . . . . . . . . 35
       6.2.4.  Hardware Shared-Secret Token Generation  . . . . . . . 36
     6.3.  Linking Identity and POP Information . . . . . . . . . . . 36
       6.3.1.  Cryptographic Linkage  . . . . . . . . . . . . . . . . 37
         6.3.1.1.  POP Link Witness Version 2 Controls  . . . . . . . 37
         6.3.1.2.  POP Link Witness Control . . . . . . . . . . . . . 38
         6.3.1.3.  POP Link Random Control  . . . . . . . . . . . . . 38
       6.3.2.  Shared-Secret/Subject DN Linking . . . . . . . . . . . 39

Top      ToC       Page 3 
       6.3.3.  Renewal and Rekey Messages . . . . . . . . . . . . . . 39
     6.4.  Data Return Control  . . . . . . . . . . . . . . . . . . . 40
     6.5.  RA Certificate Modification Controls . . . . . . . . . . . 40
       6.5.1.  Modify Certification Request Control . . . . . . . . . 41
       6.5.2.  Add Extensions Control . . . . . . . . . . . . . . . . 42
     6.6.  Transaction Identifier Control and Sender and
           Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
     6.7.  Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
     6.8.  RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
     6.9.  Get Certificate Control  . . . . . . . . . . . . . . . . . 49
     6.10. Get CRL Control  . . . . . . . . . . . . . . . . . . . . . 49
     6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
     6.12. Registration and Response Information Controls . . . . . . 52
     6.13. Query Pending Control  . . . . . . . . . . . . . . . . . . 53
     6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
     6.15. Publish Trust Anchors Control  . . . . . . . . . . . . . . 54
     6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
     6.17. Batch Request and Response Controls  . . . . . . . . . . . 56
     6.18. Publication Information Control  . . . . . . . . . . . . . 57
     6.19. Control Processed Control  . . . . . . . . . . . . . . . . 58
   7.  Registration Authorities . . . . . . . . . . . . . . . . . . . 59
     7.1.  Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
     7.2.  Signature Layer Removal  . . . . . . . . . . . . . . . . . 61
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 61
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 62
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 63
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
     11.2. Informative References . . . . . . . . . . . . . . . . . . 63
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 65
   Appendix B.  Enrollment Message Flows  . . . . . . . . . . . . . . 74
     B.1.  Request of a Signing Certificate . . . . . . . . . . . . . 74
     B.2.  Single Certification Request, But Modified by RA . . . . . 75
     B.3.  Direct POP for an RSA Certificate  . . . . . . . . . . . . 78
   Appendix C.  Production of Diffie-Hellman Public Key
                Certification Requests  . . . . . . . . . . . . . . . 81
     C.1.  No-Signature Signature Mechanism . . . . . . . . . . . . . 81

Top      ToC       Page 4 
1.  Introduction

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

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

   2.  The need for a PKI enrollment protocol for encryption only keys
       due to algorithm or hardware design.

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

1.1.  Protocol Requirements

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

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

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

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

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

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

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

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

Top      ToC       Page 5 
   The protocol must support arbitrary chains of Registration
   Authorities (RAs) as intermediaries between certification requesters
   and Certification Authorities (CAs).

1.2.  Requirements Terminology

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

1.3.  Changes since RFC 2797

   We have done a major overhaul on the layout of the document.  This
   included two different steps.  Firstly we removed some sections from
   the document and moved them to two other documents.  Information on
   how to transport our messages are now found in [CMC-TRANS].
   Information on which controls and sections of this document must be
   implemented along with which algorithms are required can now be found
   in [CMC-COMPL].

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

      Extended CMC Status Info Section 6.1.1

      Publish Trust Anchors Section 6.15

      Authenticate Data Section 6.16

      Batch Request and Response Processing Section 6.17

      Publication Information Section 6.18

      Modify Certification Request Section 6.5.1

      Control Processed Section 6.19

      Identity Proof Section 6.2.2

      Identity POP Link Witness V2 Section 6.3.1.1

2.  Protocol Overview

   A PKI enrollment transaction in this specification is generally
   composed of a single round-trip of messages.  In the simplest case a
   PKI enrollment request, henceforth referred to as a PKI Request, is
   sent from the client to the server and a PKI enrollment response,
   henceforth referred to as a PKI Response, is then returned from the

Top      ToC       Page 6 
   server to the client.  In more complicated cases, such as delayed
   certificate issuance, more than one round-trip is required.

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

   PKI Requests are formed using either the PKCS #10 or CRMF structure.
   The two PKI Requests are:

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

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

   PKI Responses are based on SignedData or AuthenticatedData [CMS].
   The two PKI Responses are

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

   Full PKI Response:  a PKIResponse content type wrapped in a
      SignedData.

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

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

   A provision exists for RAs to participate in the protocol by taking
   PKI Requests, wrapping them in a second layer of PKI Request with
   additional requirements or statements from the RA and then passing
   this new expanded PKI Request on to the CA.

Top      ToC       Page 7 
   This specification makes no assumptions about the underlying
   transport mechanism.  The use of CMS does not imply an email-based
   transport.  Several different possible transport methods are defined
   in [CMC-TRANS].

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

2.1.  Terminology

   There are several different terms, abbreviations, and acronyms used
   in this document.  These are defined here, in no particular order,
   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.

   Registration Authority (RA)  or Local RA (LRA) refers to an entity
      that acts as an intermediary between the EE and the CA.  Multiple
      RAs can exist between the end-entity and the Certification
      Authority.  RAs may perform additional services such as key
      generation or key archival.  This document uses the term RA for
      both RA and LRA.

   Certification Authority  (CA) refers to the entity that issues
      certificates.

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

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

   PKCS #10  refers to the Public Key Cryptography Standard #10
      [PKCS10], which defines a certification request syntax.

   CRMF  refers to the Certificate Request Message Format RFC [CRMF].
      CMC uses this certification request syntax defined in this
      document as part of the protocol.

   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.

Top      ToC       Page 8 
   PKI Request/Response  refers to the requests/responses described in
      this document.  PKI Requests include certification requests,
      revocation requests, etc.  PKI Responses include certs-only
      messages, failure messages, etc.

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

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

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

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

      Direct  provides the required POP operation by an encrypted
         challenge/response mechanism.

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

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

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

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

Top      ToC       Page 9 
2.2.  Protocol Requests/Responses

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

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

    +----------+                            +------------------+
    | PKCS #10 |                            | CMS ContentInfo  |
    +----------+--------------+             +------------------+------+
    | Certification Request   |             | CMS Signed Data,        |
    |                         |             |   no SignerInfo         |
    | Subject Name            |             |
    | Subject Public Key Info |             | SignedData contains one |
    |   (K_PUB)               |             | or more certificates in |
    | Attributes              |             | the certificates field  |
    |                         |             | Relevant CA certs and   |
    +-----------+-------------+             | CRLs can be included    |
                | signed with |             | as well.                |
                | matching    |             |                         |
                | K_PRIV      |             | encapsulatedContentInfo |
                +-------------+             | is absent.              |
                                            +--------------+----------+
                                                           | unsigned |
                                                           +----------+

                Figure 1: Simple PKI Requests and Responses

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

    Full PKI Request                        Full PKI Response
    -----------------------                 ------------------------
    +----------------+                      +----------------+
    | CMS ContentInfo|                      | CMS ContentInfo|
    | CMS SignedData |                      | CMS SignedData |
    |   or Auth Data |                      |   or Auth Data |
    |     object     |                      |     object     |
    +----------------+--------+             +----------------+--------+
    |                         |             |                         |
    | PKIData                 |             | PKIResponseBody         |
    |                         |             |                         |
    | Sequence of:            |             | Sequence of:            |
    | <enrollment control>*   |             | <enrollment control>*   |
    | <certification request>*|             | <CMS object>*           |
    | <CMS object>*           |             | <other message>*        |
    | <other message>*        |             |                         |
    |                         |             | where * == zero or more |
    | where * == zero or more |             |                         |
    |                         |             | All certificates issued |
    | Certification requests  |             | as part of the response |
    | are CRMF, PKCS #10, or  |             | are included in the     |
    | Other.                  |             | "certificates" field    |
    |                         |             | of the SignedData.      |
    +-------+-----------------+             | Relevant CA certs and   |
            | signed (keypair |             | CRLs can be included as |
            | used may be pre-|             | well.                   |
            | existing or     |             |                         |
            | identified in   |             +---------+---------------+
            | the request)    |                       | signed by the |
            +-----------------+                       | CA or an LRA  |
                                                      +---------------+

               Figure 2: Full PKI Requests and Responses

3.  PKI Requests

   Two types of PKI Requests exist.  This section gives the details for
   both types.

3.1.  Simple PKI Request

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

Top      ToC       Page 11 
   When a server processes a Simple PKI Request, the PKI Response
   returned is:

   Simple PKI Response  on success.

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

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

   The Simple PKI Request cannot be used if the private key is not
   capable of producing some type of signature (i.e., Diffie-Hellman
   (DH) keys can use the signature algorithms in [DH-POP] for production
   of the signature).

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

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

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

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

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

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

Top      ToC       Page 12 
3.2.  Full PKI Request

   The Full PKI Request provides the most functionality and flexibility.

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

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

   Simple PKI Response  if the enrollment was successful and only
      certificates are returned.  (A CMCStatusInfoV2 control with
      success is implied.)

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

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

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

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

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

   If AuthenticatedData is used, then:

   a.  The Password Recipient Info option of RecipientInfo MUST be used.

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

   c.  The input for the key derivation algorithm is a concatenation of
       the identifier (encoded as UTF8) and the shared-secret.

Top      ToC       Page 13 
   When creating a PKI Request to renew or rekey a certificate:

   a.  The Identification and Identity Proof controls are absent.  The
       same information is provided by the use of an existing
       certificate from a CA when signing the PKI Request.  In this
       case, the CA that issued the original certificate and the CA the
       request is made to will usually be the same, but could have a
       common operator.

   b.  CAs and RAs can impose additional restrictions on the signing
       certificate used.  They may require that the most recently issued
       signing certificate for a client be used.

   c.  Some CAs may prevent renewal operations (i.e., reuse of the same
       keys).  In this case the CA MUST return a PKI Response with
       noKeyReuse as the CMCFailInfo failure code.

3.2.1.  PKIData Content Type

   The PKIData content type is used for the Full PKI Request.  A PKIData
   content type is identified by:

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

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

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

   The fields in PKIData have the following meaning:

   controlSequence  is a sequence of controls.  The controls defined in
      this document are found in Section 6.  Controls can be defined by
      other parties.  Details on the TaggedAttribute structure can be
      found in Section 3.2.1.1.

   reqSequence  is a sequence of certification requests.  The
      certification requests can be a CertificationRequest (PKCS #10), a
      CertReqMsg (CRMF), or an externally defined PKI request.  Full
      details are found in Section 3.2.1.2.  If an externally defined
      certification request is present, but the server does not
      understand the certification request (or will not process it), a
      CMCStatus of noSupport MUST be returned for the certification
      request item and no other certification requests are processed.

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

   otherMsgSequence  is a sequence of arbitrary data objects.  Data
      objects placed here are referred to by one or more controls.  This
      allows for controls to use large amounts of data without the data
      being embedded in the control.  See Section 3.2.1.4 for more
      details.

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

   Processing of the PKIData by a recipient is as follows:

   1.  All controls should be examined and processed in an appropriate
       manner.  The appropriate processing is to complete processing at
       this time, to ignore the control, or to place the control on a
       to-do list for later processing.  Controls can be processed in
       any order; the order in the sequence is not significant.

   2.  Items in the reqSequence are not referenced by a control.  These
       items, which are certification requests, also need to be
       processed.  As with controls, the appropriate processing can be
       either immediate processing or addition to a to-do list for later
       processing.

   3.  Finally, the to-do list is processed.  In many cases, the to-do
       list will be ordered by grouping specific tasks together.

   No processing is required for cmsSequence or otherMsgSequence members
   of PKIData if they are present and are not referenced by a control.
   In this case, the cmsSequence and otherMsgSequence members are
   ignored.

3.2.1.1.  Control Syntax

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

Top      ToC       Page 15 
   The syntax of a control is:

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

     AttributeValue ::= ANY

   The fields in TaggedAttribute have the following meaning:

   bodyPartID  is a unique integer that identifies this control.

   attrType    is the OID that identifies the control.

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

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

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

3.2.1.2.  Certification Request Formats

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

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

   The fields in TaggedRequest have the following meaning:

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

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

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

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

      requestMessageType  identifies the other request type.  These
         values are defined outside of this document.

      requestMessageValue  is the data associated with the other request
         type.

3.2.1.2.1.  PKCS #10 Certification Syntax

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

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

   The fields in TaggedCertificationRequest have the following meaning:

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

Top      ToC       Page 17 
   certificationRequest  contains the PKCS-#10-based certification
      request.  Its fields are described in [PKCS10].

   When producing a certification request based on PKCS #10, clients
   MUST produce the certification request with a subject name and public
   key.  Some PKI products are operated using a central repository of
   information to assign subject names upon receipt of a certification
   request.  To accommodate this mode of operation, the subject field in
   a CertificationRequest MAY be NULL, but MUST be present.  CAs that
   receive a CertificationRequest with a NULL subject field MAY reject
   such certification requests.  If rejected and a PKI Response is
   returned, the CA MUST return a PKI Response with the CMCFailInfo
   value with the value badRequest.

3.2.1.2.2.  CRMF Certification Syntax

   A CRMF message uses the following ASN.1 structure (defined in [CRMF]
   and included here for convenience):

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

   CertRequest ::= SEQUENCE {
     certReqId     INTEGER,        -- ID for matching request and reply
     certTemplate  CertTemplate, --Selected fields of cert to be issued
     controls      Controls OPTIONAL } -- Attributes affecting issuance

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

   The fields in CertReqMsg are explained in [CRMF].

Top      ToC       Page 18 
   This document imposes the following additional restrictions on the
   construction and processing of CRMF certification requests:

      When a Full PKI Request includes a CRMF certification request,
      both the subject and publicKey fields in the CertTemplate MUST be
      defined.  The subject field can be encoded as NULL, but MUST be
      present.

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

      The regInfo field MUST NOT be used on a CRMF certification
      request.  Equivalent functionality is provided in the CMC regInfo
      control (Section 6.12).

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

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

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

3.2.1.2.3.  Other Certification Request

   This document allows for other certification request formats to be
   defined and used as well.  An example of an other certification
   request format is one for Attribute Certificates.  These other
   certification request formats are defined by specifying an OID for
   identification and the structure to contain the data to be passed.

Top      ToC       Page 19 
3.2.1.3.  Content Info Objects

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

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

   The fields in TaggedContentInfo have the following meaning:

   bodyPartID  is a unique integer that identifies this content info
      object.

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

   The four content types used in cmsSequence are AuthenticatedData,
   Data, EnvelopedData, and SignedData.  All of these content types are
   defined in [CMS].

3.2.1.3.1.  Authenticated Data

   The AuthenticatedData content type provides a method of doing pre-
   shared-secret-based validation of data being sent between two
   parties.  Unlike SignedData, it does not specify which party actually
   generated the information.

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

   AuthenticatedData content type is used by this document for:

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

      The top-level wrapper in environments where an encryption-only key
      is being certified.

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

Top      ToC       Page 20 
3.2.1.3.2.  Data

   The Data content type allows for general transport of unstructured
   data.

   The Data content type is used by this document for:

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

3.2.1.3.3.  Enveloped Data

   The EnvelopedData content type provides for shrouding of data.

   The EnvelopedData content type is the primary confidentiality method
   for sensitive information in this protocol.  EnvelopedData can
   provide encryption of an entire PKI Request (see Section 5).
   EnvelopedData can also be used to wrap private key material for key
   archival.  If the decryption on an EnvelopedData fails, a Full PKI
   Response is returned with a CMCFailInfo value of badMessageCheck and
   a bodyPartID of 0.

3.2.1.3.4.  Signed Data

   The SignedData content type provides for authentication and
   integrity.

   The SignedData content type is used by this document for:

      The outer wrapper for a PKI Request.

      The outer wrapper for a PKI Response.

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

   For the PKI Response, SignedData allows the server to sign the
   returning data, if any exists, and to carry the certificates and CRLs
   corresponding to the PKI Request.  If no data is being returned
   beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo
   fields are not populated.

Top      ToC       Page 21 
3.2.1.4.  Other Message Bodies

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

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

   The fields in OtherMsg have the following meaning:

   bodyPartID  is the unique id identifying this data object.

   otherMsgType  is the OID that defines the type of message body.

   otherMsgValue  is the data.

3.2.2.  Body Part Identification

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

      bodyIdMax INTEGER ::= 4294967295

      BodyPartID ::= INTEGER(0..bodyIdMax)

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

   The bodyPartID value of 0 is reserved for use as the reference to the
   current PKIData object.

   Some controls, such as the Add Extensions control (Section 6.5.2),
   use the body part identifier in the pkiDataReference field to refer
   to a PKI Request in the current PKIData.  Some controls, such as the
   Extended CMC Status Info control (Section 6.1.1), will also use body
   part identifiers to refer to elements in the previous PKI Request/

Top      ToC       Page 22 
   Response.  This allows an error to be explicit about the control or
   PKI Request to which the error applies.

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

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

   A BodyPartPath contains a path of body part identifiers moving
   through nesting (i.e., the Modify Certification Request control in
   Section 6.5.1).  The ASN.1 type BodyPartPath is defined as:

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

3.2.3.  CMC Unsigned Data Attribute

   There is sometimes a need to include data in a PKI Request designed
   to be removed by an RA during processing.  An example of this is the
   inclusion of an encrypted private key, where a Key Archive Agent
   removes the encrypted private key before sending it on to the CA.
   One side effect of this desire is that every RA that encapsulates
   this information needs to move the data so that it is not covered by
   that RA's signature.  (A client PKI Request encapsulated by an RA
   cannot have a signed control removed by the Key Archive Agent without
   breaking the RA's signature.)  The CMC Unsigned Data attribute
   addresses this problem.

   The CMC Unsigned Data attribute contains information that is not
   directly signed by a client.  When an RA encounters this attribute in
   the unsigned or unauthenticated attribute field of a request it is
   aggregating, the CMC Unsigned Data attribute is removed from the
   request prior to placing the request in a cmsSequence and placed in
   the unsigned or unauthenticated attributes of the RA's signed or
   authenticated data wrapper.

   The CMC Unsigned Data attribute is identified by:

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

   The CMC Unsigned Data attribute has the ASN.1 definition:

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

Top      ToC       Page 23 
   The fields in CMCUnsignedData have the following meaning:

   bodyPartPath  is the path pointing to the control associated with
      this data.  When an RA moves the control in an unsigned or
      unauthenticated attribute up one level as part of wrapping the
      data in a new SignedData or AuthenticatedData, the body part
      identifier of the embedded item in the PKIData is prepended to the
      bodyPartPath sequence.

   identifier  is the OID that defines the associated data.

   content  is the data.

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



(page 23 continued on part 2)

Next RFC Part