rfc2511.txt

PKIX的RFC英文文档

Network Working Group                                           M. Myers
Request for Comments: 2511                                      VeriSign
Category: Standards Track                                       C. Adams
                                                    Entrust Technologies
                                                                 D. Solo
                                                                Citicorp
                                                                 D. Kemp
                                                                     DoD
                                                              March 1999


           Internet X.509 Certificate Request Message Format

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 (1999).  All Rights Reserved.

1.  Abstract

   This document describes the Certificate Request Message Format
   (CRMF).  This syntax is used to convey a request for a certificate to
   a Certification Authority (CA) (possibly via a Registration Authority
   (RA)) for the purposes of X.509 certificate production.  The request
   will typically include a public key and associated registration
   information.

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document (in uppercase, as shown) are to be interpreted as
   described in RFC 2119.

2.  Overview

   Construction of a certification request involves the following steps:

   a)  A CertRequest value is constructed.  This value may include the
       public key, all or a portion of the end-entity's (EE's) name,
       other requested certificate fields, and additional control
       information related to the registration process.





Myers, et. al.              Standards Track                     [Page 1]

RFC 2511                  Internet X.509 CRMF                 March 1999


   b)  A proof of possession (of the private key corresponding to the
       public key for which a certificate is being requested) value may
       be calculated across the CertRequest value.

   c)  Additional registration information may be combined with the
       proof of possession value and the CertRequest structure to form a
       CertReqMessage.

   d)  The CertReqMessage is securely communicated to a CA. Specific
       means of secure transport are beyond the scope of this
       specification.

3. CertReqMessage Syntax

   A certificate request message is composed of the certificate request,
   an optional proof of possession field and an optional registration
   information field.

CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg

CertReqMsg ::= SEQUENCE {
    certReq   CertRequest,
    pop       ProofOfPossession  OPTIONAL,
    -- content depends upon key type
    regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }

   The proof of possession field is used to demonstrate that the entity
   to be associated with the certificate is actually in possession of
   the corresponding private key.  This field may be calculated across
   the contents of the certReq field and varies in structure and content
   by public key algorithm type and operational mode.

   The regInfo field SHOULD only contain supplementary information
   related to the context of the certification request when such
   information is required to fulfill a certification request.  This
   information MAY include subscriber contact information, billing
   information or other ancillary information useful to fulfillment of
   the certification request.

   Information directly related to certificate content SHOULD be
   included in the certReq content.  However, inclusion of additional
   certReq content by RAs may invalidate the pop field.  Data therefore
   intended for certificate content MAY be provided in regInfo.

   See Section 8 and Appendix B for example regInfo contents.






Myers, et. al.              Standards Track                     [Page 2]

RFC 2511                  Internet X.509 CRMF                 March 1999


4. Proof of Possession (POP)

   In order to prevent certain attacks and to allow a CA/RA to properly
   check the validity of the binding between an end entity and a key
   pair, the PKI management operations specified here make it possible
   for an end entity to prove that it has possession of (i.e., is able
   to use) the private key corresponding to the public key for which a
   certificate is requested.  A given CA/RA is free to choose how to
   enforce POP (e.g., out-of-band procedural means versus the CRMF in-
   band message) in its certification exchanges (i.e., this may be a
   policy issue).  However, it is MANDATED that CAs/RAs MUST enforce POP
   by some means because there are currently many non-PKIX operational
   protocols in use (various electronic mail protocols are one example)
   that do not explicitly check the binding between the end entity and
   the private key.  Until operational protocols that do verify the
   binding (for signature, encryption, and key agreement key pairs)
   exist, and are ubiquitous, this binding can only be assumed to have
   been verified by the CA/RA. Therefore, if the binding is not verified
   by the CA/RA, certificates in the Internet Public-Key Infrastructure
   end up being somewhat less meaningful.

   POP is accomplished in different ways depending on the type of key
   for which a certificate is requested. If a key can be used for
   multiple purposes (e.g., an RSA key) then any of the methods MAY be
   used.

   This specification allows for cases where POP is validated by the CA,
   the RA, or both.  Some policies may require the CA to verify POP
   during certification, in which case the RA MUST forward the end
   entity's CertRequest and ProofOfPossession fields unaltered to the
   CA, and as an option MAY also verify POP.  If the CA is not required
   by policy to verify POP, then the RA SHOULD forward the end entity's
   request and proof unaltered to the CA as above.  If this is not
   possible (for example because the RA verifies POP by an out-of-band
   method), then the RA MAY attest to the CA that the required proof has
   been validated. If the CA uses an out-of-band method to verify POP
   (such as physical delivery of CA-generated private keys), then the
   ProofOfPossession field is not used.

4.1 Signature Keys

   For signature keys, the end entity can sign a value to prove
   possession of the private key.








Myers, et. al.              Standards Track                     [Page 3]

RFC 2511                  Internet X.509 CRMF                 March 1999


4.2 Key Encipherment Keys

   For key encipherment keys, the end entity can provide the private key
   to the CA/RA, or can be required to decrypt a value in order to prove
   possession of the private key. Decrypting a value can be achieved
   either directly or indirectly.

   The direct method is for the RA/CA to issue a random challenge to
   which an immediate response by the end entity is required.

   The indirect method is to issue a certificate which is encrypted for
   the end entity (and have the end entity demonstrate its ability to
   decrypt this certificate in a confirmation message). This allows a CA
   to issue a certificate in a form which can only be used by the
   intended end entity.

4.3 Key Agreement Keys

   For key agreement keys, the end entity can use any of the three
   methods given in Section 5.2 for encryption keys.  For the direct and
   indirect methods, the end entity and the PKI management entity (i.e.,
   CA or RA) must establish a shared secret key in order to prove that
   the end entity has possession of the private key (i.e., in order to
   decrypt the encrypted certificate or to construct the response to the
   issued challenge).  Note that this need not impose any restrictions
   on the keys that can be certified by a given CA -- in particular, for
   Diffie-Hellman keys the end entity may freely choose its algorithm
   parameters -- provided that the CA can generate a short-term (or
   one-time) key pair with the appropriate parameters when necessary.

   The end entity may also MAC the certificate request (using a shared
   secret key derived from a Diffie-Hellman computation) as a fourth
   alternative for demonstrating POP.  This option may be used only if
   the CA already has a DH certificate that is known to the end entity
   and if the EE is willing to use the CA's DH parameters.

4.4 Proof of Possession Syntax

   ProofOfPossession ::= CHOICE {
       raVerified        [0] NULL,
       -- used if the RA has already verified that the requester is in
       -- possession of the private key
       signature         [1] POPOSigningKey,
       keyEncipherment   [2] POPOPrivKey,
       keyAgreement      [3] POPOPrivKey }

   POPOSigningKey ::= SEQUENCE {
       poposkInput         [0] POPOSigningKeyInput OPTIONAL,



Myers, et. al.              Standards Track                     [Page 4]

RFC 2511                  Internet X.509 CRMF                 March 1999


       algorithmIdentifier     AlgorithmIdentifier,
       signature               BIT STRING }
       -- The signature (using "algorithmIdentifier") is on the
       -- DER-encoded value of poposkInput.  NOTE: If the CertReqMsg
       -- certReq CertTemplate contains the subject and publicKey values,
       -- then poposkInput MUST be omitted and the signature MUST be
       -- computed on the DER-encoded value of CertReqMsg certReq.  If
       -- the CertReqMsg certReq CertTemplate does not contain the public
       -- key and subject values, then poposkInput MUST be present and
       -- MUST be signed.  This strategy ensures that the public key is
       -- not present in both the poposkInput and CertReqMsg certReq
       -- CertTemplate fields.

   POPOSigningKeyInput ::= SEQUENCE {
       authInfo            CHOICE {
           sender              [0] GeneralName,
           -- used only if an authenticated identity has been
           -- established for the sender (e.g., a DN from a
           -- previously-issued and currently-valid certificate)
           publicKeyMAC        PKMACValue },
           -- used if no authenticated GeneralName currently exists for
           -- the sender; publicKeyMAC contains a password-based MAC
           -- on the DER-encoded value of publicKey
       publicKey           SubjectPublicKeyInfo }  -- from CertTemplate

   PKMACValue ::= SEQUENCE {
      algId  AlgorithmIdentifier,
      -- the algorithm value shall be PasswordBasedMac
      --     {1 2 840 113533 7 66 13}
      -- the parameter value is PBMParameter
      value  BIT STRING }

   POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,
       -- posession is proven in this message (which contains the private
       -- key itself (encrypted for the CA))
       subsequentMessage [1] SubsequentMessage,
       -- possession will be proven in a subsequent message
       dhMAC             [2] BIT STRING }
       -- for keyAgreement (only), possession is proven in this message
       -- (which contains a MAC (over the DER-encoded value of the
       -- certReq parameter in CertReqMsg, which must include both subject
       -- and publicKey) based on a key derived from the end entity's
       -- private DH key and the CA's public DH key);
       -- the dhMAC value MUST be calculated as per the directions given
       -- in Appendix A.

   SubsequentMessage ::= INTEGER {



Myers, et. al.              Standards Track                     [Page 5]

RFC 2511                  Internet X.509 CRMF                 March 1999


       encrCert (0),
       -- requests that resulting certificate be encrypted for the
       -- end entity (following which, POP will be proven in a
       -- confirmation message)
       challengeResp (1) }
       -- requests that CA/RA engage in challenge-response exchange with
       -- end entity in order to prove private key possession

   It is expected that protocols which incorporate this specification
   will include the confirmation and challenge-response messages
   necessary to a complete protocol.

4.4.1  Use of Password-Based MAC

   The following algorithm SHALL be used when publicKeyMAC is used in
   POPOSigningKeyInput to prove the authenticity of a request.

   PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         iterationCount      INTEGER,
         -- number of times the OWF is applied
         mac                 AlgorithmIdentifier
         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
   }   -- or HMAC [RFC2104, RFC2202])

   The process of using PBMParameter to compute publicKeyMAC and so
   authenticate the origin of a public key certification request
   consists of two stages. The first stage uses shared secret
   information to produce a MAC key. The second stage MACs the public
   key in question using this MAC key to produce an authenticated value.

   Initialization of the first stage of algorithm assumes the existence
   of a shared secret distributed in a trusted fashion between CA/RA and
   end-entity.  The salt value is appended to the shared secret and the
   one way function (owf) is applied iterationCount times, where the
   salted secret is the input to the first iteration and, for each
   successive iteration, the input is set to be the output of the
   previous iteration, yielding a key K.

   In the second stage, K and the public key are inputs to HMAC as
   documented in [HMAC] to produce a value for publicKeyMAC as follows:

   publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) )

   where ipad and opad are defined in [RFC2104].




Myers, et. al.              Standards Track                     [Page 6]

RFC 2511                  Internet X.509 CRMF                 March 1999


   The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and
   for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}.

5.  CertRequest syntax

   The CertRequest syntax consists of a request identifier, a template
   of certificate content, and an optional sequence of control
   information.