rfc2797.txt

PKIX的RFC英文文档

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