Internet Draft                            M. Myers (TraceRoute Security)PKIX Working Group                                    C. Adams (Entrust)November 2002                                         D. Solo (Citicorp)expires in six months                                      D. Kemp (DoD)               Internet X.509 Public Key Infrastructure               Certificate Request Message Format (CRMF)                  <draft-ietf-pkix-rfc2511bis-05.txt>Status of this Memo   This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC 2026.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF), its areas, and its working groups. Note that other   groups may also distribute working documents as Internet-Drafts.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time. It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   The list of current Internet-Drafts can be accessed at   http://www.ietf.org/ietf/1id-abstracts.txt   The list of Internet-Draft Shadow Directories can be accessed at   http://www.ietf.org/shadow.html.   Copyright (C) The Internet Society (2002). 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.             Expires May 2003                     [Page 1]Internet Draft                                                  May 2001   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.             Expires May 2003                     [Page 2]Internet Draft                                                  May 20014. 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.             Expires May 2003                     [Page 3]Internet Draft                                                  May 20014.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.             Expires May 2003                     [Page 4]Internet Draft                                                  May 2001       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 both the        -- public key and subject values (i.e., if it contains only one        -- of these, or neither), then poposkInput MUST be present and       -- MUST be signed.     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.             Expires May 2003                     [Page 5]Internet Draft                                                  May 2001       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.             Expires May 2003                     [Page 6]Internet Draft                                                  May 2001   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.   CertRequest ::= SEQUENCE {      certReqId     INTEGER,        -- ID for matching request and reply