diff options
Diffstat (limited to 'doc/rfc/rfc2511.txt')
| -rw-r--r-- | doc/rfc/rfc2511.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2511.txt b/doc/rfc/rfc2511.txt new file mode 100644 index 0000000..9e7288b --- /dev/null +++ b/doc/rfc/rfc2511.txt @@ -0,0 +1,1403 @@ + + + + + + +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. + +CertRequest ::= SEQUENCE { + certReqId INTEGER, -- ID for matching request and reply + certTemplate CertTemplate, -- Selected fields of cert to be issued + controls Controls OPTIONAL } -- Attributes affecting issuance + +CertTemplate ::= SEQUENCE { + version [0] Version OPTIONAL, + serialNumber [1] INTEGER OPTIONAL, + signingAlg [2] AlgorithmIdentifier OPTIONAL, + issuer [3] Name OPTIONAL, + validity [4] OptionalValidity OPTIONAL, + subject [5] Name OPTIONAL, + publicKey [6] SubjectPublicKeyInfo OPTIONAL, + issuerUID [7] UniqueIdentifier OPTIONAL, + subjectUID [8] UniqueIdentifier OPTIONAL, + extensions [9] Extensions OPTIONAL } + + OptionalValidity ::= SEQUENCE { + notBefore [0] Time OPTIONAL, + notAfter [1] Time OPTIONAL } --at least one must be present + + Time ::= CHOICE { + utcTime UTCTime, + generalTime GeneralizedTime } + +6. Controls Syntax + + The generator of a CertRequest may include one or more control values + pertaining to the processing of the request. + + Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue + + The following controls are defined (it is recognized that this list + may expand over time): regToken; authenticator; pkiPublicationInfo; + pkiArchiveOptions; oldCertID; protocolEncrKey. + + + + + + + +Myers, et. al. Standards Track [Page 7] + +RFC 2511 Internet X.509 CRMF March 1999 + + +6.1 Registration Token Control + + A regToken control contains one-time information (either based on a + secret value or on knowledge) intended to be used by the CA to verify + the identity of the subject prior to issuing a certificate. Upon + receipt of a certification request containing a value for regToken, + the receiving CA verifies the information in order to confirm the + identity claimed in the certification request. + + The value for regToken may be generated by the CA and provided out of + band to the subscriber, or may otherwise be available to both the CA + and the subscriber. The security of any out-of-band exchange should + be commensurate with the risk of the CA accepting an intercepted + value from someone other than the intended subscriber. + + The regToken control would typically be used only for initialization + of an end entity into the PKI, whereas the authenticator control (see + Section 7.2) would typically be used for initial as well as + subsequent certification requests. + + In some instances of use the value for regToken could be a text + string or a numeric quantity such as a random number. The value in + the latter case could be encoded either as a binary quantity or as a + text string representation of the binary quantity. To ensure a + uniform encoding of values regardless of the nature of the quantity, + the encoding of regToken SHALL be UTF8. + +6.2 Authenticator Control. + + An authenticator control contains information used in an ongoing + basis to establish a non-cryptographic check of identity in + communication with the CA. Examples include: mother's maiden name, + last four digits of social security number, or other knowledge-based + information shared with the subscriber's CA; a hash of such + information; or other information produced for this purpose. The + value for an authenticator control may be generated by the subscriber + or by the CA. + + In some instances of use the value for regToken could be a text + string or a numeric quantity such as a random number. The value in + the latter case could be encoded either as a binary quantity or as a + text string representation of the binary quantity. To ensure a + uniform encoding of values regardless of the nature of the quantity, + the encoding of authenticator SHALL be UTF8. + + + + + + + +Myers, et. al. Standards Track [Page 8] + +RFC 2511 Internet X.509 CRMF March 1999 + + +6.3 Publication Information Control + + The pkiPublicationInfo control enables subscribers to control the + CA's publication of the certificate. It is defined by the following + syntax: + + PKIPublicationInfo ::= SEQUENCE { + action INTEGER { + dontPublish (0), + pleasePublish (1) }, + pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } + + + -- pubInfos MUST NOT be present if action is "dontPublish" + -- (if action is "pleasePublish" and pubInfos is omitted, + -- "dontCare" is assumed) + + SinglePubInfo ::= SEQUENCE { + pubMethod INTEGER { + dontCare (0), + x500 (1), + web (2), + ldap (3) }, + pubLocation GeneralName OPTIONAL } + + If the dontPublish option is chosen, the requester indicates that the + PKI should not publish the certificate (this may indicate that the + requester intends to publish the certificate him/herself). + + If the dontCare method is chosen, or if the PKIPublicationInfo + control is omitted from the request, the requester indicates that the + PKI MAY publish the certificate using whatever means it chooses. + + If the requester wishes the certificate to appear in at least some + locations but wishes to enable the CA to make the certificate + available in other repositories, set two values of SinglePubInfo for + pubInfos: one with x500, web or ldap value and one with dontCare. + + The pubLocation field, if supplied, indicates where the requester + would like the certificate to be found (note that the CHOICE within + GeneralName includes a URL and an IP address, for example). + +6.4 Archive Options Control + + The pkiArchiveOptions control enables subscribers to supply + information needed to establish an archive of the private key + corresponding to the public key of the certification request. It is + defined by the following syntax: + + + +Myers, et. al. Standards Track [Page 9] + +RFC 2511 Internet X.509 CRMF March 1999 + + +PKIArchiveOptions ::= CHOICE { + encryptedPrivKey [0] EncryptedKey, + -- the actual value of the private key + keyGenParameters [1] KeyGenParameters, + -- parameters which allow the private key to be re-generated + archiveRemGenPrivKey [2] BOOLEAN } + -- set to TRUE if sender wishes receiver to archive the private + -- key of a key pair which the receiver generates in response to + -- this request; set to FALSE if no archival is desired. + +EncryptedKey ::= CHOICE { + encryptedValue EncryptedValue, + envelopedData [0] EnvelopedData } + -- The encrypted private key MUST be placed in the envelopedData + -- encryptedContentInfo encryptedContent OCTET STRING. + +EncryptedValue ::= SEQUENCE { + intendedAlg [0] AlgorithmIdentifier OPTIONAL, + -- the intended algorithm for which the value will be used + symmAlg [1] AlgorithmIdentifier OPTIONAL, + -- the symmetric algorithm used to encrypt the value + encSymmKey [2] BIT STRING OPTIONAL, + -- the (encrypted) symmetric key used to encrypt the value + keyAlg [3] AlgorithmIdentifier OPTIONAL, + -- algorithm used to encrypt the symmetric key + valueHint [4] OCTET STRING OPTIONAL, + -- a brief description or identifier of the encValue content + -- (may be meaningful only to the sending entity, and used only + -- if EncryptedValue might be re-examined by the sending entity + -- in the future) + encValue BIT STRING } + +KeyGenParameters ::= OCTET STRING + + An alternative to sending the key is to send the information about + how to re-generate the key using the KeyGenParameters choice (e.g., + for many RSA implementations one could send the first random numbers + tested for primality). The actual syntax for this parameter may be + defined in a subsequent version of this document or in another + standard. + + + + + + + + + + + +Myers, et. al. Standards Track [Page 10] + +RFC 2511 Internet X.509 CRMF March 1999 + + +6.5 OldCert ID Control + + If present, the OldCertID control specifies the certificate to be + updated by the current certification request. The syntax of its + value is: + + CertId ::= SEQUENCE { + issuer GeneralName, + serialNumber INTEGER + } + +6.6 Protocol Encryption Key Control + + If present, the protocolEncrKey control specifies a key the CA is to + use in encrypting a response to CertReqMessages. + + This control can be used when a CA has information to send to the + subscriber that needs to be encrypted. Such information includes a + private key generated by the CA for use by the subscriber. + + The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo. + +7. Object Identifiers + + The OID id-pkix has the value + + id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) } + + -- arc for Internet X.509 PKI protocols and their components + id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) } + + -- Registration Controls in CRMF + id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } + id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 } + id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 } + id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } + id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } + id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } + id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } + + -- Registration Info in CRMF + id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) } + id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 } + --with syntax OCTET STRING + id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } + --with syntax CertRequest + + + + +Myers, et. al. Standards Track [Page 11] + +RFC 2511 Internet X.509 CRMF March 1999 + + +8. Security Considerations + + The security of CRMF delivery is reliant upon the security mechanisms + of the protocol or process used to communicate with CAs. Such + protocol or process needs to ensure the integrity, data origin + authenticity, and privacy of the message. Encryption of a CRMF is + strongly recommended if it contains subscriber-sensitive information + and if the CA has an encryption certificate that is known to the end + entity. + +9. References + + [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February 1997. + +10. Acknowledgments + + The authors gratefully acknowledge the contributions of Barbara Fox, + Warwick Ford, Russ Housley and John Pawling, whose review and + comments significantly clarified and improved the utility of this + specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers, et. al. Standards Track [Page 12] + +RFC 2511 Internet X.509 CRMF March 1999 + + +11. Authors' Addresses + + Michael Myers + VeriSign, Inc. + 1390 Shorebird Way + Mountain View, CA 94019 + + EMail: mmyers@verisign.com + + + Carlisle Adams + Entrust Technologies + 750 Heron Road, Suite E08 + Ottawa, Canada, K1V 1A7 + + EMail: cadams@entrust.com + + + Dave Solo + Citicorp + 666 Fifth Ave, 3rd Floor + New York, Ny 10103 + + EMail: david.solo@citicorp.com + + + David Kemp + National Security Agency + Suite 6734 + 9800 Savage Road + Fort Meade, MD 20755 + + EMail: dpkemp@missi.ncsc.mil + + + + + + + + + + + + + + + + + + +Myers, et. al. Standards Track [Page 13] + +RFC 2511 Internet X.509 CRMF March 1999 + + +Appendix A. Constructing "dhMAC" + + This Appendix describes the method for computing the bit string + "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie- + Hellman certificate requests. + + 1. The entity generates a DH public/private key-pair. + + The DH parameters used to calculate the public SHOULD be those + specified in the CA's DH certificate. + + From CA's DH certificate: + CApub = g^x mod p (where g and p are the established DH + parameters and x is the CA's private + DH component) + For entity E: + DH private value = y + Epub = DH public value = g^y mod p + + 2. The MACing process will then consist of the following steps. + + a) The value of the certReq field is DER encoded, yielding a binary + string. This will be the 'text' referred to in [HMAC], the data to + which HMAC-SHA1 is applied. + + b) A shared DH secret is computed, as follows, + shared secret = Kec = g^xy mod p + + [This is done by the entity E as CApub^y and by the CA as Epub^x, + where CApub is retrieved from the CA's DH certificate and Epub is + retrieved from the actual certification request.] + + c) A key K is derived from the shared secret Kec and the subject and + issuer names in the CA's certificate as follows: + + K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName) + + where "|" means concatenation. If subjectName in the CA + certificate is an empty SEQUENCE then DER-encoded-subjectAltName + should be used instead; similarly, if issuerName is an empty + SEQUENCE then DER-encoded-issuerAltName should be used instead. + + d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as: + SHA1(K XOR opad, SHA1(K XOR ipad, text)) + + + + + + + +Myers, et. al. Standards Track [Page 14] + +RFC 2511 Internet X.509 CRMF March 1999 + + + where, + opad (outer pad) = the byte 0x36 repeated 64 times + and + ipad (inner pad) = the byte 0x5C repeated 64 times. + + + Namely, + + (1) Append zeros to the end of K to create a 64 byte string + (e.g., if K is of length 16 bytes it will be appended with + 48 zero bytes 0x00). + (2) XOR (bitwise exclusive-OR) the 64 byte string computed in + step (1) with ipad. + (3) Append the data stream 'text' to the 64 byte string + resulting from step (2). + (4) Apply SHA1 to the stream generated in step (3). + (5) XOR (bitwise exclusive-OR) the 64 byte string computed in + step (1) with opad. + (6) Append the SHA1 result from step (4) to the 64 byte string + resulting from step (5). + (7) Apply SHA1 to the stream generated in step (6) and output + the result. + + Sample code is also provided in [RFC2104, RFC2202]. + + e) The output of (d) is encoded as a BIT STRING (the value "dhMAC"). + + 3. The proof-of-possession process requires the CA to carry out + steps (a) through (d) and then simply compare the result of step + (d) with what it received as the "dhMAC" value. If they match then + the following can be concluded. + + 1) The Entity possesses the private key corresponding to the + public key in the certification request (because it needed the + private key to calculate the shared secret). + + 2) Only the intended CA can actually verify the request (because + the CA requires its own private key to compute the same shared + secret). This helps to protect from rogue CAs. + +References + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- + SHA-1", RFC 2202, September 1997. + + + +Myers, et. al. Standards Track [Page 15] + +RFC 2511 Internet X.509 CRMF March 1999 + + +Acknowledgements + + The details of this Appendix were provided by Hemma Prafullchandra. + + Appendix B. Use of RegInfo for Name-Value Pairs + + The "value" field of the id-regInfo-utf8Pairs OCTET STRING (with + "tag" field equal to 12 and appropriate "length" field) will contain + a series of UTF8 name/value pairs. + + This Appendix lists some common examples of such pairs for the + purpose of promoting interoperability among independent + implementations of this specification. It is recognized that this + list is not exhaustive and will grow with time and implementation + experience. + +B.1. Example Name/Value Pairs + + When regInfo is used to convey one or more name-value pairs (via id- + regInfo-utf8Pairs), the first and subsequent pairs SHALL be + structured as follows: + + [name?value][%name?value]*% + + This string is then encoded into an OCTET STRING and placed into the + regInfo SEQUENCE. + + Reserved characters are encoded using the %xx mechanism of [RFC1738], + unless they are used for their reserved purposes. + + The following table defines a recommended set of named elements. + The value in the column "Name Value" is the exact text string that + will appear in the regInfo. + + Name Value + ---------- + version -- version of this variation of regInfo use + corp_company -- company affiliation of subscriber + org_unit -- organizational unit + mail_firstName -- personal name component + mail_middleName -- personal name component + mail_lastName -- personal name component + mail_email -- subscriber's email address + jobTitle -- job title of subscriber + employeeID -- employee identification number or string + + mailStop -- mail stop + issuerName -- name of CA + + + +Myers, et. al. Standards Track [Page 16] + +RFC 2511 Internet X.509 CRMF March 1999 + + + subjectName -- name of Subject + validity -- validity interval + + For example: + + version?1%corp_company?Acme, Inc.%org_unit?Engineering% + mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% + mail_email?john@acme.com% + +B.1.1. IssuerName, SubjectName and Validity Value Encoding + + When they appear in id-regInfo-utf8Pairs syntax as named elements, + the encoding of values for issuerName, subjectName and validity SHALL + use the following syntax. The characters [] indicate an optional + field, ::= and | have their usual BNF meanings, and all other symbols + (except spaces which are insignificant) outside non-terminal names + are terminals. Alphabetics are case-sensitive. + + issuerName ::= <names> + subjectName ::= <names> + <names> ::= <name> | <names>:<name> + + <validity> ::= validity ? [<notbefore>]-[<notafter>] + <notbefore> ::= <time> + <notafter> ::= <time> + + Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM, + and SS default to 00 and are omitted if at the and of value 00. + + Example validity encoding: + + validity?-19991231% + + is a validity interval with no value for notBefore and a value of + December 31, 1999 for notAfter. + + Each name comprises a single character name form identifier followed + by a name value of one or UTF8 characters. Within a name value, when + it is necessary to disambiguate a character which has formatting + significance at an outer level, the escape sequence %xx SHALL be + used, where xx represents the hex value for the encoding concerned. + The percent symbol is represented by %%. + + <name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname> + + Name forms and value formats are as follows: + + X.500 directory name form (identifier "X"): + + + +Myers, et. al. Standards Track [Page 17] + +RFC 2511 Internet X.509 CRMF March 1999 + + + <xname> ::= <rdns> + <rdns> ::= <rdn> | <rdns> , <rdn> + <rdn> ::= <avas> + <avas> ::= <ava> | <avas> + <ava> + <ava> ::= <attyp> = <avalue> + <attyp> ::= OID.<oid> | <stdat> + + Standard attribute type <stdat> is an alphabetic attribute type + identifier from the following set: + + C (country) + L (locality) + ST (state or province) + O (organization) + OU (organizational unit) + CN (common name) + STREET (street address) + E (E-mail address). + + <avalue> is a name component in the form of a UTF8 character string + of 1 to 64 characters, with the restriction that in the IA5 subset of + UTF8 only the characters of ASN.1 PrintableString may be used. + + Other name form (identifier "O"): + <oname> ::= <oid> , <utf8string> + + E-mail address (rfc822name) name form (identifier "E"): + <ename> ::= <ia5string> + + DNS name form (identifier "D"): + <dname> ::= <ia5string> + + URI name form (identifier "U"): + <uname> ::= <ia5string> + + IP address (identifier "I"): + <iname> ::= <oid> + + For example: + + issuerName?XOU=Our CA,O=Acme,C=US% + subjectName?XCN=John Smith, O=Acme, C=US, E=john@acme.com% + +References + + [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, + "Uniform Resource Locators (URL)", RFC 1738, December 1994. + + + + +Myers, et. al. Standards Track [Page 18] + +RFC 2511 Internet X.509 CRMF March 1999 + + +Appendix C. ASN.1 Structures and OIDs + +PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)} + +CRMF DEFINITIONS IMPLICIT TAGS ::= +BEGIN + +IMPORTS + -- Directory Authentication Framework (X.509) + Version, AlgorithmIdentifier, Name, Time, + SubjectPublicKeyInfo, Extensions, UniqueIdentifier + FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-explicit-88(1)} + + -- Certificate Extensions (X.509) + GeneralName + FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-implicit-88(2)} + + -- Cryptographic Message Syntax + EnvelopedData + FROM CryptographicMessageSyntax { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) + modules(0) cms(1) }; + +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 } + +CertRequest ::= SEQUENCE { + certReqId INTEGER, -- ID for matching request and reply + certTemplate CertTemplate, -- Selected fields of cert to be issued + controls Controls OPTIONAL } -- Attributes affecting issuance + +CertTemplate ::= SEQUENCE { + version [0] Version OPTIONAL, + serialNumber [1] INTEGER OPTIONAL, + signingAlg [2] AlgorithmIdentifier OPTIONAL, + issuer [3] Name OPTIONAL, + validity [4] OptionalValidity OPTIONAL, + subject [5] Name OPTIONAL, + + + +Myers, et. al. Standards Track [Page 19] + +RFC 2511 Internet X.509 CRMF March 1999 + + + publicKey [6] SubjectPublicKeyInfo OPTIONAL, + issuerUID [7] UniqueIdentifier OPTIONAL, + subjectUID [8] UniqueIdentifier OPTIONAL, + extensions [9] Extensions OPTIONAL } + +OptionalValidity ::= SEQUENCE { + notBefore [0] Time OPTIONAL, + notAfter [1] Time OPTIONAL } --at least one MUST be present + +Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue + +AttributeTypeAndValue ::= SEQUENCE { + type OBJECT IDENTIFIER, + value ANY DEFINED BY type } + +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, + 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 + + + +Myers, et. al. Standards Track [Page 20] + +RFC 2511 Internet X.509 CRMF March 1999 + + + publicKey SubjectPublicKeyInfo } -- from CertTemplate + +PKMACValue ::= SEQUENCE { + algId AlgorithmIdentifier, + -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13} + -- parameter value is PBMParameter + value BIT STRING } + +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]) + +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 { + 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 engage in challenge-response exchange with + -- end entity in order to prove private key possession + +-- Object identifier assignments -- + +id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) +dod(6) internet(1) security(5) mechanisms(5) 7 } + +-- arc for Internet X.509 PKI protocols and their components + + + +Myers, et. al. Standards Track [Page 21] + +RFC 2511 Internet X.509 CRMF March 1999 + + +id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 } + +-- Registration Controls in CRMF +id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 } + +-- The following definition may be uncommented for use with +-- ASN.1 compilers which do not understand UTF8String. + +-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING + +id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 } +--with syntax: +RegToken ::= UTF8String + +id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 } +--with syntax: +Authenticator ::= UTF8String + +id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } +--with syntax: + +PKIPublicationInfo ::= SEQUENCE { + action INTEGER { + dontPublish (0), + pleasePublish (1) }, + pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } + -- pubInfos MUST NOT be present if action is "dontPublish" + -- (if action is "pleasePublish" and pubInfos is omitted, + -- "dontCare" is assumed) + +SinglePubInfo ::= SEQUENCE { + pubMethod INTEGER { + dontCare (0), + x500 (1), + web (2), + ldap (3) }, + pubLocation GeneralName OPTIONAL } + +id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } +--with syntax: +PKIArchiveOptions ::= CHOICE { + encryptedPrivKey [0] EncryptedKey, + -- the actual value of the private key + keyGenParameters [1] KeyGenParameters, + -- parameters which allow the private key to be re-generated + archiveRemGenPrivKey [2] BOOLEAN } + -- set to TRUE if sender wishes receiver to archive the private + -- key of a key pair which the receiver generates in response to + + + +Myers, et. al. Standards Track [Page 22] + +RFC 2511 Internet X.509 CRMF March 1999 + + + -- this request; set to FALSE if no archival is desired. + +EncryptedKey ::= CHOICE { + encryptedValue EncryptedValue, + envelopedData [0] EnvelopedData } + -- The encrypted private key MUST be placed in the envelopedData + -- encryptedContentInfo encryptedContent OCTET STRING. + + +EncryptedValue ::= SEQUENCE { + intendedAlg [0] AlgorithmIdentifier OPTIONAL, + -- the intended algorithm for which the value will be used + symmAlg [1] AlgorithmIdentifier OPTIONAL, + -- the symmetric algorithm used to encrypt the value + encSymmKey [2] BIT STRING OPTIONAL, + -- the (encrypted) symmetric key used to encrypt the value + keyAlg [3] AlgorithmIdentifier OPTIONAL, + -- algorithm used to encrypt the symmetric key + valueHint [4] OCTET STRING OPTIONAL, + -- a brief description or identifier of the encValue content + -- (may be meaningful only to the sending entity, and used only + -- if EncryptedValue might be re-examined by the sending entity + -- in the future) + encValue BIT STRING } + -- the encrypted value itself + +KeyGenParameters ::= OCTET STRING + +id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } +--with syntax: +OldCertId ::= CertId + +CertId ::= SEQUENCE { + issuer GeneralName, + serialNumber INTEGER } + +id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } +--with syntax: +ProtocolEncrKey ::= SubjectPublicKeyInfo + +-- Registration Info in CRMF +id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 } + +id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 } +--with syntax +UTF8Pairs ::= UTF8String + +id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } + + + +Myers, et. al. Standards Track [Page 23] + +RFC 2511 Internet X.509 CRMF March 1999 + + +--with syntax +CertReq ::= CertRequest + +END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers, et. al. Standards Track [Page 24] + +RFC 2511 Internet X.509 CRMF March 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Myers, et. al. Standards Track [Page 25] + |