idnits 2.17.1 draft-ietf-pkix-crmf-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '...pop ProofOfPossession OPTIONAL,...' RFC 2119 keyword, line 78: '...X) of AttributeTypeAndValue OPTIONAL }...' RFC 2119 keyword, line 86: '...he regInfo field SHOULD only contain s...' RFC 2119 keyword, line 88: '...ication request. This information MAY...' RFC 2119 keyword, line 93: '...certificate content SHOULD be included...' (74 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == Line 276 has weird spacing: '...or each succe...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1998) is 9471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 984 -- Looks like a reference, but probably isn't: '1' on line 986 -- Looks like a reference, but probably isn't: '2' on line 988 -- Looks like a reference, but probably isn't: '3' on line 990 == Missing Reference: 'PKCS11' is mentioned on line 894, but not defined -- Looks like a reference, but probably isn't: '4' on line 992 -- Looks like a reference, but probably isn't: '5' on line 830 -- Looks like a reference, but probably isn't: '6' on line 831 -- Looks like a reference, but probably isn't: '7' on line 832 -- Looks like a reference, but probably isn't: '8' on line 833 -- Looks like a reference, but probably isn't: '9' on line 834 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 935, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Duplicate reference: RFC2104, mentioned in 'RFC2104', was also mentioned in 'HMAC'. ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 2202 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group Michael Myers (VeriSign) 2 Internet Draft Carlisle Adams (Entrust Technologies) 3 Dave Solo (Citicorp) 4 Dave Kemp (DoD) 6 Expires in six months May 1998 8 Internet X.509 Certificate Request Message Format 9 11 1. Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 2. Abstract 32 This document describes the Certificate Request Message Format (CRMF). 33 This syntax is used to convey a request for a certificate to a 34 Certification Authority (CA) (possibly via a Registration Authority 35 (RA)) for the purposes of X.509 certificate production. The request 36 will typically include a public key and associated registration 37 information. 39 The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'', 40 and ''MAY'' in this document (in uppercase, as shown) 41 are to be interpreted as described in RFC 2119. 43 Please send comments on this document to the ietf-pkix@lists.tandem.com 44 mail list. 46 3. Overview 48 Construction of a certification request involves the following steps: 50 a) A CertRequest value is constructed. This value may include the 51 public key, all or a portion of the end-entity's (EE's) name, other 52 requested certificate fields, and additional control information 53 related to the registration process. 55 b) A proof of possession (of the private key corresponding to the 56 public key for which a certificate is being requested) value may be 57 calculated across the CertRequest value. 59 c) Additional registration information may be combined with the proof 60 of possession value and the CertRequest structure to form a 61 CertReqMessage. 63 d) The CertReqMessage is securely communicated to a CA. Specific means 64 of secure transport are beyond the scope of this specification. 66 4. CertReqMessage Syntax 68 A certificate request message is composed of the certificate request, an 69 optional proof of possession field and an optional registration 70 information field. 72 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 74 CertReqMsg ::= SEQUENCE { 75 certReq CertRequest, 76 pop ProofOfPossession OPTIONAL, 77 -- content depends upon key type 78 regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL } 80 The proof of possession field is used to demonstrate that the entity to 81 be associated with the certificate is actually in possession of the 82 corresponding private key. This field may be calculated across the 83 contents of the certReq field and varies in structure and content by 84 public key algorithm type and operational mode. 86 The regInfo field SHOULD only contain supplementary information related 87 to the context of the certification request when such information is 88 required to fulfill a certification request. This information MAY 89 include subscriber contact information, billing information or other 90 ancillary information useful to fulfillment of the certification 91 request. 93 Information directly related to certificate content SHOULD be included 94 in the certReq content. However, inclusion of additional certReq 95 content by RAs may invalidate the pop field. Data therefore intended 96 for certificate content MAY be provided in regInfo. 98 See Section 8 and Appendix B for example regInfo contents. 100 5. Proof of Possession (POP) 102 In order to prevent certain attacks and to allow a CA/RA to properly 103 check the validity of the binding between an end entity and a key pair, 104 the PKI management operations specified here make it possible for an end 105 entity to prove that it has possession of (i.e., is able to use) the 106 private key corresponding to the public key for which a certificate is 107 requested. A given CA/RA is free to choose how to enforce POP (e.g., 108 out-of-band procedural means versus the CRMF in-band message) in its 109 certification exchanges (i.e., this may be a policy issue). However, 110 it is MANDATED that CAs/RAs MUST enforce POP by some means because there 111 are currently many non-PKIX operational protocols in use (various 112 electronic mail protocols are one example) that do not explicitly check 113 the binding between the end entity and the private key. Until 114 operational protocols that do verify the binding (for signature, 115 encryption, and key agreement key pairs) exist, and are ubiquitous, this 116 binding can only be assumed to have been verified by the CA/RA. 117 Therefore, if the binding is not verified by the CA/RA, certificates in 118 the Internet Public-Key Infrastructure end up being somewhat less 119 meaningful. 121 POP is accomplished in different ways depending on the type of key for 122 which a certificate is requested. If a key can be used for multiple 123 purposes (e.g., an RSA key) then any of the methods MAY be used. 125 This specification allows for cases where POP is validated by the CA, 126 the RA, or both. Some policies may require the CA to verify POP 127 during certification, in which case the RA MUST forward the end 128 entity's CertRequest and ProofOfPossession fields unaltered to the CA, 129 and as an option MAY also verify POP. If the CA is not required by 130 policy to verify POP, then the RA SHOULD forward the end entity's 131 request and proof unaltered to the CA as above. If this is not 132 possible (for example because the RA verifies POP by an out-of-band 133 method), then the RA MAY attest to the CA that the required proof has 134 been validated. If the CA uses an out-of-band method to verify POP 135 (such as physical delivery of CA-generated private keys), then the 136 ProofOfPossession field is not used. 138 5.1 Signature Keys 140 For signature keys, the end entity can sign a value to prove possession 141 of the private key. 143 5.2 Key Encipherment Keys 145 For key encipherment keys, the end entity can provide the private key to 146 the CA/RA, or can be required to decrypt a value in order to prove 147 possession of the private key. Decrypting a value can be achieved either 148 directly or indirectly. 150 The direct method is for the RA/CA to issue a random challenge to which 151 an immediate response by the end entity is required. 153 The indirect method is to issue a certificate which is encrypted for the 154 end entity (and have the end entity demonstrate its ability to decrypt 155 this certificate in a confirmation message). This allows a CA to issue 156 a certificate in a form which can only be used by the intended end 157 entity. 159 5.3 Key Agreement Keys 161 For key agreement keys, the end entity can use any of the three methods 162 given in Section 5.2 for encryption keys. For the direct and indirect 163 methods, the end entity and the PKI management entity (i.e., CA or RA) 164 must establish a shared secret key in order to prove that the end 165 entity has possession of the private key (i.e., in order to decrypt the 166 encrypted certificate or to construct the response to the issued 167 challenge). Note that this need not impose any restrictions on the 168 keys that can be certified by a given CA -- in particular, for 169 Diffie-Hellman keys the end entity may freely choose its algorithm 170 parameters -- provided that the CA can generate a short-term (or 171 one-time) key pair with the appropriate parameters when necessary. 173 The end entity may also MAC the certificate request (using a shared 174 secret key derived from a Diffie-Hellman computation) as a fourth 175 alternative for demonstrating POP. This option may be used only if 176 the CA already has a DH certificate that is known to the end entity 177 and if the EE is willing to use the CA's DH parameters. 179 5.4 Proof of Possession Syntax 181 ProofOfPossession ::= CHOICE { 182 raVerified [0] NULL, 183 -- used if the RA has already verified that the requester is in 184 -- possession of the private key 185 signature [1] POPOSigningKey, 186 keyEncipherment [2] POPOPrivKey, 187 keyAgreement [3] POPOPrivKey } 189 POPOSigningKey ::= SEQUENCE { 190 poposkInput [0] POPOSigningKeyInput OPTIONAL, 191 algorithmIdentifier AlgorithmIdentifier, 192 signature BIT STRING } 193 -- The signature (using "algorithmIdentifier") is on the 194 -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg 195 -- certReq CertTemplate contains the subject and publicKey values, 196 -- then poposkInput MUST be omitted and the signature MUST be 197 -- computed on the DER-encoded value of CertReqMsg certReq. If 198 -- the CertReqMsg certReq CertTemplate does not contain the public 199 -- key and subject values, then poposkInput MUST be present and 200 -- MUST be signed. This strategy ensures that the public key is 201 -- not present in both the poposkInput and CertReqMsg certReq 202 -- CertTemplate fields. 204 POPOSigningKeyInput ::= SEQUENCE { 205 authInfo CHOICE { 206 sender [0] GeneralName, 207 -- used only if an authenticated identity has been 208 -- established for the sender (e.g., a DN from a 209 -- previously-issued and currently-valid certificate) 210 publicKeyMAC PKMACValue }, 211 -- used if no authenticated GeneralName currently exists for 212 -- the sender; publicKeyMAC contains a password-based MAC 213 -- on the DER-encoded value of publicKey 214 publicKey SubjectPublicKeyInfo } -- from CertTemplate 216 PKMACValue ::= SEQUENCE { 217 algId AlgorithmIdentifier, 218 -- the algorithm value shall be PasswordBasedMac 219 -- {1 2 840 113533 7 66 13} 220 -- the parameter value is PBMParameter 221 value BIT STRING } 223 POPOPrivKey ::= CHOICE { 224 thisMessage [0] BIT STRING, 225 -- posession is proven in this message (which contains the private 226 -- key itself (encrypted for the CA)) 227 subsequentMessage [1] SubsequentMessage, 228 -- possession will be proven in a subsequent message 229 dhMAC [2] BIT STRING } 230 -- for keyAgreement (only), possession is proven in this message 231 -- (which contains a MAC (over the DER-encoded value of the 232 -- certReq parameter in CertReqMsg, which must include both subject 233 -- and publicKey) based on a key derived from the end entity's 234 -- private DH key and the CA's public DH key); 235 -- the dhMAC value MUST be calculated as per the directions given 236 -- in Appendix A. 238 SubsequentMessage ::= INTEGER { 239 encrCert (0), 240 -- requests that resulting certificate be encrypted for the 241 -- end entity (following which, POP will be proven in a 242 -- confirmation message) 243 challengeResp (1) } 244 -- requests that CA/RA engage in challenge-response exchange with 245 -- end entity in order to prove private key possession 247 It is expected that protocols which incorporate this specification will 248 include the confirmation and challenge-response messages necessary to a 249 complete protocol. 251 5.4.1 Use of Password-Based MAC 253 The following algorithm SHALL be used when publicKeyMAC is used in 254 POPOSigningKeyInput to prove the authenticity of a request. 256 PBMParameter ::= SEQUENCE { 257 salt OCTET STRING, 258 owf AlgorithmIdentifier, 259 -- AlgId for a One-Way Function (SHA-1 recommended) 260 iterationCount INTEGER, 261 -- number of times the OWF is applied 262 mac AlgorithmIdentifier 263 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 264 } -- or HMAC [RFC2104, RFC2202]) 266 The process of using PBMParameter to compute publicKeyMAC and so 267 authenticate the origin of a public key certification request consists 268 of two stages. The first stage uses shared secret information to produce 269 a MAC key. The second stage MACs the public key in question using 270 this MAC key to produce an authenticated value. 272 Initialization of the first stage of algorithm assumes the existence of 273 a shared secret distributed in a trusted fashion between CA/RA and end- 274 entity. The salt value is appended to the shared secret and the one way 275 function (owf) is applied iterationCount times, where the salted secret 276 is the input to the first iteration and, for each successive iteration, 277 the input is set to be the output of the previous iteration, yielding a 278 key K. 280 In the second stage, K and the public key are inputs to HMAC as 281 documented in [HMAC] to produce a value for publicKeyMAC as follows: 283 publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) ) 285 where ipad and opad are defined in [RFC2104]. 287 The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and for 288 mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. 290 6. CertRequest syntax 292 The CertRequest syntax consists of a request identifier, a template 293 of certificate content, and an optional sequence of control information. 295 CertRequest ::= SEQUENCE { 296 certReqId INTEGER, -- ID for matching request and reply 297 certTemplate CertTemplate, -- Selected fields of cert to be issued 298 controls Controls OPTIONAL } -- Attributes affecting issuance 300 CertTemplate ::= SEQUENCE { 301 version [0] Version OPTIONAL, 302 serialNumber [1] INTEGER OPTIONAL, 303 signingAlg [2] AlgorithmIdentifier OPTIONAL, 304 issuer [3] Name OPTIONAL, 305 validity [4] OptionalValidity OPTIONAL, 306 subject [5] Name OPTIONAL, 307 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 308 issuerUID [7] UniqueIdentifier OPTIONAL, 309 subjectUID [8] UniqueIdentifier OPTIONAL, 310 extensions [9] Extensions OPTIONAL } 312 OptionalValidity ::= SEQUENCE { 313 notBefore [0] Time OPTIONAL, 314 notAfter [1] Time OPTIONAL } --at least one must be present 316 Time ::= CHOICE { 317 utcTime UTCTime, 318 generalTime GeneralizedTime } 320 7. Controls Syntax 322 The generator of a CertRequest may include one or more control values 323 pertaining to the processing of the request. 325 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 326 The following controls are defined (it is recognized that this list 327 may expand over time): regToken; authenticator; pkiPublicationInfo; 328 pkiArchiveOptions; oldCertID; protocolEncrKey. 330 7.1 Registration Token Control 332 A regToken control contains one-time information (either based on a 333 secret value or on knowledge) intended to be used by the CA to verify 334 the identity of the subject prior to issuing a certificate. Upon 335 receipt of a certification request containing a value for regToken, 336 the receiving CA verifies the information in order to confirm the 337 identity claimed in the certification request. 339 The value for regToken may be generated by the CA and provided out of 340 band to the subscriber, or may otherwise be available to both the CA 341 and the subscriber. The security of any out-of-band exchange should 342 be commensurate with the risk of the CA accepting an intercepted value 343 from someone other than the intended subscriber. 345 The regToken control would typically be used only for initialization 346 of an end entity into the PKI, whereas the authenticator control (see 347 Section 7.2) would typically be used for initial as well as subsequent 348 certification requests. 350 In some instances of use the value for regToken could be a text string 351 or a numeric quantity such as a random number. The value in the latter 352 case could be encoded either as a binary quantity or as a text string 353 representation of the binary quantity. To ensure a uniform encoding of 354 values regardless of the nature of the quantity, the encoding of 355 regToken SHALL be UTF8. 357 7.2 Authenticator Control. 359 An authenticator control contains information used in an ongoing basis 360 to establish a non-cryptographic check of identity in communication 361 with the CA. Examples include: mother's maiden name, last four digits 362 of social security number, or other knowledge-based information shared 363 with the subscriber's CA; a hash of such information; or other 364 information produced for this purpose. The value for an authenticator 365 control may be generated by the subscriber or by the CA. 367 In some instances of use the value for regToken could be a text string 368 or a numeric quantity such as a random number. The value in the latter 369 case could be encoded either as a binary quantity or as a text string 370 representation of the binary quantity. To ensure a uniform encoding of 371 values regardless of the nature of the quantity, the encoding of 372 authenticator SHALL be UTF8. 374 7.3 Publication Information Control 376 The pkiPublicationInfo control enables subscribers to control the CA's 377 publication of the certificate. It is defined by the following syntax: 379 PKIPublicationInfo ::= SEQUENCE { 380 action INTEGER { 381 dontPublish (0), 382 pleasePublish (1) }, 383 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 385 -- pubInfos MUST NOT be present if action is "dontPublish" 386 -- (if action is "pleasePublish" and pubInfos is omitted, 387 -- "dontCare" is assumed) 389 SinglePubInfo ::= SEQUENCE { 390 pubMethod INTEGER { 391 dontCare (0), 392 x500 (1), 393 web (2), 394 ldap (3) }, 395 pubLocation GeneralName OPTIONAL } 397 If the dontPublish option is chosen, the requester indicates that the 398 PKI should not publish the certificate (this may indicate that the 399 requester intends to publish the certificate him/herself). 401 If the dontCare method is chosen, or if the PKIPublicationInfo control 402 is omitted from the request, the requester indicates that the PKI 403 MAY publish the certificate using whatever means it chooses. 405 If the requester wishes the certificate to appear in at least some 406 locations but wishes to enable the CA to make the certificate available 407 in other repositories, set two values of SinglePubInfo for pubInfos: one 408 with x500, web or ldap value and one with dontCare. 410 The pubLocation field, if supplied, indicates where the requester would 411 like the certificate to be found (note that the CHOICE within 412 GeneralName includes a URL and an IP address, for example). 414 7.4 Archive Options Control 416 The pkiArchiveOptions control enables subscribers to supply information 417 needed to establish an archive of the private key corresponding to the 418 public key of the certification request. It is defined by the following 419 syntax: 421 PKIArchiveOptions ::= CHOICE { 422 encryptedPrivKey [0] EncryptedKey, 423 -- the actual value of the private key 424 keyGenParameters [1] KeyGenParameters, 425 -- parameters which allow the private key to be re-generated 426 archiveRemGenPrivKey [2] BOOLEAN } 427 -- set to TRUE if sender wishes receiver to archive the private 428 -- key of a key pair which the receiver generates in response to 429 -- this request; set to FALSE if no archival is desired. 431 EncryptedKey ::= CHOICE { 432 encryptedValue EncryptedValue, 433 envelopedData [0] EnvelopedData } 434 -- The encrypted private key MUST be placed in the envelopedData 435 -- encryptedContentInfo encryptedContent OCTET STRING. 437 EncryptedValue ::= SEQUENCE { 438 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 439 -- the intended algorithm for which the value will be used 440 symmAlg [1] AlgorithmIdentifier OPTIONAL, 441 -- the symmetric algorithm used to encrypt the value 442 encSymmKey [2] BIT STRING OPTIONAL, 443 -- the (encrypted) symmetric key used to encrypt the value 444 keyAlg [3] AlgorithmIdentifier OPTIONAL, 445 -- algorithm used to encrypt the symmetric key 446 valueHint [4] OCTET STRING OPTIONAL, 447 -- a brief description or identifier of the encValue content 448 -- (may be meaningful only to the sending entity, and used only 449 -- if EncryptedValue might be re-examined by the sending entity 450 -- in the future) 451 encValue BIT STRING } 453 KeyGenParameters ::= OCTET STRING 455 An alternative to sending the key is to send the information about how 456 to re-generate the key using the KeyGenParameters choice (e.g., for many 457 RSA implementations one could send the first random numbers tested for 458 primality). The actual syntax for this parameter may be defined in a 459 subsequent version of this document or in another standard. 461 7.5 OldCert ID Control 463 If present, the OldCertID control specifies the certificate to be 464 updated by the current certification request. The syntax of its value 465 is: 467 CertId ::= SEQUENCE { 468 issuer GeneralName, 469 serialNumber INTEGER 470 } 472 7.6 Protocol Encryption Key Control 474 If present, the protocolEncrKey control specifies a key the CA is to use 475 in encrypting a response to CertReqMessages. 477 This control can be used when a CA has information to send to the 478 subscriber that needs to be encrypted. Such information includes a 479 private key generated by the CA for use by the subscriber. 481 The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo. 483 8. Object Identifiers 485 The OID id-pkix has the value 487 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 488 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 490 -- arc for Internet X.509 PKI protocols and their components 491 id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) } 493 -- Registration Controls in CRMF 494 id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } 495 id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 } 496 id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 } 497 id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } 498 id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } 499 id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } 500 id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } 502 -- Registration Info in CRMF 503 id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) } 504 id-regInfo-asciiPairs OBJECT IDENTIFIER ::= { id-regInfo 1 } 505 --with syntax OCTET STRING 506 id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } 507 --with syntax CertRequest 509 9. Security Considerations 511 The security of CRMF delivery is reliant upon the security mechanisms of 512 the protocol or process used to communicate with CAs. Such protocol or 513 process needs to ensure the integrity, data origin authenticity, and 514 privacy of the message. Encryption of a CRMF is strongly recommended if 515 it contains subscriber-sensitive information and if the CA has an 516 encryption certificate that is known to the end entity. 518 10. References 520 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 521 for Message Authentication", Internet Request for Comments 522 2104, February 1997. 524 11. Acknowledgments 526 The authors gratefully acknowledge the contributions of Barbara Fox, 527 Warwick Ford, Russ Housley and John Pawling, whose review and comments 528 significantly clarified and improved the utility of this specification. 530 7. INTELLECTUAL PROPERTY STATEMENT 532 The authors have no knowledge of any pending or granted patents covering 533 the techniques described. 535 12. Authors' Addresses 537 Michael Myers Carlisle Adams 538 VeriSign, Inc. Entrust Technologies 539 1390 Shorebird Way Ottawa, Ontario 540 Mountain View, CA 94019 Canada K1V 1A7 541 mmyers@verisign.com cadams@entrust.com 543 Dave Solo David Kemp 544 Citicorp National Security Agency, M/S X31 545 666 Fifth Ave, 3rd Floor 9800 Savage Road 546 New York, Ny 10103 Fort Meade, MD 20755 547 david.solo@citicorp.com dpkemp@missi.ncsc.mil 549 Appendix A. Constructing "dhMAC" 551 This Appendix describes the method for computing the bit string 552 "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie- 553 Hellman certificate requests. 555 1. The entity generates a DH public/private key-pair. 557 The DH parameters used to calculate the public SHOULD be those 558 specified in the CA's DH certificate. 560 From CA's DH certificate: 561 CApub = g^x mod p (where g and p are the established DH 562 parameters and x is the CA's private 563 DH component) 564 For entity E: 565 DH private value = y 566 Epub = DH public value = g^y mod p 568 2. The MACing process will then consist of the following steps. 570 a) The value of the certReq field is DER encoded, yielding a binary 571 string. This will be the 'text' referred to in [HMAC], the 572 data to which HMAC-SHA1 is applied. 574 b) A shared DH secret is computed, as follows, 575 shared secret = Kec = g^xy mod p 577 [This is done by the entity E as CApub^y and by the CA as 578 Epub^x, where CApub is retrieved from the CA's DH certificate 579 and Epub is retrieved from the actual certification request.] 581 c) A key K is derived from the shared secret Kec and the subject 582 and issuer names in the CA's certificate as follows: 584 K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName) 586 where "|" means concatenation. If subjectName in the CA cert- 587 ificate is an empty SEQUENCE then DER-encoded-subjectAltName should 589 be used instead; similarly, if issuerName is an empty 590 SEQUENCE then DER-encoded-issuerAltName should be used instead. 592 d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as: 593 SHA1(K XOR opad, SHA1(K XOR ipad, text)) 595 where, 596 opad (outer pad) = the byte 0x36 repeated 64 times 597 and 598 ipad (inner pad) = the byte 0x5C repeated 64 times. 600 Namely, 602 (1) Append zeros to the end of K to create a 64 byte string 603 (e.g., if K is of length 16 bytes it will be appended with 48 604 zero bytes 0x00). 605 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in step 606 (1) with ipad. 607 (3) Append the data stream 'text' to the 64 byte string resulting 608 from step (2). 609 (4) Apply SHA1 to the stream generated in step (3). 610 (5) XOR (bitwise exclusive-OR) the 64 byte string computed in 611 step (1) with opad. 612 (6) Append the SHA1 result from step (4) to the 64 byte string 613 resulting from step (5). 614 (7) Apply SHA1 to the stream generated in step (6) and output 615 the result. 617 Sample code is also provided in [RFC2104, RFC2202]. 619 e) The output of (d) is encoded as a BIT STRING (the value "dhMAC"). 621 3. The proof-of-possession process requires the CA to carry out 622 steps (a) through (d) and then simply compare the result of step (d) 623 with what it received as the "dhMAC" value. If they match then 624 the following can be concluded. 626 1) The Entity possesses the private key corresponding to the public 627 key in the certification request (because it needed the private 628 key to calculate the shared secret). 630 2) Only the intended CA can actually verify the request (because 631 the CA requires its own private key to compute the same shared 632 secret). This helps to protect from rogue CAs. 634 References 636 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed Hashing 637 for Message Authentication", Internet Request for Comments 638 2104, February, 1997. 640 [RFC2202] P. Cheng, R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", 641 Internet Request for Comments 2202, September 1997. 643 Acknowledgements 645 The details of this Appendix were provided by Hemma Prafullchandra. 647 Appendix B. Use of RegInfo for Name-Value Pairs 649 The "value" field of the id-regInfo-utf8Pairs OCTET STRING (with 650 "tag" field equal to 12 and appropriate "length" field) will contain 651 a series of UTF8 name/value pairs. 653 This Appendix lists some common examples of such pairs for the 654 purpose of promoting interoperability among independent 655 implementations of this specification. It is recognized that this 656 list is not exhaustive and will grow with time and implementation 657 experience. 659 B.1. Example Name/Value Pairs 661 When regInfo is used to convey one or more name-value pairs (via 662 id-regInfo-utf8Pairs), the first and subsequent pairs SHALL be 663 structured as follows: 665 [name?value][%name?value]*% 667 This string is then encoded into an OCTET STRING and placed into the 668 regInfo SEQUENCE. 670 Reserved characters are encoded using the %xx mechanism of [RFC1738], 671 unless they are used for their reserved purposes. 673 The following table defines a recommended set of named elements. The 674 value in the column "Name Value" is the exact text string that will 675 appear in the regInfo. 677 Name Value 678 ---------- 679 version -- version of this variation of regInfo use 680 corp_company -- company affiliation of subscriber 681 org_unit -- organizational unit 682 mail_firstName -- personal name component 683 mail_middleName -- personal name component 684 mail_lastName -- personal name component 685 mail_email -- subscriber's email address 686 jobTitle -- job title of subscriber 687 employeeID -- employee identification number or string 689 mailStop -- mail stop 690 issuerName -- name of CA 691 subjectName -- name of Subject 692 validity -- validity interval 694 For example: 696 version?1%corp_company?Acme, Inc.%org_unit?Engineering% 697 mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% 698 mail_email?john@acme.com% 700 B.1.1. IssuerName, SubjectName and Validity Value Encoding 702 When they appear in id-regInfo-utf8Pairs syntax as named elements, 703 the encoding of values for issuerName, subjectName and validity SHALL 704 use the following syntax. The characters [] indicate an optional 705 field, ::= and | have their usual BNF meanings, and all other symbols 706 (except spaces which are insignificant) outside non-terminal names 707 are terminals. Alphabetics are case-sensitive. 709 issuerName ::= 710 subjectName ::= 711 ::= | : 713 ::= validity ? []-[] 714 ::=