rfc2797.txt

PKIX的RFC英文文档

   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 knowled