PKIX Working Group                                     J. Schaad
Internet Draft                           Soaring Hawk Consulting
                                                        M. Myers
February 2002                                TraceRoute Security
Expires: August 2002                                      X. Liu
                                                            Cisco
                                                     J. Weinstein



                Certificate Management Messages over CMS

                      draft-ietf-pkix-2797-bis-01.txt



Status of this Memo



   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].



   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.



   Comments or suggestions for improvement may be made on the "ietf-
   pkix" mailing list, or directly to the author.



Copyright Notice



   Copyright (C) The Internet Society (2000).  All Rights Reserved.



Abstract



   This document defines a Certificate Management protocol using CMS
   (CMC).  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 [PKCS10], and
   2. The need in [SMIMEV3] 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.



  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

  "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in

  this document are to be interpreted as described in [RFC 2119].



1.  Protocol Requirements



  -  The protocol is to be based as much as possible on the existing
  CMS, PKCS#10 and CRMF specifications.
  -  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.

  -  The protocol needs to easily support the multi-key enrollment
  protocols required by S/MIME and other groups.
  -  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.
  -  The protocol will be designed such that all key generation can
  occur on the client.
  -  The mandatory algorithms must superset the required algorithms
  for S/MIME.

  -  The protocol will contain POP methods. Optional provisions for
  multiple-round trip POP will be made if necessary.
  -  The protocol will support deferred and pending responses to
  certificate request for cases where external procedures are required
  to issue a certificate.
  -  The protocol needs to support arbitrary chains of local
  registration authorities as intermediaries between certificate
  requesters and issuers.



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.

  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.



  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.



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





   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.



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.



  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:



  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



        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:



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

  -  When both CRMF and CMC controls exist with equivalent

  functionality, the CMC control SHOULD be used.  The CMC control MUST

  override the CRMF control.

  -  The regInfo field MUST NOT be used on a CRMF message.  Equivalent

  functionality is provided in the regInfo control attribute (section

  5.12).

  -  The indirect method of proving POP is not supported in this

  protocol.  One of the other methods (including the direct method

  described in this document) MUST be used instead if POP is desired.

  The value of encrCert in SubsequentMessage MUST NOT be used.

  -  Since the subject and publicKeyValues are always present, the

  POPOSigningKeyInput MUST NOT be used when computing the value for

  POPSigningKey.



  A server is not required to use all of the values suggested by the

  client in the certificate template.  Servers MUST be able to process

  all extensions defined, but not prohibited in [PXIXCERT].  Servers

  are not required to be able to process other V3 X.509 extension

  transmitted using this protocol, nor are they required to be able to

  process other, private extensions. Servers are permitted to modify

  client-requested extensions.  Servers MUST NOT alter an extension so

  as to invalidate the original intent of a client-requested

  extension. (For example change key usage from key exchange to

  signing.)  If a certificate request is denied due to the inability

  to handle a requested extension, the server MUST respond with a

  failInfo attribute of unsupportedExt.



3.3.3  Production of Diffie-Hellman Public Key Certification Requests



  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.



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 Id of zero is reserved to designate the

  current PKIData object.  This value is used in control attributes

  such as the Add Extensions Control in the pkiDataReference field to

  refer to a request in the current PKIData object.



  Some control attribute, such as the CMC Status Info attribute, will

  also use Body Part Identifiers to refer to elements in the previous

  message.  This allows an error to be explicit about the attribute or

  request to which the error applies.



3.5  Control Attributes



  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.



  Servers MUST fail the processing of an entire PKIData message if any

  included control attribute is not recognized.  The response MUST be

  the error badRequest and bodyList MUST contain the bodyPartID of the

  invalid or unrecognized control attribute(s).



  The syntax of a control attribute is



     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 three contents used in this location are SignedData,

  EnvelopedData and Data.



  EnvelopedData provides for shrouding of data.  Data allows for

  general transport of unstructured data.



  The SignedData object from [CMS] is also used in this specification

  to provide for authentication as well as serving as the general

  transport wrapper of requests and responses.



3.6.1  Signed Data





  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 publishAutenticatedData control (section 5.2.16).  This

  control is uses the PKIData body so that new controls with

  additional policy type information could be included as well.



3.7  Other Message Bodies



  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-cmc-UnsignedData OBJECT IDENTIFIER ::= {<TBD>}



  CMCUnsignedData ::= SEQUENCE {

      bodyPartPath        SEQUENCE SIZE (1..MAX) OF BodyPartID,

      identifier          OBJECT IDENTIFIER,

      content             ANY DEFINED BY identifier

  }



  There MUST be at most one CMCUnsignedData attribute in the

  UnsignedAttribute sequence of a SignerInfo structure.  If the

  attribute appears in one SignerInfo in a sequence, it MUST appear

  the same in all SignerInfo items and MUST have the same value.



4.  PKI Messages



  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

  Identifier. If duplicate ids are found, the server MUST return the

  error badRequest with a bodyPartID of 0.



  The signedData object wrapping the PKIData may be signed either by

  the private key material of the signature certification request, or

  by a previously certified signature key. If the private key of a

  signature certification request is being used, then:

  a) the certification request containing the corresponding public key

  MUST include a Subject Key Identifier extension,

  b) the subjectKeyIdentifier form of signerInfo MUST be used, and

  c) the value of the subjectKeyIdentifier form of signerInfo MUST be

  the Subject Key Identifier specified in the corresponding

  certification request.



  (The subjectKeyIdentifier form of signerInfo is used here because no

  certificates have yet been issued for the signing key.) If the

  request key is used for signing, there MUST be only one signerInfo

  object in the signedData object.



  When creating a message to renew a certificate, the following should

  be taken into consideration:



  1. The identification and identityProof control statements are not

  required.  The same information is provided by the use of an

  existing certificate from the CA when signing the enrollment

  message.

  2. CAs and LRAs may impose additional restrictions on the signing

  certificate used.  They may require that the most recently issued

  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.



  Clients MUST NOT assume the certificates are in any order. Servers

  SHOULD include all intermediate certificates needed to form complete

  chains to one or more self-signed certificates, not just the newly

  issued certificate(s). The server MAY additionally return CRLs in

  the CRL bag.  Servers MAY include the self-signed certificates.

  Clients MUST NOT implicitly trust included self-signed

  certificate(s) merely due to its presence in the certificate bag. In

  the event clients receive a new self-signed certificate from the

  server, clients SHOULD provide a mechanism to enable the user to

  explicitly trust the certificate.



4.4  Full PKI Response



  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 ore more self-signed certificates, not just the newly

  issued certificate(s). The server MAY additionally return CRLs in

  the CRL bag.  Servers MAY include the self-signed certificates.

  Clients MUST NOT implicitly trust included self-signed

  certificate(s) merely due to its presence in the certificate bag. In

  the event clients receive a new self-signed certificate from the

  server, clients SHOULD provide a mechanism to enable the user to

  explicitly trust the certificate.



4.5  Application of Encryption to a PKI Message





  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.



  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.



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

     -----------------       ----------     --------------

     cMCStatusInfo           id-cmc 1       CMCStatusInfo

     identification          id-cmc 2       UTF8String

     identityProof           id-cmc 3       OCTET STRING

     dataReturn              id-cmc 4       OCTET STRING



     transactionId           id-cmc 5       INTEGER

     senderNonce             id-cmc 6       OCTET STRING

     recipientNonce          id-cmc 7       OCTET STRING

     addExtensions           id-cmc 8       AddExtensions

     encryptedPOP            id-cmc 9       EncryptedPOP

     decryptedPOP            id-cmc 10      DecryptedPOP

     lraPOPWitness           id-cmc 11      LraPOPWitness

     getCert                 id-cmc 15      GetCert

     getCRL                  id-cmc 16      GetCRL

     revokeRequest           id-cmc 17      RevokeRequest

     regInfo                 id-cmc 18      OCTET STRING

     responseInfo            id-cmc 19      OCTET STRING

     QueryPending            id-cmc 21      OCTET STRING

     idPOPLinkRandom         id-cmc 22      OCTET STRING

     idPOPLinkWitness        id-cmc 23      OCTET STRING

     idConfirmCertAcceptance id-cmc 24      CMCCertId

     cmcStatusInfoExt        id-cmc XX      CMCStatusInfoExt

     publishTrustRoot        id-cmc XX      CertificateSequence

     publishAuthenticatedData id-cmc XX     AuthPublish

     batchRequests           id-cmc XX      BodyPartList

     batchResponses          id-cmc XX      BodyPartList



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

  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

  CMCStatusInfoExt control, but MAY additionally use the CMCStatusInfo

  attribute.  Clients MUST be able to process the CMCStatusInfoExt

  control.



5.1.1 Extended CMC Status Info Control Attribute



  This control uses the following ASN.1 definition:



     CMCStatusInfoExt ::= 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

          }

        }

     }





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



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



     -- 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 idConfirmCertAcceptance control is

  required

          -- before use of certificate

     }



5.1.4   CMCFailInfo



  CMCFailInfo conveys information relevant to the interpretation of a

  failure condition. The CMCFailInfo has the following ASN.1

  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)

     }



  Additional failure reasons MAY be defined for closed environments

  with a need.



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

  method and MAY also have a bilateral method of similar strength

  available.



  The CMC method starts with an out-of-band transfer of a token (the

  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

  identity value are hashed rather than just the token.



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

  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 an

  idPOPLinkRandom control attribute.  This control attribute MUST be

  included in the Full PKI Request message.

  5. The 160-bit HMAC-SHA1 result from Step 3 is encoded as the value

  of an idPOPLinkWitness extension to the certificate request.

     a. For CRMF, idPOPLinkWitness is included in the controls section

  of the CertRequest structure.

     b. For PKCS#10, idPOPLinkWitness is included in the attributes

  section of the CertificationRequest structure.



  Upon receipt, servers MUST verify that each certificate request

  contains a copy of the idPOPLinkWitness and that its value was

  derived in the specified manner from the shared secret and the