Network Working Group                                           M. MyersRequest for Comments: 2511                                      VeriSignCategory: Standards Track                                       C. Adams                                                    Entrust Technologies                                                                 D. Solo                                                                Citicorp                                                                 D. Kemp                                                                     DoD                                                              March 1999           Internet X.509 Certificate Request Message FormatStatus 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 CertReqMsgCertReqMsg ::= 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 19994. 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 19994.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.