doc: Add RFC documents

1 files changed, 2635 insertions, 0 deletions

diff --git a/doc/rfc/rfc2797.txt b/doc/rfc/rfc2797.txt
new file mode 100644
index 0000000..22b8184
--- /dev/null
+++ b/doc/rfc/rfc2797.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                            M. Myers
+Request for Comments: 2797                                       VeriSign
+Category: Standards Track                                          X. Liu
+                                                                    Cisco
+                                                                J. Schaad
+                                                                Microsoft
+                                                             J. Weinstein
+                                                               April 2000
+
+
+                Certificate Management Messages over CMS
+
+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.
+
+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].
+
+
+
+Myers, et al.               Standards Track                     [Page 1]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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.
+
+
+
+
+Myers, et al.               Standards Track                     [Page 2]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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.
+
+
+
+Myers, et al.               Standards Track                     [Page 3]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   "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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                     [Page 4]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+    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.
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                     [Page 5]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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  OBJECT IDENTIFIER ::= { id-cct 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 certificate requests.  The
+   certificate requests can be either a CertificateRequest (PKCS10
+   request) or a CertReqMsg.  Details on each of these request types are
+   found in sections 3.3.1 and 3.3.2 respectively.
+
+   -- cmsSequence consists of a sequence of [CMS] message objects.  This
+   protocol only uses EnvelopedData, SignedData and EncryptedData.  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.
+
+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 OBJECT IDENTIFIER ::= { id-cct 3 }
+
+
+
+
+
+
+Myers, et al.               Standards Track                     [Page 6]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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 and EncryptedData.  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.
+
+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.
+
+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.
+
+
+
+
+
+Myers, et al.               Standards Track                     [Page 7]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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 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.
+   -  In general, when both CRMF and CMC controls exist with equivalent
+      functionality, the CMC control SHOULD be used.  The CMC control
+      MUST override any CRMF control.
+   -  The regInfo field MUST NOT be used on a CRMF message.  Equivalent
+      functionality is provided in the regInfo control attribute
+      (section 5.12).
+   -  The indirect method of proving POP is not supported in this
+      protocol.  One of the other methods (including the direct method
+      described in this document) MUST be used instead if POP is
+      desired.  The value of encrCert in SubsequentMessage MUST NOT be
+      used.
+
+
+
+
+
+Myers, et al.               Standards Track                     [Page 8]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   -  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 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.
+
+
+
+
+Myers, et al.               Standards Track                     [Page 9]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+3.3.3.2   Diffie-Hellman POP Signature
+
+   CMC compliant implementations MUST support section 5 of [DH-POP].
+
+3.3.3.3   Diffie-Hellman MAC signature
+
+   CMC compliant implementations MAY support section 4 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.
+
+   The syntax of a control attribute is
+
+      TaggedAttribute ::= SEQUENCE {
+          bodyPartID         BodyPartId,
+          attrType           OBJECT IDENTIFIER,
+          attrValues         SET OF AttributeValue
+      }
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 10]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      -- 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.
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 11]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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.
+
+   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.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.
+
+4.  PKI Messages
+
+   This section discusses the details of putting together the different
+   enrollment request and response messages.
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 12]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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.
+
+   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 element in a Full Enrollment Request is identified by a Body
+   Part Identifier. If duplicate ids are found, the server MUST return
+   the error badRequest with a bodyPartID of 0.
+
+   The signedData object wrapping the PKIData may be signed either by
+   the private key material of the signature certification request, or
+   by a previously certified signature key. If the private key of a
+   signature certification request is being used, then:
+   a) the certification request containing the corresponding public key
+      MUST include a Subject Key Identifier extension request,
+   b) the subjectKeyIdentifier form of signerInfo MUST be used, and
+
+
+
+
+Myers, et al.               Standards Track                    [Page 13]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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.
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 14]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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:
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 15]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+     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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 16]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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
+
+5.1  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
+      }
+
+      PendInfo ::= SEQUENCE {
+           pendToken           OCTET STRING,
+           pendTime            GeneralizedTime
+      }
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 17]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      -- cMCStatus is described in section 5.1.1
+
+      -- 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.2. It provides a detailed
+      error on what the failure was.  This choice is present only if
+      cMCStatus is failed.
+
+      -- pendToken is the token to be used in the queryPending control
+      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.1   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)
+
+
+
+
+Myers, et al.               Standards Track                    [Page 18]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+           -- conformation using the idConfirmCertAcceptance control is
+      required
+           -- before use of certificate
+      }
+
+5.1.2   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.
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 19]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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 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.
+
+   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
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 20]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   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.
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 21]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+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 random
+   string included in the idPOPLinkRandom control attribute.
+
+5.3.2  Shared-secret/subject DN matching
+
+   The second technique for doing identity-POP linking is to link a
+   particular subject distinguished name (subject DN) to the shared-
+   secrets that are distributed out-of-band and to require that clients
+   using the shared-secret to prove identity include that exact subject
+   DN in every certificate request.  It is expected that many client-
+   server connections using shared-secret based proof-of-identity will
+   use this mechanism. (It is common not to omit the subject DN
+   information from the certificate request messages.)
+
+   When the shared secret is generated and transferred out-of-band to
+   initiate the registration process (Section 5.2), a particular subject
+   DN is also associated with the shared secret and communicated to the
+   client.  (The subject DN generated MUST be unique per entity in
+
+
+
+Myers, et al.               Standards Track                    [Page 22]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   accordance with CA policy; a null subject DN cannot be used.  A
+   common practice could be to place the identification value as part of
+   the subject DN.)  When the client generates the Full PKI Request
+   message, it MUST use these two pieces of information as follows:
+
+   1. The client MUST include the specific subject DN that it received
+      along with the shared secret as the subject name in every
+      certificate request (PKCS#10 and/or CRMF) in the Full PKI Request.
+      The subject names in the requests MUST NOT be null.
+   2. The client MUST include the identityProof control attribute
+      (Section 5.2), derived from the shared secret, in the Full PKI
+      Request.
+
+   The server receiving this message MUST (a) validate the identityProof
+   control attribute and then, (b) check that the subject DN included in
+   each certificate request matches that associated with the shared
+   secret.  If either of these checks fails the certificate request MUST
+   be rejected.
+
+5.3.3  Renewal and Re-Key Messages
+
+   In a renewal or re-key message, the subject DN in (a) the certificate
+   referenced by the CMS SignerInfo object, and (b) all certificate
+   requests within the request message MUST match according to the
+   standard name match rules described in [PKIXCERT].
+
+5.4  Data Return Control Attribute
+
+   The data return control attribute allows clients to send arbitrary
+   data (usually some type of internal state information) to the server
+   and to have the data returned as part of the enrollment response
+   message.  Data placed in a data return statement is considered to be
+   opaque to the server.  The same control is used for both requests and
+   responses.  If the data return statement appears in an enrollment
+   message, the server MUST return it as part of the enrollment response
+   message.
+
+   In the event that the information in the data return statement needs
+   to be confidential, it is expected that the client would apply some
+   type of encryption to the contained data, but the details of this are
+   outside the scope of this specification.
+
+   An example of using this feature is for a client to place an
+   identifier marking the exact source of the private key material.
+   This might be the identifier of a hardware device containing the
+   private key.
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 23]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+5.5  Add Extensions Control Attribute
+
+   The Add Extensions control attribute is used by LRAs in order to
+   specify additional extensions that are to be placed on certificates.
+   This attribute uses the following ASN.1 definition:
+
+     AddExtensions ::= SEQUENCE {
+         pkiDataReference             BodyPartID
+         certReferences               SEQUENCE OF BodyPartID,
+         extensions                   SEQUENCE OF Extension
+     }
+
+      -- pkiDataReference field contains the body part id of the
+      embedded request message.
+
+      -- certReferences field is a list of references to one or more of
+      the payloads contained within a PKIData.  Each element of the
+      certReferences sequence MUST be equal to either the bodyPartID of
+      a TaggedCertificationRequest or the certReqId of the CertRequest
+      within a CertReqMsg.   By definition, the listed extensions are to
+      be applied to every element referenced in the certReferences
+      sequence.  If a request corresponding to bodyPartID cannot be
+      found, the error badRequest is returned referencing this control
+      attribute.
+
+      -- extensions field contains the sequence of extensions to be
+      applied to the referenced certificate requests.
+
+   Servers MUST be able to process all extensions defined in [PKIXCERT].
+   Servers are not required to be able to process every V3 X.509
+   extension transmitted using this protocol, nor are they required to
+   be able to process other, private extensions.  Servers are not
+   required to put all LRA-requested extensions into a certificate.
+   Servers are permitted to modify LRA-requested extensions.  Servers
+   MUST NOT alter an extension so as to reverse the meaning of a
+   client-requested extension If a certification request is denied due
+   to the inability to handle a requested extension and a response is
+   returned, the server MUST return a failInfo attribute with the value
+   of unsupportedExt.
+
+   If multiple Add Extensions statements exist in an enrollment message,
+   the exact behavior is left up to the certificate issuer policy.
+   However it is recommended that the following policy be used.  These
+   rules would be applied to individual extensions within an Add
+   Extensions control attribute (as opposed to an "all or nothing"
+   approach).
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 24]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   1. If the conflict is within a single PKIData object, the certificate
+      request would be rejected with an error of badRequest.
+
+   2. If the conflict is between different PKIData objects, the
+      outermost version of the extension would be used (allowing an LRA
+      to override the extension requested by the end-entyt).
+
+5.6  Transaction Management Control Attributes
+
+   Transactions are identified and tracked using a transaction
+   identifier.  If used, clients generate transaction identifiers and
+   retain their value until the server responds with a message that
+   completes the transaction.  Servers correspondingly include received
+   transaction identifiers in the response.
+
+   The transactionId attribute identifies a given transaction.  It is
+   used between client and server to manage the state of an operation.
+   Clients MAY include a transactionID attribute in request messages.
+   If the original request contains a transactionID attribute, all
+   subsequent request and response messages MUST include the same
+   transactionID attribute.  A server MUST use only transactionIds in
+   the outermost PKIdata object. TransactionIds on inner PKIdata objects
+   are for intermediate entities.
+
+   Replay protection can be supported through the use of sender and
+   recipient nonces. If nonces are used, in the first message of a
+   transaction, no recipientNonce is transmitted; a senderNonce is
+   instantiated by the message originator and retained for later
+   reference.  The recipient of a sender nonce reflects this value back
+   to the originator as a recipientNonce and includes it's own
+   senderNonce.  Upon receipt by the transaction originator of this
+   message, the originator compares the value of recipientNonce to its
+   retained value.  If the values match, the message can be accepted for
+   further security processing.  The received value for senderNonce is
+   also retained for inclusion in the next message associated with the
+   same transaction.
+
+   The senderNonce and recipientNonce attribute can be used to provide
+   application-level replay prevention. Clients MAY include a
+   senderNonce in the initial request message.  Originating messages
+   include only a value for senderNonce. If a message includes a
+   senderNonce, the response MUST include the transmitted value of the
+   previously received senderNonce as recipientNonce and include new
+   value for senderNonce. A server MUST use only nonces in the outermost
+   PKIdata object. Nonces on inner PKIdata objects are for intermediate
+   entities.
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 25]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+5.7  Proof-of-possession (POP) for encryption-only keys
+
+   Everything described in this section is optional to implement, for
+   both servers and clients. Servers MAY require this POP method be used
+   only if another POP method is unavailable. Servers SHOULD reject all
+   requests contained within a PKIData if any required POP is missing
+   for any element within the PKIData.
+
+   Many servers require proof that an entity requesting a certificate
+   for a public key actually possesses the corresponding private
+   component of the key pair.  For keys that can be used as signature
+   keys, signing the certification request with the private key serves
+   as a POP on that key pair.  With keys that can only be used for
+   encryption operations, POP MUST be performed by forcing the client to
+   decrypt a value.  See Section 5 of [CRMF] for a detailed discussion
+   of POP.
+
+   By necessity, POP for encryption-only keys cannot be done in one
+   round-trip, since there are four distinct phases:
+
+   1. Client tells the server about the public component of a new
+      encryption key pair.
+   2. Server sends the client a POP challenge, encrypted with the
+      presented public encryption key, which the client must decrypt.
+   3. Client decrypts the POP challenge and sends it back to the server.
+   4. Server validates the decrypted POP challenge and continues
+      processing the certificate request.
+
+   CMC defines two different attributes.  The first deals with the
+   encrypted challenge sent from the server to the user in step 2.  The
+   second deals with the decrypted challenge sent from the client to the
+   server in step 3.
+
+   The encryptedPOP attribute is used to send the encrypted challenge
+   from the server to the client.  As such, it is encoded as a tagged
+   attribute within the controlSequence of a ResponseBody.  (Note that
+   we assume that the message sent in Step 1 above is an enrollment
+   request and that the response in step 2 is a Full Enrollment Response
+   including a failureInfo specifying that a POP is explicitly required,
+   and providing the POP challenge in the encryptedPOP attribute.)
+
+      EncryptedPOP ::= SEQUENCE {
+
+           request        TaggedRequest,
+           cms            contentInfo,
+           thePOPAlgID    AlgorithmIdentifier,
+           witnessAlgID   AlgorithmIdentifier,
+           witness        OCTET STRING
+
+
+
+Myers, et al.               Standards Track                    [Page 26]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      }
+
+      DecryptedPOP ::= SEQUENCE {
+           bodyPartID     BodyPartID,
+           thePOPAlgID    AlgorithmIdentifier,
+           thePOP         OCTET STRING
+      }
+
+   The encrypted POP algorithm works as follows:
+
+   1. The server generates a random value y and associates it with the
+      request.
+   2. The server returns the encrypted pop with the following fields
+      set:
+      a. request is the certificate request in the original request
+         message (it is included here so the client need not key a copy
+         of the request),
+      b. cms is an EnvelopedData object, the content type being id-data
+         and the content being the value y.  If the certificate request
+         contains a subject key identifier (SKI) extension, then the
+         recipient identifier SHOULD be the SKI.  If the
+         issuerAndSerialNumber form is used, the IsserName MUST be
+         encoded as NULL and the SerialNumber as the bodyPartId of the
+         certificate request,
+      c. thePOPAlgID contains the algorithm to be used in computing the
+         return POP value,
+      d. witnessAlgID contains the hash algorithm used on y to create
+         the field witness,
+      e. witness contains the hashed value of y.
+   3. The client decrypts the cms field to obtain the value y.  The
+      client computes H(y) using the witnessAlgID and compares to the
+      value of witness.  If the values do not compare or the decryption
+      is not successful, the client MUST abort the enrollment process.
+      The client aborts the process by sending a request message
+      containing a CMCStatusInfo control attribute with failInfo value
+      of popFailed.
+   4. The client creates the decryptedPOP as part of a new PKIData
+      message.  The fields in the decryptedPOP are:
+      a. bodyPartID refers to the certificate request in the new
+         enrollment message,
+      b. thePOPAlgID is copied from the encryptedPOP,
+      c. thePOP contains the possession proof.  This value is computed
+         by thePOPAlgID using the value y and request referenced in
+         (4a).
+   5. The server then re-computes the value of thePOP from its cached
+      value of y and the request and compares to the value of thePOP.
+      If the values do not match, the server MUST NOT issue the
+      certificate.  The server MAY re-issue a new challenge or MAY fail
+
+
+
+Myers, et al.               Standards Track                    [Page 27]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      the request altogether.
+
+   When defining the algorithms for thePOPAlgID and witnessAlgID care
+   must be taken to ensure that the result of witnessAlgID is not a
+   useful value to shortcut the computation with thePOPAlgID.  Clients
+   MUST implement SHA-1 for witnessAlgID.  Clients MUST implement HMAC-
+   SHA1 for thePOPAlgID.  The value of y is used as the secret value in
+   the HMAC algorithm and the request referenced in (4a) is used as the
+   data.  If y is greater than 64 bytes, only the first 64 bytes of y
+   are used as the secret.
+
+   One potential problem with the algorithm above is the amount of state
+   that a CA needs to keep in order to verify the returned POP value.
+   This describes one of many possible ways of addressing the problem by
+   reducing the amount of state kept on the CA to a single (or small
+   set) of values.
+
+   1. Server generates random seed x, constant across all requests. (The
+      value of x would normally be altered on a regular basis and kept
+      for a short time afterwards.)
+   2. For certificate request R, server computes y = F(x,R).  F can be,
+      for example, HMAC-SHA1(x,R).  All that's important for
+      statelessness is that y be consistently computable with only known
+      state constant x and function F, other inputs coming from the cert
+      request structure.  y should not be predictable based on knowledge
+      of R, thus the use of a OWF like HMAC-SHA1.
+
+5.8  LRA POP Witnesses Control Attribute
+
+   In an enrollment scenario involving an LRAs the CA may allow (or
+   require) the LRA to perform the POP protocol with the entity
+   requesting certification.  In this case the LRA needs a way to inform
+   the CA it has done the POP.  This control attribute has been created
+   to address this issue.
+
+   The ASN.1 structure for the LRA POP witness is as follows:
+
+      LraPopWitness ::= SEQUENCE {
+          pkiDataBodyid   BodyPartID,
+          bodyIds         SEQUENCE of BodyPartID
+      }
+
+      -- pkiDataBodyid field contains the body part id of the nested CMS
+      body object containing the client's full request message.
+      pkiDataBodyid is set to 0 if the request is in the current
+      PKIRequest body.
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 28]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      -- bodyIds contains a list of certificate requests for which the
+      LRA has performed an out-of-band authentication.  The method of
+      authentication could be archival of private key material,
+      challenge-response or other means.
+
+   If a certificate server does not allow for an LRA to do the POP
+   verification, it returns an error of POPFAILURE.  The CA MUST NOT
+   start a challenge-response to re-verify the POP itself.
+
+5.9  Get Certificate Control Attribute
+
+   Everything described in this section is optional to implement.
+
+   The get certificate control attribute is used to retrieve previously
+   issued certificates from a repository of certificates.  A Certificate
+   Authority, an LRA or an independent service may provide this
+   repository.  The clients expected to use this facility are those
+   operating in a resource-constrained environment.  (An example of a
+   resource-constrained client would be a low-end IP router that does
+   not retain its own certificate in non-volatile memory.)
+
+   The get certificate control attribute has the following ASN.1
+   structure:
+
+      GetCert ::= SEQUENCE {
+          issuerName    GeneralName,
+          serialNumber  INTEGER }
+
+   The service responding to the request will place the requested
+   certificate in the certificates field of a SignedData object.  If the
+   get certificate attribute is the only control in a Full PKI Request
+   message, the response would be a Simple Enrollment Response.
+
+5.10 Get CRL Control Attribute
+
+   Everything described in this section is optional to implement.
+
+   The get CRL control attribute is used to retrieve CRLs from a
+   repository of CRLs.  A Certification Authority, an LRA or an
+   independent service may provide this repository.  The clients
+   expected to use this facility are those where a fully deployed
+   directory is either infeasible or undesirable.
+
+   The get CRL control attribute has the following ASN.1 structure:
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 29]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      GetCRL ::= SEQUENCE {
+          issuerName    Name,
+          cRLName       GeneralName OPTIONAL,
+          time          GeneralizedTime OPTIONAL,
+          reasons       ReasonFlags OPTIONAL }
+
+   The fields in a GetCRL have the following meanings:
+
+      -- issuerName is the name of the CRL issuer.
+
+      -- cRLName may be the value of CRLDistributionPoints in the
+      subject certificate or equivalent value in the event the
+      certificate does not contain such a value.
+
+      -- time is used by the client to specify from among potentially
+      several issues of CRL that one whose thisUpdate value is less than
+      but nearest to the specified time.  In the absence of a time
+      component, the CA always returns with the most recent CRL.
+
+      -- reasons is used to specify from among CRLs partitioned by
+      revocation reason.  Implementers should bear in mind that while a
+      specific revocation request has a single CRLReason code--and
+      consequently entries in the CRL would have a single CRLReason code
+      value--a single CRL can aggregate information for one or more
+      reasonFlags.
+
+   A service responding to the request will place the requested CRL in
+   the crls field of a SignedData object.  If the get CRL attribute is
+   the only control in a full enrollment message, the response would be
+   a simple enrollment response.
+
+5.11 Revocation Request Control Attribute
+
+   The revocation request control attribute is used to request that a
+   certificate be revoked.
+
+   The revocation request control attribute has the following ASN.1
+   syntax:
+
+      RevRequest ::= SEQUENCE {
+          issuerName      Name,
+          serialNumber    INTEGER,
+          reason          CRLReason,
+          invalidityDate  GeneralizedTime OPTIONAL,
+          sharedSecret    OCTET STRING OPTIONAL,
+          comment         UTF8string OPTIONAL }
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 30]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+      -- issuerName contains the issuerName of the certificate to be
+      revoked.
+
+      -- serialNumber contains the serial number of the certificate to
+      be revoked
+
+      -- reason contains the suggested CRLReason code for why the
+      certificate is being revoked.  The CA can use this value at its
+      discretion in building the CRL.
+
+      -- invalidityDate contains the suggested value for the Invalidity
+      Date CRL Extension.  The CA can use this value at its discretion
+      in building the CRL.
+
+      -- sharedSecret contains a secret value registered by the EE when
+      the certificate was obtained to allow for revocation of a
+      certificate in the event of key loss.
+
+      -- comment contains a human readable comment.
+
+   For a revocation request to become a reliable object in the event of
+   a dispute, a strong proof of originator authenticity is required.
+   However, in the instance when an end-entity has lost use of its
+   signature private key, it is impossible for the end-entity to produce
+   a digital signature (prior to the certification of a new signature
+   key pair). The RevRequest provides for the optional transmission from
+   the end-entity to the CA of a shared secret that may be used as an
+   alternative authenticator in the instance of loss of use. The
+   acceptability of this practice is a matter of local security policy.
+
+   (Note that in some situations a Registration Authority may be
+   delegated authority to revoke certificates on behalf of some
+   population within its scope control.  In these situations the CA
+   would accept the LRA's digital signature on the request to revoke a
+   certificate, independent of whether the end entity still had access
+   to the private component of the key pair.)
+
+   Clients MUST provide the capability to produce a digitally signed
+   revocation request control attribute.  Clients SHOULD be capable of
+   producing an unsigned revocation request containing the end-entity's
+   shared secret.  If a client provides shared secret based self-
+   revocation, the client MUST be capable of producing a revocation
+   request containing the shared secret. Servers MUST be capable of
+   accepting both forms of revocation requests.
+
+   The structure of an unsigned, shared secret based revocation request
+   is a matter of local implementation.  The shared secret does not need
+   to be encrypted when sent in a revocation request.  The shared secret
+
+
+
+Myers, et al.               Standards Track                    [Page 31]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   has a one-time use, that of causing the certificate to be revoked,
+   and public knowledge of the shared secret after the certificate has
+   been revoked is not a problem.  Clients need to inform users that the
+   same shared secret SHOULD NOT be used for multiple certificates.
+
+   A full response message MUST be returned for a revocation request.
+
+5.12 Registration and Response Information Control Attributes
+
+   The regInfo control attribute is for clients and LRAs to pass
+   additional information as part a PKI request.  The regInfo control
+   attribute uses the ASN.1 structure:
+
+      RegInfo ::= OCTET STRING
+
+   The content of this data is based on bilateral agreement between the
+   client and server.
+
+   If a server (or LRA) needs to return information back to a requestor
+   in response to data submitted in a regInfo attribute, then that data
+   is returned as a responseInfo control attribute.  The content of the
+   OCTET STRING for response information is based on bilateral agreement
+   between the client and server.
+
+5.13 Query Pending Control Attribute
+
+   In some environments, process requirements for manual intervention or
+   other identity checking can cause a delay in returning the
+   certificate related to a certificate request. The query pending
+   attribute allows for a client to query a server about the state of a
+   pending certificate request.  The server returns a token as part of
+   the CMCStatusInfo attribute (in the otherInfo field).  The client
+   puts the token into the query pending attribute to identify the
+   correct request to the server.  The server can also return a
+   suggested time for the client to query for the state of a pending
+   certificate request.
+
+   The ASN.1 structure used by the query pending control attribute is:
+
+      QueryPending ::= OCTET STRING
+
+   If a server returns a pending state (the transaction is still
+   pending), the otherInfo MAY be omitted.  If it is not omitted then
+   the same value MUST be returned (the token MUST NOT change during the
+   request).
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 32]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+5.14 Confirm Certificate Acceptance
+
+   Some Certification Authorities require that clients give a positive
+   conformation that the certificates issued to it are acceptable.  The
+   Confirm Certificate Acceptance control attribute is used for that
+   purpose.  If the CMCStatusInfo on a certificate request is
+   confirmRequired, then the client MUST return a Confirm Certificate
+
+   Acceptance prior to any usage of the certificate.  Clients SHOULD
+   wait for the response from the server that the conformation has been
+   received.
+
+   The confirm certificate acceptance structure is:
+
+      CMCCertId ::= IssuerSerial
+
+      -- CMCCertId contains the issuer and serial number of the
+      certificate being accepted.
+
+   Servers MUST return a full enrollment response for a confirm
+   certificate acceptance control.
+
+6.  Local Registration Authorities
+
+   This specification permits the use of Local Registration Authorities
+   (LRAs).  An LRA sits between the end-entity and the Certification
+   Authority.  From the end-entity's perspective, the LRA appears to be
+   the Certification Authority and from the server the LRA appears to be
+   a client.  LRAs receive the enrollment messages, perform local
+   processing and then forward onto Certificate Authorities. Some of the
+   types of local processing that an LRA can perform include:
+
+   -  batching multiple enrollment messages together,
+   -  challenge/response POP proofs,
+   -  addition of private or standardized certificate extensions to all
+      requests,
+   -  archival of private key material,
+   -  routing of requests to different CAs.
+
+   When an LRA receives an enrollment message it has three options: it
+   may forward the message without modification, it may add a new
+   wrapping layer to the message, or it may remove one or more existing
+   layers and add a new wrapping layer.
+
+   When an LRA adds a new wrapping layer to a message it creates a new
+   PKIData object.  The new layer contains any control attributes
+   required (for example if the LRA does the POP proof for an encryption
+   key or the addExtension control attribute to modify an enrollment
+
+
+
+Myers, et al.               Standards Track                    [Page 33]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   request) and the client enrollment message.  The client enrollment
+   message is placed in the cmsSequence if it is a Full Enrollment
+   message and in the reqSequence if it is a Simple Enrollment message.
+   If an LRA is batching multiple client messages together, then each
+   client enrollment message is placed into the appropriate location in
+   the LRA's PKIData object along with all relevant control attributes.
+
+   (If multiple LRAs are in the path between the end-entity and the
+   Certification Authority, this will lead to multiple wrapping layers
+   on the message.)
+
+   In processing an enrollment message, an LRA MUST NOT alter any
+   certificate request body (PKCS #10 or CRMF) as any alteration would
+   invalidate the signature on the request and thus the POP for the
+   private key.
+
+   An example of how this would look is illustrated by the following
+   figure:
+
+      SignedData (by LRA)
+        PKIData
+          controlSequence
+                  LRA added control statements
+          reqSequence
+                  Zero or more Simple CertificationRequests from clients
+          cmsSequence
+                  Zero or more Full PKI messages from clients
+                     SignedData (by client)
+                         PKIData
+
+   Under some circumstances an LRA is required to remove wrapping
+   layers.  The following sections look at the processing required if
+   encryption layers and signing layers need to be removed.
+
+6.1  Encryption Removal
+
+   There are two cases that require an LRA to remove or change
+   encryption in an enrollment message.  In the first case the
+   encryption was applied for the purposes of protecting the entire
+   enrollment request from unauthorized entities.  If the CA does not
+   have a recipient info entry in the encryption layer, the LRA MUST
+   remove the encryption layer.  The LRA MAY add a new encryption layer
+   with or without adding a new signing layer.
+
+   The second change of encryption that may be required is to change the
+   encryption inside of a signing layer.  In this case the LRA MUST
+   remove all signing layers containing the encryption.  All control
+   statements MUST be merged according to local policy rules as each
+
+
+
+Myers, et al.               Standards Track                    [Page 34]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   signing layer is removed and the resulting merged controls MUST be
+   placed in a new signing layer provided by the LRA.  If the signing
+   layer provided by the end-entity needs to be removed to the LRA can
+   remove the layer.
+
+6.2  Signature Layer Removal
+
+   Only two instances exist where an LRA should remove a signature layer
+   on a Full Enrollment message.  If an encryption needs to be modified
+   within the message, or if a Certificate Authority will not accept
+   secondary delegation (i.e. multiple LRA signatures).  In all other
+   situations LRAs SHOULD NOT remove a signing layer from a message.
+
+   If an LRA removes a signing layer from a message, all control
+   statements MUST be merged according to local policy rules.  The
+   resulting merged control statements MUST be placed in a new signing
+   layer provided by the LRA.
+
+7.  Transport Wrapping
+
+   Not all methods of transporting data allow for sending unlabeled raw
+   binary data, in may cases standard methods of encoding can be used to
+   greatly ease this issue.  These methods normally consist of wrapping
+   some identification of the content around the binary data, possibly
+   applying an encoding to the data and labeling the data.   We document
+   for use three different wrapping methods.
+
+   -- MIME wrapping is for transports that are natively MIME based such
+      as HTTP and E-mail.
+   -- Binary file transport is defined since floppy disk transport is
+      still very common.  File transport can be done either as MIME
+      wrapped (section 7.1) or bare (section 7.2).
+   -- Socket based transport uses the raw BER encoded object.
+
+7.1  MIME Wrapping
+
+   MIME wrapping is defined for those environments that are MIME native.
+   These include E-Mail based protocols as well as HTTP.
+
+   The basic mime wrapping in this section is taken from [SMIMEV2] and
+   [SMIMEV3].  Simple enrollment requests are encoded using the
+   application/pkcs10 content type.  A file name MUST be included either
+   in a content type or content disposition statement.  The extension
+   for the file MUST be ".p10".
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 35]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   Simple enrollment response messages MUST be encoded as content-type
+   application/pkcs7-mime.  An smime-type parameter MUST be on the
+   content-type statement with a value of "certs-only." A file name with
+   the ".p7c" extension MUST be specified as part of the content-type or
+   content-disposition.
+
+   Full enrollment request messages MUST be encoded as content-type
+   application/pkcs7-mime.  The smime-type parameter MUST be included
+   with a value of "CMC-enroll".  A file name with the ".p7m" extension
+   MUST be specified as part of the content-type or content-disposition
+   statement.
+
+   Full enrollment response messages MUST be encoded as content-type
+   application/pkcs7-mime.  The smime-type parameter MUST be included
+   with a value of "CMC-response."  A file name with the ".p7m"
+   extensions MUST be specified as part of the content-type or content-
+   disposition.
+
+MIME TYPE                       File Extension        SMIME-TYPE
+
+application/pkcs10                .p10                  N/A
+(simple PKI request)
+
+application/pkcs7-mime            .p7m                  CMC-request
+(full PKI request)
+
+application/pkcs7-mime            .p7c                  certs-only
+(simple PKI response)
+
+application/pkcs7-mime            .p7m                  CMC-response
+(full PKI response)
+
+7.2  File-Based Transport
+
+   Enrollment messages and responses may also be transferred between
+   clients and servers using file system-based mechanisms, such as when
+   enrollment is performed for an off-line client.  When files are used
+   to transport binary, BER-encoded Full Enrollment Request and Response
+   messages, the following file type extensions SHOULD be used:
+
+   Message Type                   File Extension
+
+   Full PKI Request                 .crq
+
+   Full PKI Response                .crp
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 36]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+7.3  Socket-Based Transport
+
+   When enrollment messages and responses are sent over sockets, no
+   wrapping is required.  Messages SHOULD be sent in their binary, BER-
+   encoded form.
+
+8.  Interoperability
+
+8.1  Mandatory and Optional Algorithms
+
+   CMC clients and servers MUST be capable of producing and processing
+   message signatures using the Digital Signature Algorithm [DSA].  DSA
+   signatures MUST be indicated by the DSA AlgorithmIdentifier value (as
+   specified in section 7.2.2 of [PKIXCERT]).  PKI clients and servers
+   SHOULD also be capable of producing and processing RSA signatures (as
+   specified in section 7.2.1 of [PKIXCERT]).
+
+   CMC clients and servers MUST be capable of protecting and accessing
+   message encryption keys using the Diffie-Hellman (D-H) key exchange
+   algorithm.  D-H/3DES protection MUST be indicated by the D-H
+   AlgorithmIdentifier value specified in [CMS].  PKI clients and
+   servers SHOULD also be capable of producing and processing RSA key
+   transport.  When used for PKI messages, RSA key transport MUST be
+   indicated as specified in section 7.2.1 of [PKIXCERT].
+
+8.2  Minimum Conformance Requirements
+
+   A minimally compliant CMC server:
+
+   a) MUST accept a Full PKI Request message
+      i) MUST accept CRMF Request Bodies within a Full PKI Request
+      ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
+   b) MUST accept a Simple Enrollment Request message
+   c) MUST be able to return a Full PKI Response.  (A Full PKI Response
+      is always a valid response, but for interoperability with
+      downlevel clients a compliant server SHOULD use the Simple
+      Enrollment Response whenever possible.)
+
+   A minimally-complaint CMC client:
+
+   a) MAY use either the Simple Enrollment Message or the Full PKI
+      Request.
+      i) clients MUST use PKCS#10 with the Simple Enrollment Message
+      ii) clients MAY use either PKCS#10 or CRMF with the Full PKI
+         Request
+   b) MUST understand the Simple Enrollment Response.
+   c) MUST understand the Full PKI Response.
+
+
+
+
+Myers, et al.               Standards Track                    [Page 37]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+9.  Security Considerations
+
+   Initiation of a secure communications channel between an end-entity
+   and a CA or LRA (and, similarly, between an LRA and another LRA or
+   CA) necessarily requires an out-of-band trust initiation mechanism.
+   For example, a secure channel may be constructed between the end-
+   entity and the CA via IPSEC or TLS. Many such schemes exist and the
+   choice of any particular scheme for trust initiation is outside the
+   scope of this document.  Implementers of this protocol are strongly
+   encouraged to consider generally accepted principles of secure key
+   management when integrating this capability within an overall
+   security architecture.
+
+   Mechanisms for thwarting replay attacks may be required in particular
+   implementations of this protocol depending on the operational
+   environment. In cases where the CA maintains significant state
+   information, replay attacks may be detectable without the inclusion
+   of the optional nonce mechanisms. Implementers of this protocol need
+   to carefully consider environmental conditions before choosing
+   whether or not to implement the senderNonce and recipientNonce
+   attributes described in section 5.6.  Developers of state-constrained
+   PKI clients are strongly encouraged to incorporate the use of these
+   attributes.
+
+   Under no circumstances should a signing key be archived.  Doing so
+   allows the archiving entity to potentially use the key for forging
+   signatures.
+
+   Due care must be taken prior to archiving keys.  Once a key is given
+   to an archiving entity, the archiving entity could use the keys in a
+   way not conducive to the archiving entity.  Users should be made
+   especially aware that proper verification is made of the certificate
+   used to encrypt the private key material.
+
+   Clients and servers need to do some checks on cryptographic
+   parameters prior to issuing certificates to make sure that weak
+   parameters are not used. A description of the small subgroup attack
+   is provided in [X942].  CMC implementations ought to be aware of this
+   attack when doing parameter validations.
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 38]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+10. Acknowledgments
+
+   The authors would like to thank Brian LaMacchia for his work in
+   developing and writing up many of the concepts presented in this
+   document.  The authors would also like to thank Alex Deacon and Barb
+   Fox for their contributions.
+
+11. References
+
+   [CMS]      Housley, R., "Cryptographic Message Syntax", RFC 2630,
+              June 1999.
+
+   [CRMF]     Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
+              X.509 Certificate Request Message Format", RFC 2511, March
+              1999.
+
+   [DH]       B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
+
+   [DH-POP]   H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-
+              Possession Algorithms", Work in Progress.
+
+   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [PKCS1]    Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
+              2313, March 1998.
+
+   [PKCS7]    Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5",
+              RFC 2315, October 1997.
+
+   [PKCS8]    RSA Laboratories, "PKCS#8: Private-Key Information Syntax
+              Standard, Version 1.2", November 1, 1993.
+
+   [PKCS10]   Kaliski, B., "PKCS #10: Certification Request Syntax
+              v1.5", RFC 2314, October 1997.
+
+   [PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
+              X.509 Public Key Infrastructure Certificate and CRL
+              Profile", RFC 2459, January 1999.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SMIMEV2]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
+              Repka, "S/MIME Version 2 Message Specification", RFC 2311,
+              March 1998.
+
+
+
+
+Myers, et al.               Standards Track                    [Page 39]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+   [SMIMEV3]  Ramsdell, B., "S/MIME Version 3 Message Specification",
+              RFC 2633, June 1999.
+
+   [X942]     Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
+              2631, June 1999.
+
+12. Authors' Addresses
+
+   Michael Myers
+   VeriSign Inc.
+   1350 Charleston Road
+   Mountain View, CA, 94043
+
+   Phone: (650) 429-3402
+   EMail: mmyers@verisign.com
+
+
+   Xiaoyi Liu
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134
+
+   Phone: (480) 526-7430
+   EMail: xliu@cisco.com
+
+
+   Jim Schaad
+
+   EMail:  jimsch@nwlink.com
+
+
+   Jeff Weinstein
+
+   EMail: jsw@meer.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 40]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+Appendix A  ASN.1 Module
+
+EnrollmentMessageSyntax
+   { iso(1) identified-organization(3) dod(4) internet(1)
+   security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
+
+   DEFINITIONS IMPLICIT TAGS ::=
+   BEGIN
+
+   -- EXPORTS All --
+   -- The types and values defined in this module are exported for use
+   -- in the other ASN.1 modules.  Other applications may use them for
+   -- their own purposes.
+
+   IMPORTS
+
+     -- Information Directory Framework (X.501)
+           Name
+              FROM InformationFramework { joint-iso-itu-t ds(5)
+                   modules(1) informationFramework(1) 3 }
+
+     -- Directory Authentication Framework (X.509)
+           AlgorithmIdentifier, AttributeCertificate, Certificate,
+           CertificateList, CertificateSerialNumber
+              FROM AuthenticationFramework { joint-iso-itu-t ds(5)
+                   module(1) authenticationFramework(7) 3 }
+
+     -- PKIX Part 1 - Implicit
+        GeneralName, CRLReason, ReasonFlags
+        FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
+                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                id-pkix1-implicit-88(2)}
+
+     -- PKIX Part 1 - Explicit
+        SubjectPublicKeyInfo, Extension
+        FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
+                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                id-pkix1-explicit-88(1)}
+
+     -- Cryptographic Message Syntax
+        ContentInfo, Attribute
+          FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
+
+     -- CRMF
+        CertReqMsg
+        FROM CRMF { 1 3 6 1 5 5 7 0 5 };
+
+    id-pkix OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
+
+
+
+Myers, et al.               Standards Track                    [Page 41]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+        dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+        id-cmc OBJECT IDENTIFIER ::= {id-pkix 7}   -- CMC controls
+        id-cct OBJECT IDENTIFIER ::= {id-pkix 12}  -- CMC content types
+
+    -- The following controls have simple type content (usually OCTET
+STRING)
+
+    id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
+    id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
+    id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
+    id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
+    id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
+    id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
+    id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
+    id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
+    id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
+    id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
+    id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
+
+    -- This is the content type used for a request message in the
+protocol
+
+    id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
+
+
+    PKIData ::= SEQUENCE {
+        controlSequence    SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+        reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,
+        cmsSequence        SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+        otherMsgSequence   SEQUENCE SIZE(0..MAX) OF OtherMsg
+    }
+
+    bodyIdMax INTEGER ::= 4294967295
+
+    BodyPartID ::= INTEGER(0..bodyIdMax)
+
+    TaggedAttribute ::= SEQUENCE {
+        bodyPartID         BodyPartId,
+        attrType           OBJECT IDENTIFIER,
+        attrValues         SET OF AttributeValue
+    }
+
+    AttributeValue ::= ANY
+
+    TaggedRequest ::= CHOICE {
+        tcr               [0] TaggedCertificationRequest,
+        crm               [1] CertReqMsg
+
+
+
+Myers, et al.               Standards Track                    [Page 42]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+    }
+
+    TaggedCertificationRequest ::= SEQUENCE {
+        bodyPartID            BodyPartID,
+        certificationRequest  CertificationRequest
+    }
+
+    CertificationRequest ::= SEQUENCE {
+      certificationRequestInfo  SEQUENCE {
+        version                   INTEGER,
+        subject                   Name,
+        subjectPublicKeyInfo      SEQUENCE {
+          algorithm                 AlgorithmIdentifier,
+          subjectPublicKey          BIT STRING },
+        attributes                [0] IMPLICIT SET OF Attribute },
+      signatureAlgorithm        AlgorithmIdentifier,
+      signature                 BIT STRING
+    }
+
+    TaggedContentInfo ::= SEQUENCE {
+        bodyPartID              BodyPartId,
+        contentInfo             ContentInfo
+    }
+
+    OtherMsg ::= SEQUENCE {
+        bodyPartID        BodyPartID,
+        otherMsgType      OBJECT IDENTIFIER,
+        otherMsgValue     ANY DEFINED BY otherMsgType }
+
+    --  This defines the response message in the protocol
+    id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
+
+    ResponseBody ::= SEQUENCE {
+        controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+        cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+        otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
+    }
+
+    -- Used to return status state in a response
+
+    id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
+
+    CMCStatusInfo ::= SEQUENCE {
+        cMCStatus       CMCStatus,
+        bodyList        SEQUENCE SIZE (1..MAX) OF INTEGER,
+        statusString    UTF8String OPTIONAL,
+        otherInfo        CHOICE {
+          failInfo         CMCFailInfo,
+
+
+
+Myers, et al.               Standards Track                    [Page 43]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+          pendInfo         PendInfo } OPTIONAL
+    }
+
+    PendInfo ::= SEQUENCE {
+        pendToken        INTEGER,
+        pendTime         GENERALIZEDTIME
+    }
+
+    CMCStatus ::= INTEGER {
+        success         (0),
+        -- you got exactly what you asked for
+        failed          (2),
+        -- you don't get it, more information elsewhere in the message
+        pending         (3),
+        -- the request body part has not yet been processed,
+        -- requester is responsible to poll back on this
+        noSupport       (4)
+        -- the requested operation is not supported
+    }
+
+    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),
+        -- Server failed to get an acceptable POP for the request
+        noKeyReuse      (10)
+        -- Server policy does not allow key re-use
+        internalCAError (11)
+        tryLater        (12)
+
+
+
+Myers, et al.               Standards Track                    [Page 44]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+    }
+
+    -- Used for LRAs to add extensions to certificate requests
+    id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
+
+    AddExtensions ::= SEQUENCE {
+        pkiDataReference    BodyPartID,
+        certReferences      SEQUENCE OF BodyPartID,
+        extensions          SEQUENCE OF Extension
+    }
+
+
+    id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
+    id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
+
+    EncryptedPOP ::= SEQUENCE {
+                request       TaggedRequest,
+        cms             ContentInfo,
+        thePOPAlgID     AlgorithmIdentifier,
+        witnessAlgID    AlgorithmIdentifier,
+        witness         OCTET STRING
+    }
+
+    DecryptedPOP ::= SEQUENCE {
+        bodyPartID      BodyPartID,
+        thePOPAlgID     AlgorithmIdentifier,
+        thePOP          OCTET STRING
+    }
+
+    id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
+
+    LraPopWitness ::= SEQUENCE {
+        pkiDataBodyid   BodyPartID,
+        bodyIds         SEQUENCE OF BodyPartID
+    }
+
+
+    --
+    id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
+
+    GetCert ::= SEQUENCE {
+        issuerName      GeneralName,
+        serialNumber    INTEGER }
+
+
+    id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
+
+    GetCRL ::= SEQUENCE {
+
+
+
+Myers, et al.               Standards Track                    [Page 45]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+        issuerName    Name,
+        cRLName       GeneralName OPTIONAL,
+        time          GeneralizedTime OPTIONAL,
+        reasons       ReasonFlags OPTIONAL }
+
+    id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
+
+    RevRequest ::= SEQUENCE {
+        issuerName            Name,
+        serialNumber          INTEGER,
+        reason                CRLReason,
+       invalidityDate         GeneralizedTime OPTIONAL,
+        passphrase            OCTET STRING OPTIONAL,
+        comment               UTF8String OPTIONAL }
+
+   id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
+
+   CMCCertId ::= IssuerSerial
+
+   -- The following is used to request V3 extensions be added to a
+certificate
+
+   id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
+        rsadsi(113549) pkcs(1) pkcs-9(9) 14}
+
+   ExtensionReq ::= SEQUENCE OF Extension
+
+   -- The following exists to allow Diffie-Hellman Certificate Requests
+Messages to be
+   -- well-formed
+
+   id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
+
+   NoSignatureValue ::= OCTET STRING
+
+END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 46]
+
+RFC 2797        Certificate Management Messages over CMS      April 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers, et al.               Standards Track                    [Page 47]
+