rfc2797.txt

PKIX的RFC英文文档


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