rfc2797.txt

PKIX的RFC英文文档

   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