idnits 2.17.1 draft-ietf-pkix-rfc2511bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1873. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 36), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2101 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2005) is 6975 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) == Missing Reference: 'RFC2119' is mentioned on line 116, but not defined -- Looks like a reference, but probably isn't: '0' on line 1725 -- Looks like a reference, but probably isn't: '1' on line 1656 -- Looks like a reference, but probably isn't: '2' on line 1658 -- Looks like a reference, but probably isn't: '3' on line 1660 -- Looks like a reference, but probably isn't: '4' on line 1662 -- Looks like a reference, but probably isn't: '5' on line 1510 -- Looks like a reference, but probably isn't: '6' on line 1511 -- Looks like a reference, but probably isn't: '7' on line 1512 -- Looks like a reference, but probably isn't: '8' on line 1513 -- Looks like a reference, but probably isn't: '9' on line 1514 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1473, but not defined == Unused Reference: 'RFC 2119' is defined on line 1257, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11' ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) ** Obsolete normative reference: RFC 2875 (Obsoleted by RFC 6955) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 17 errors (**), 0 flaws (~~), 7 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Schaad 3 PKIX Working Group Soaring Hawk Consulting 4 March 2005 5 expires in six months 7 Internet X.509 Public Key Infrastructure 8 Certificate Request Message Format (CRMF) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 or will be disclosed, and any of which I become aware will be 19 disclosed, in accordance with RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes the Certificate Request Message Format (CRMF) 41 syntax and semantics. This syntax is used to convey a request for a 42 certificate to a Certification Authority (CA), possibly via a 43 Registration Authority (RA), for the purposes of X.509 certificate 44 production. The request will typically include a public key and the 45 associated registration information. This document does not define a 46 certificate request protocol 48 Table Of Contents 50 1. Introduction and Terminology......................................3 51 2. Overview..........................................................3 52 2.1 Changes since RFC 2511...........................................4 53 3. CertReqMessage Syntax..............................................4 54 4. Proof of Possession (POP)..........................................5 55 4.1 Signature Key POP................................................7 56 4.2 Key Encipherment Keys............................................9 57 4.2.1 Private Key Info Content Type...............................10 58 4.2.2 Private Key Structures......................................12 59 4.2.3 Challenge-Response Guidelines...............................13 60 4.3 Key Agreement Keys..............................................13 61 4.4 Use of Password-Based MAC......................................14 62 5. CertRequest syntax...............................................15 63 6. Controls Syntax...................................................17 64 6.1 Registration Token Control......................................18 65 6.2 Authenticator Control...........................................18 66 6.3 Publication Information Control.................................19 67 6.4 Archive Options Control........................................20 68 6.5 OldCert ID Control.............................................22 69 6.6 Protocol Encryption Key Control................................22 70 7. RegInfo Controls.................................................23 71 7.1 utf8Pairs......................................................23 72 7.2 certReq........................................................23 73 8. Object Identifiers...............................................24 74 9. Security Considerations..........................................24 75 10. IANA Considerations..............................................26 76 11. References.......................................................26 77 11.1 Normative References..........................................26 78 11.2 Informative References.........................................27 79 12. Acknowledgments..................................................27 80 13. Authors' Addresses...............................................27 81 Appendix A. Use of RegInfo for Name-Value Pairs......................28 82 A.1. Defined Names..................................................28 83 A.2 IssuerName, SubjectName and Validity Value Encoding.............29 84 Appendix B. ASN.1 Structures and OIDs................................30 85 Appendix C. Why do Proof of Possession (POP).........................36 86 Appendix D - Change History..........................................37 87 D.1 Changes from -06 to -07.........................................37 88 D.2 Changes from -07 to -08.........................................38 89 D.3 Changes from -08 to -09.........................................38 90 Appendix E - Full Copyright Statement................................38 92 1. Introduction and Terminology 94 This document describes the Certificate Request Message Format 95 (CRMF). A Certificate Request Message object is used within a 96 protocol to convey a request for a certificate to a Certification 97 Authority (CA), possibly via a Registration Authority (RA), for the 98 purposes of X.509 certificate production. The request will typically 99 include a public key and the associated registration information. 101 The certificate request object defined in this document is not a 102 standalone protocol. The information defined in this document is 103 designed to be used by an externally define Certificate Request 104 Protocol (CRP). The referencing protocol is expected to define what 105 algorithms are used, what registration information and control 106 structures are defined. Many of the requirements in this document 107 refer to the referencing Certificate Request Protocol (CRP). 109 Certificate requests may be submitted by an RA requesting a 110 certificate on behalf of a Subject, by a CA requesting a cross- 111 certificate from another CA, or directly by an End Entity (EE). 113 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 114 in this document (in uppercase, as shown) are to be interpreted as 115 described in RFC 2119 [RFC2119]. 117 2. Overview 119 Construction of a certification request involves the following steps: 121 a) A CertRequest object is constructed. This object may include the 122 public key, all or a portion of the Subject name, other requested 123 certificate fields, and additional control information related to the 124 registration process. Depending on the CRP this information can be 125 specified by the Subject and potentially modified by an RA, or be 126 specified by the RA based on knowledge of the Subject or 127 documentation presented by the Subject. 129 b) If required, a proof of possession (of the private key 130 corresponding to the public key for which a certificate is being 131 requested) value is calculated. 133 c) Additional registration information can be combined with the 134 proof of possession value and the CertRequest structure to form a 135 CertReqMessage. Additional registration information can be added by 136 both the Subject and an RA. 138 d) The CertReqMessage is securely communicated to a CA. Specific 139 means of secure transport are to be specified by each CRP that refers 140 to this document. 142 2.1 Changes since RFC 2511 144 1. Addition of an introduction section. 146 2. Addition of the concept of a CRP and language relating to CRPs. 148 3. In section 6.2 changed regToken to authenticator. 150 4. Add information describing the contents of the EncryptedValue 151 structure. 153 5. Changed name and contents of OID {id-regInfo 1}. 155 6. Added text detailing what goes into the fields of the different 156 structures defined in the document. 158 7. Replaced appendix A with a reference to [RFC 2875]. The only 159 difference is that the old text specified to use subject alt name 160 instead of subject name if subject name was empty. This is not 161 possible for a CA certificate issued using PKIX. It would however be 162 useful to update RFC 2875 to have this fall back position. 164 7. Insert Appendix C describing why POP is necessary and what some 165 of the different POP attacks are. 167 8. pop field in the CertReqMsg structure has been renamed to popo to 168 avoid confusion between POP and pop. 170 9. The use of the EncryptedValue structure is now discouraged in 171 favor of the EnvelopedData structure. 173 10. Add details on how private keys are to be structured when 174 encrypted. 176 11. Allow for POP on key agreement algorithms other than DH. 178 3. CertReqMessage Syntax 180 A certificate request message is composed of the certificate request, 181 an optional proof of possession field and an optional registration 182 information field. 184 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg 186 CertReqMsg ::= SEQUENCE { 187 certReq CertRequest, 188 popo ProofOfPossession OPTIONAL, 189 -- content depends upon key type 190 regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL 191 } 193 The fields of CertReqMsg have the following meaning: 195 certReq contains the template of the certificate being requested. 196 The template is filled in by (or on behalf of) the Subject. Not 197 all fields within the template need to be specified. Details on 198 this field are found in section 5. 200 popo contains the value used to demonstrate that the entity that 201 will be identified as the Subject of the certificate is actually 202 in possession of the corresponding private key. This field varies 203 in structure and content based on the public key algorithm and the 204 mode (encryption vs. signature) in which the algorithm is used, as 205 specified in the KeyUsage field of the certificate to be issued. 206 Details on this field are found in section 4. 208 regInfo field SHOULD contain only supplementary information 209 relating to the context of the certificate request, where such 210 information is required to fulfill the request. This information 211 might include subscriber contact information, billing information 212 or other ancillary information useful to fulfillment of the 213 request. 215 Information directly related to certificate content SHOULD be 216 included in the certReq content. However, inclusion of additional 217 certReq content by RAs can invalidate the popo field (depending on 218 the details of the POP method used). Data therefore intended for 219 certificate content MAY be provided in regInfo. 221 It is the responsibility of a referencing CRP to define the details 222 of what can be specified in the regInfo field. This document 223 describes one method of encoding the information found in this field. 224 Details on this encoding are found in Appendix A. 226 4. Proof of Possession (POP) 228 In order to prevent certain attacks (see Appendix C) and to allow a 229 CA/RA to properly check the validity of the binding between a subject 230 and a key pair, the PKI management structures specified here make it 231 possible for a subject to prove that it has possession of (i.e., is 232 able to use) the private key corresponding to the public key for 233 which a certificate is requested. A given CRP is free to choose how 234 to enforce POP (e.g., out-of-band procedural means versus the CRMF 236 in-band message) in its certification exchanges. Within a given CRP, 237 CAs and RAs are free to choose from among the POP methods provided 238 (i.e., this is a policy issue local to an RA/CA). A CRP SHOULD 239 define either which POP methods are required, or specify a mechanism 240 for clients to discover the POP methods supported. 242 Any CRP referencing this document MUST enforce POP by some means. 243 There are currently many non-PKIX operational protocols in use 244 (various electronic mail protocols are one example) that do not 245 explicitly check the binding between the end entity and the private 246 key. Until operational protocols that do verify the binding (for 247 signature, encryption, and key agreement key pairs) exist, and are 248 ubiquitous, this binding cannot be assumed to have been verified by 249 the CA/RA. Therefore, one cannot truly know if the binding of the 250 public key and the identity in the certificate is actually correct. 252 POP is accomplished in different ways depending on the type of key 253 for which a certificate is requested. If a key can be used for 254 multiple purposes (e.g., a signing and decryption RSA key) then any 255 of the methods MAY be used. Protocol designers need to be aware that 256 there can be hardware limitations on what POP methods may be usable, 257 e.g., if the private key is maintained in a hardware token. 259 This specification allows for cases where POP is validated by the CA, 260 the RA, or both. Some policies require the CA to verify POP during 261 certificate issuance, in which case the RA MUST forward the end 262 entity's CertRequest and ProofOfPossession fields unaltered to the 263 CA. (In this case the RA could verify the POP and reject failing 264 certificate requests rather than forwarding them to the CA.) If the 265 CA is not required by policy to verify POP, then the RA SHOULD 266 forward the end entity's request and proof unaltered to the CA as 267 above. If this is not possible (for example because the RA verifies 268 POP by an out-of-band method), then the RA uses the raVerified 269 element to attest to the CA that the required proof has been 270 validated. If the CA/RA uses an out-of-band method to verify POP 271 (such as physical delivery of CA/RA-generated private keys) then the 272 ProofOfPossession field is omitted. 274 ProofOfPossession ::= CHOICE { 275 raVerified [0] NULL, 276 signature [1] POPOSigningKey, 277 keyEncipherment [2] POPOPrivKey, 278 keyAgreement [3] POPOPrivKey } 280 The fields of ProofOfPossession have the following meaning: 282 raVerified indicates that the RA has performed the POP required on 283 the certificate request. This field is used by an RA when 1) the 284 CA is not required to do its own POP verification and 2) the RA 285 needs to change the contents of the certReq field. CRPs MUST 286 provide a method for the RA to sign the ProofOfPossession. A 287 requestor MUST NOT set this field and an RA/CA MUST NOT accept a 288 ProofOfPossession where the requestor sets this field. 290 signature is used for performing POP with signature keys. The 291 details of this field are covered in section 4.1. 293 keyEncipherment is used for performing POP with key encipherment 294 encryption based keys (i.e. RSA). The details of this field are 295 covered in section 4.2. 297 keyAgreement is used for performing POP with key agreement type 298 encryption keys (i.e. DH). The details of this field are covered 299 in section 4.3. 301 4.1 Signature Key POP 303 POP for a signature key is accomplished by performing a signature 304 operation on a piece of data containing the identity for which the 305 certificate is desired. 307 There are three cases that need to be looked at when doing a POP for 308 a signature key: 310 1. The certificate subject has not yet established an authenticated 311 identity with a CA/RA but has a one-time password and identity issued 312 by the CA/RA. In this case the POPOSigningKeyInput structure would 313 be filled out using the publicKeyMAC choice for authInfo and the 314 password and identity would be used to compute the publicKeyMAC 315 value. The public key for the certificate being requested would be 316 placed in both the POPOSigningKeyInput and the Certificate Template 317 structures. The signature field is computed over the DER encoded 318 POPOSigningKeyInput structure. 320 2. The CA/RA has established an authenticated identity for the 321 certificate subject, but the requestor is not placing it into the 322 certificate request. In this case the POPOSigningKeyInput 323 structure would be filled out using the sender choice for authInfo. 324 The public key for the certificate being requested would be placed in 325 both the POPOSigningKeyInput and the Certificate Template structures. 326 The signature field is computed over the DER encoded 327 POPOSigningKeyInput structure. 329 3. The certificate subject places its name in the Certificate 330 Template structure along with the public key. In this case the 331 poposkInput field is omitted from the POPOSigningKey structure. The 333 signature field is computed over the DER certReq field of the 334 CertReqMsg structure. 336 POPOSigningKey ::= SEQUENCE { 337 poposkInput [0] POPOSigningKeyInput OPTIONAL, 338 algorithmIdentifier AlgorithmIdentifier, 339 signature BIT STRING } 341 The fields of POPOSigningKey have the following meaning: 343 poposkInput contains the data to be signed, when present. This 344 field MUST be present when the certificate template does not 345 contain both the public key value and a subject name value. 347 algorithmIdentifier identifiers the signature algorithm and an 348 associated parameters used to produce the POP value. 350 signature contains the POP value produced. If poposkInput is 351 present, the signature is computed using the DER encoded value of 352 poposkInput. If poposkInput is absent, the signature is computed 353 using the DER encoded value of certReq. 355 POPOSigningKeyInput ::= SEQUENCE { 356 authInfo CHOICE { 357 sender [0] GeneralName, 358 -- used only if an authenticated identity has been 359 -- established for the sender (e.g., a DN from a 360 -- previously-issued and currently-valid certificate) 361 publicKeyMAC PKMACValue }, 362 -- used if no authenticated GeneralName currently exists for 363 -- the sender; publicKeyMAC contains a password-based MAC 364 -- on the DER-encoded value of publicKey 365 publicKey SubjectPublicKeyInfo } -- from CertTemplate 367 The fields of POPOSigningKeyInput have the following meaning: 369 sender contains an authenticated identity that has previously been 370 established for the subject. 372 publicKeyMAC contains a computed value using a shared secret 373 between the CA/RA and the certificate requestor. 375 publicKey contains a copy of the public key from the certificate 376 template. This MUST be exactly the same value as is contained in 377 the certificate template. 379 PKMACValue ::= SEQUENCE { 380 algId AlgorithmIdentifier, 382 value BIT STRING } 384 The fields of PKMACValue have the following meaning: 386 algId identifiers the algorithm used to compute the MAC value. 387 All implementations MUST support id-PasswordBasedMAC. The details 388 on this algorithm are presented in section 4.4. 390 value contains the computed MAC value. The MAC value is computed 391 over the DER encoded public key of the certificate subject. 392 2 393 The CA/RA identifies the shared secret to be used by looking at 1) 394 the subject name field in the certificate request, 2) the subject 395 alternative name field in the certificate request or 3) either the 396 regToken (see section 6.1) or authToken (see section 6.2) controls. 398 4.2 Key Encipherment Keys 400 POP for key encipherment keys is accomplished by one of three 401 different methods. The private key can be provided to the CA/RA, an 402 encrypted challenge from the CA/RA can be decrypted (direct method) 403 or the created certificate can be returned encrypted and used as the 404 challenge response (indirect method). 406 POPOPrivKey ::= CHOICE { 407 thisMessage [0] BIT STRING, -- discouraged 408 subsequentMessage [1] SubsequentMessage, 409 dhMAC [2] BIT STRING, -- deprecated 410 agreeMAC [3] PKMACValue, 411 encryptedKey [4] EnvelopedData } 412 -- for keyAgreement (only), possession is proven in this message 413 -- (which contains a MAC (over the DER-encoded value of the 414 -- certReq parameter in CertReqMsg, which must include both subject 415 -- and publicKey) based on a key derived from the end entity's 416 -- private DH key and the CA's public DH key); 417 -- the dhMAC value MUST be calculated as per the directions given 418 -- in RFC 2875 for static DH proof of possesion. 420 SubsequentMessage ::= INTEGER { 421 encrCert (0), 422 challengeResp (1) } 424 The fields of POPOPrivKey have the following meaning: 426 thisMessage contains the encrypted private key for which a 427 certificate is to be issued. The possession of the private key is 428 proved by providing it to the CA/RA. This field was incorrectly 429 typed when the specification was first written. The correct way 431 to use this field is to encrypt the private using using the 432 EncryptedValue structure and then wrap that in the BIT STRING 433 type. This field has been discouraged in favor of the 434 encryptedKey field. This is because EnvelopedData offers key 435 management options not supported by the EncryptedValue data type. 437 subsequentMessage is used to indicate that the POP will be 438 completed by decrypting a message from the CA/RA and a response 439 returned. The type of message to be decrypted is indicated by the 440 value used. 442 encrCert indicates that the certificate issued is to be 443 returned in an encrypted form. The requestor is required to 444 decrypt the certificate and prove success to the CA/RA. The 445 details of this are provided by the CRP. 447 challengeResponse indicates that a challenge message is to be 448 sent from the CA/RA to the requestor. The details of the 449 challenge message and the response are details to be provided 450 by the CRP. 452 dhMAC is used for Diffie-Hellman key agreement keys. It contains 453 a computed MAC that is obtained by using the requestor's private 454 key and the CA/RA public key. The use of this field is deprecated 455 in favor of the agreeMAC field. Details are covered in section 456 4.3. 458 agreeMAC is used for key agreement keys. It contains a computed 459 MAC that is obtained by using the requestor's private key and a 460 matching CA/RA public key. Details are covered in section 4.3. 462 macAlg contains the algorithm identifying the method used to 463 compute the MAC value. 465 macValue contains the computed MAC value. 467 encryptedKey contains the encrypted private key matching the 468 public key for which the certificate is to be issued. It also 469 contains an identification value to indicate it was constructed by 470 the requestor of the certificate. The enveloped content type MUST 471 be id-ct-encKeyWithID. 473 It is expected that protocols that incorporate this specification 474 will include the confirmation and challenge-response messages 475 necessary for a complete protocol. 477 4.2.1 Private Key Info Content Type 479 This content type is used for 1) proving possession of private keys 480 and 2) escrow of private keys (using the archive options control in 481 section 6.4). This structure is based on the private key info 483 structure from [PKCS8] but has one deliberate difference. There is a 484 potential attack on escrow agents if they decrypt the private key but 485 don't know who the encrypted key is supposed to belong to. An 486 attacker could intercept the encrypted private key, build a 487 certificate request around it and then ask for a recovery operation 488 on the private key. 490 This content type and its structure are: 492 id-ct-encKeyWithID ::= OBJECT IDENTIFER ::= {id-ct 21} 494 EncKeyWithID ::= SEQUENCE { 495 privateKey PrivateKeyInfo, 496 identifier CHOICE { 497 string UTF8String, 498 generalName GeneralName 499 } OPTIONAL 500 } 502 PrivateKeyInfo ::= SEQUENCE { 503 version INTEGER, 504 privateKeyAlgorithm AlgorithmIdentifier, 505 privateKey OCTET STRING, 506 attributes [0] IMPLICIT Attributes OPTIONAL 507 } 509 Attributes ::= SET OF Attribute 511 The fields of EncKeyWithID are defined as: 513 privateKey contains the encoded private key. Definitions for 514 three private key formats are included in this document. 515 Specifications for asymmetric algorithms need to include both the 516 public and private key definitions for consistency. 518 identifier contains a name that the CA/RA can associate with the 519 requestor. This will generally be either the DN of a certificate 520 or a text token passed known to both the requestor and the CA/RA. 521 This field MUST be present if the purpose is to prove possession 522 of the private key. The field SHOULD be present if archiving a 523 key and the archive agent is expected to decrypt the key. 525 The fields of PrivatekeyInfo are define as: 527 version MUST be the value 0 529 privateKeyAlgorithm contains the identifier for the private key 530 object 532 privateKey is an octet string whose contents is the private key 533 and whose format is defined by the value of privateKeyAlgorithm. 535 attributes is a set of attributes. These are extended information 536 that is part of the private key information. 538 4.2.2 Private Key Structures 540 We are defining the structures here to be used for three algorithms. 542 4.2.2.1 D-H Private Keys 544 When creating a PrivateKeyInfo for a D-H key, the following rules 545 apply: 547 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The 548 parameter for id-dh-private-number is DomainParameters (imported 549 from [PKIXALG]). 551 2. The ASN structure for privateKey MUST be 553 DH-PrivateKey ::= INTEGER 555 3. The attributes field MUST be omitted. 557 4.2.2.2 DSA Private Keys 559 When creating a PrivateKeyInfo for a DSA key, the following rules 560 apply: 562 1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters 563 for id-dsa is Dss-Parms (imported from [PKIXALG]). 565 2. The ASN structure for privateKey MUST be 567 DSA-PrivateKey ::= INTEGER 569 3. The attributes field MUST be omitted. 571 4.2.2.3 RSA Private Keys 573 When creating a PrivateKeyInfo for an RSA key, the following rules 574 apply: 576 1. The privateKeyAlgorithm MUST be set to rsaEncryption. 578 2. The ASN structure for privateKey MUST be RSAPrivateKey (defined 579 in [PKCS1]) 581 3. The attributes field MUST be omitted. 583 4.2.3 Challenge-Response Guidelines 585 The following provides guidelines to enrollment protocol authors 586 about how an indirect proof of possession is expected to work and 587 some of the areas where one needs to be careful in crafting the 588 messages to implement this POP method. 590 1. The original enrollment request includes a proof of identity of 591 some type and the public portion of the encryption key. Note 592 that the proof of identity needs cover the public portion of the 593 encryption key to prevent substitution attacks (where the 594 attacker changes your public key for his public key). 596 2. The response message from the server includes an encrypted data 597 value of some type. That value needs to be authenticated as 598 coming from the server in some fashion. The specification needs 599 to include the specifics of how this value is returned for the 600 different key types. For RSA keys the value can be specified as 601 being directly encrypted by the RSA public key, this will not 602 work for a D-H key where you need to specify an indirect 603 mechanism to encrypt the value. 605 3. The second request message includes a hash of the decrypted 606 value. This message MUST NOT be just the hash of the encrypted 607 value as one should never "sign" a completely random value. One 608 method to avoid this is to include information such as an 609 identity string in the hashing process. This returned value MUST 610 be included in a second proof of identity. 612 It is strongly suggested that transaction identifiers and nonce 613 values be required when performing indirect POP as this allows for 1) 614 tying the different messages in the process together and 2) for 615 letting each entity inject some amount of random data into the 616 process for doing identity proofs on. 618 4.3 Key Agreement Keys 620 POP for key agreement keys is accomplished by one of four different 621 methods. The first three are identical to those presented above for 622 key encryption keys. The fourth method takes advantage of the fact 623 that a shared secret is produced and that value can be used to MAC 624 information. 626 When the direct or indirect encryption methods presented above are 627 used, the CA/RA will need to create an ephemeral key for those cases 628 where the encryption algorithm parameters do not match between the 629 CA/RA and the requestor. 631 The end entity may also MAC the certificate request (using a shared 632 secret key derived from computation) as a fourth alternative for 633 demonstrating POP. This option may be used only if the CA/RA already 634 has a certificate that is known to the end entity and if the Subject 635 is able to use the CA/RA's key parameters. 637 For the DH key agreement algorithm, all implementations MUST support 638 the static DH Proof-of-Possession. Details on this algorithm can be 639 found in section 3 of [RFC 2875]. NOTE: If either the subject or 640 issuer name in the CA certificate is empty, then the alternative name 641 should be used in its place. 643 4.4 Use of Password-Based MAC 645 This MAC algorithm was designed to take a shared secret (a password) 646 and use it to compute a check value over a piece of information. The 647 assumption being that without the password the correct check value 648 cannot be computed. The algorithm computes the one way function 649 multiple times in order to slow down any dictionary attacks against 650 the password value. 652 The algorithm identifier and parameter structure used for Password- 653 Based MAC is: 655 id-PasswordBasedMAC OBJECT IDENTIFIER ::= 656 { 1 2 840 113533 7 66 13} 658 PBMParameter ::= SEQUENCE { 659 salt OCTET STRING, 660 owf AlgorithmIdentifier, 661 iterationCount INTEGER, 662 mac AlgorithmIdentifier 663 ) 665 The fields of PEMParameter have the following meaning: 667 salt contains a randomly generated value used in computing the key 668 of the MAC process. The salt SHOULD be at least 8 octets (64 bits) 669 long. 671 owf identifies the algorithm and associated parameters used to 672 compute the key used in the MAC process. All implementations MUST 673 support SHA-1. 675 iterationCount identifies the number of times the hash is applied 676 during the key computation process. The iterationCount MUST be a 677 minimum of 100. Many people suggest using values as high as 1000 678 iterations as the minimum value. The trade off here is between 680 protection of the password from attacks and the time spent by the 681 server processing all of the different iterations in deriving 682 passwords. Hashing is generally considered to be a cheap 683 operation but this may not be true with all hash functions in the 684 future. 686 mac identifies the algorithm and associated parameters of the MAC 687 function to be used. All implementations MUST support HMAC-SHA1 688 [HMAC]. All implementations SHOULD support DES-MAC and Triple-DES- 689 MAC [PKCS11]. 691 The following is pseudo code for the algorithm: 693 Inputs: 694 pw an octet string containing the user's password 695 data an octet string containing the value to be MAC-ed 696 iteration count Iter 698 Output: 699 MAC an octet string containing the resultant MAC value. 701 1. Generate a random salt value S 703 2. Append the salt to the pw. K = pw || salt. 705 3. Hash the value of K. K = HASH(K) 707 4. Iter = Iter - 1. If Iter is greater than zero. Goto step 3. 709 5. Compute an HMAC as documented in [HMAC]. 711 MAC = HASH( K XOR opad, HASH( K XOR ipad, data) ) 713 Where opad and ipad are defined in [HMAC]. 715 5. CertRequest syntax 717 The CertRequest syntax consists of a request identifier, a template 718 of certificate content, and an optional sequence of control 719 information. 721 CertRequest ::= SEQUENCE { 722 certReqId INTEGER, -- ID for matching request and reply 723 certTemplate CertTemplate, --Selected fields of cert to be issued 724 controls Controls OPTIONAL } -- Attributes affecting issuance 726 CertTemplate ::= SEQUENCE { 727 version [0] Version OPTIONAL, 729 serialNumber [1] INTEGER OPTIONAL, 730 signingAlg [2] AlgorithmIdentifier OPTIONAL, 731 issuer [3] Name OPTIONAL, 732 validity [4] OptionalValidity OPTIONAL, 733 subject [5] Name OPTIONAL, 734 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 735 issuerUID [7] UniqueIdentifier OPTIONAL, 736 subjectUID [8] UniqueIdentifier OPTIONAL, 737 extensions [9] Extensions OPTIONAL } 739 OptionalValidity ::= SEQUENCE { 740 notBefore [0] Time OPTIONAL, 741 notAfter [1] Time OPTIONAL } --at least one must be present 743 Time ::= CHOICE { 744 utcTime UTCTime, 745 generalTime GeneralizedTime } 747 The fields of CertRequest have the following meaning: 749 certReqId contains an integer value that is used by the 750 certificate requestor to associate a specific certificate request 751 with a certificate response. 753 certTemplate contains a template of an X.509 certificate. The 754 requestor fills in those fields for which specific values are 755 desired. Details on the fields are given below. 757 controls contains attributes that are not part of the certificate, 758 but control the context in which the certificate is to be issued. 759 Details on the controls defined in this document can be found in 760 section 6. Other documents may define other controls. CRPs are 761 responsible for specifying which controls are required. 763 The fields of CertTemplate have the following meaning: 765 version MUST be 2 if supplied. It SHOULD be omitted. 767 serialNumber MUST be omitted. This field is assigned by the CA 768 during certificate creation. 770 signingAlg MUST be omitted. This field is assigned by the CA 771 during certificate creation. 773 issuer is normally omitted. It would be filled in with the CA 774 that the requestor desires to issue the certificate in situations 775 where an RA is servicing more than one CA. 777 validity is normally omitted. It can be used to request that 778 certificates either start at some point in the future or expire at 780 some specific time. A case where this field would commonly be 781 used is when a cross certificate is issued for a CA. In this case 782 the validity of an existing certificate would be placed in this 783 field so that the new certificate would have the same validity 784 period as the existing certificate. If validity is not omitted 785 then at least one of the sub-fields MUST be specified. The sub- 786 fields are as follows: 788 notBefore contains the requested start time of the certificate. 789 The time follows the same rules as the notBefore time in 790 [PROFILE]. 792 notAfter contains the requested expiration time of the 793 certificate. The time follows the same rules as the notAfter 794 time in [PROFILE]. 796 subject is filled in with the suggested name for the requestor. 797 This would normally be filled in by a name that has previously 798 been issued to the requestor by the CA. 800 publicKey contains the public key for which the certificate is 801 being created. This field MUST be filled in if the requestor 802 generates its own key. The field is omitted if the key is 803 generated by the RA/CA. 805 issuerUID MUST be omitted. This field has been deprecated in 806 [PROFILE]. 808 subjectUID MUST be omitted. This field has been deprecated in 809 [PROFILE]. 811 extensions contains extensions that the requestor wants to have 812 placed in the certificate. These extensions would generally deal 813 with things such as setting the key usage to keyEncipherment. 815 With the exception of the publicKey field, the CA/RA is permitted to 816 alter any requested field. The returned certificate needs to be 817 checked by the requestor to see if the fields have been set in an 818 acceptable manner. CA/RA SHOULD use the template fields if possible. 820 There are cases where all fields of the template can be omitted. If 821 the key generation is being done at the CA/RA and the identity proof 822 is placed in a different location (such as the id-regCtrl-regToken 823 below), then there are no fields that needs to be specified by the 824 certificate requestor. 826 6. Controls Syntax 828 The generator of a CertRequest may include one or more control values 829 pertaining to the processing of the request. 831 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 833 The following controls are defined by this document: regToken; 834 authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID; 835 protocolEncrKey. Each CRP MUST define the set of controls supported 836 by that protocol. Additional controls may be defined by additional 837 RFCs or by the CRP protocol itself. 839 6.1 Registration Token Control 841 A regToken control contains one-time information (either based on a 842 secret value or other shared information) intended to be used by the 843 CA to verify the identity of the subject prior to issuing a 844 certificate. Upon receipt of a certification request containing a 845 value for regToken, the receiving CA verifies the information in 846 order to confirm the identity claimed in the certification request. 848 The value for regToken may be generated by the CA and provided out of 849 band to the subscriber, or may otherwise be available to both the CA 850 and the subscriber. The security of any out-of-band exchange should 851 be commensurate with the risk that the CA will tolerate with regard 852 to accepting an intercepted value from someone other than the 853 intended subscriber. The regToken value is not encrypted on return, 854 if the data is considered to be sensitive it needs to be shrouded by 855 the requestor. 857 The regToken control is used only for initialization of an end entity 858 into the PKI, whereas the authenticator control (see Section 7.2) can 859 be used both for the initial as well as subsequent certification 860 requests. 862 In some instances of use the value for regToken could be a text 863 string or a numeric quantity such as a random number. The value in 864 the latter case is encoded as a text string representation of the 865 binary quantity. The encoding of regToken SHALL be UTF8String. 867 id-regCtrl-regTokenUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 9 } 869 Without prior agreement between the subscriber and CA agents, this 870 value would be a textual shared secret of some type. If a computed 871 value based on that shared secret is to be used instead, it is 872 suggested that the CRP define a new registration control for that 873 specific computation. 875 6.2 Authenticator Control. 877 An authenticator control contains information used in an ongoing 878 basis to establish a non-cryptographic check of identity in 880 communication with the CA. Examples include: mother's maiden name, 881 last four digits of social security number, or other knowledge-based 882 information shared with the subscriber's CA; a hash of such 883 information; or other information produced for this purpose. The 884 value for an authenticator control may be generated by the subscriber 885 or by the CA. 887 In some instances of use the value for authenticator could be a text 888 string or a numeric quantity such as a random number. The value in 889 the latter case is encoded as a text string representation of the 890 binary quantity. The encoding of authenticator SHALL be UTF8String. 892 id-regCtrl-authenticatorUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 10 } 894 When deciding whether to use an authenticator or a regToken, use the 895 following guidelines. If the value is a one time usage value, then 896 regToken would be used. If the value has a long term usage then the 897 authenticator control would be used. 899 6.3 Publication Information Control 901 The pkiPublicationInfo control enables subscribers to influence the 902 CA/RA's publication of the certificate. This control is considered 903 to be advisory and can be ignored by CAs/RAs. It is defined by the 904 following OID and syntax: 906 id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } 908 PKIPublicationInfo ::= SEQUENCE { 909 action INTEGER { 910 dontPublish (0), 911 pleasePublish (1) }, 912 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 914 SinglePubInfo ::= SEQUENCE { 915 pubMethod INTEGER { 916 dontCare (0), 917 x500 (1), 918 web (2), 919 ldap (3) }, 920 pubLocation GeneralName OPTIONAL } 922 The fields of PKIPublicationInfo have the following meaning: 924 action indicates whether or not the requestor wishes the CA/RA to 925 publish the certificate. The values and their means are: 927 dontPublish indicates that the requester wishes the CA/RA not 928 to publish the certificate (this may indicate that the 929 requester intends to publish the certificate him/herself). If 930 dontPublish is used, the pubInfos field MUST be omitted. 932 pleasePublish indicates that the requestor wishes the CA/RA to 933 publish the certificate. 935 pubInfos holds the locations where the requestor desires the CA/RA 936 to publish the certificate. This field is omitted if the 937 dontPublish choice is selected. If the requestor wants to specify 938 some locations for the certificate to be published, and to allow 939 the CA/RA to publish in other locations would specify multiple 940 values of the SinglePubInfo structure, one of which would be 941 dontCare. 943 The fields of SinglePubInfo have the following meaning: 945 pubMethod indicates the address type for the location at which the 946 requestor desires the certificate to be placed by the CA/RA. 948 dontCare indicates that the CA/RA can publish the certificate 949 in whatever locations it choses. If dontCare is used, the 950 pubInfos field MUST be omitted. 952 x500 indicates that the requestor wishes for the CA/RA to 953 publish the certificate in a specific location. The location 954 is indicated in the x500 field of pubLocation. 956 ldap indicates that the requestor wishes for the CA/RA to 957 publish the certificate in a specific location. The location 958 is indicated in the ldap field of pubLocation. 960 web indicates that the requestor wishes for the CA/RA to 961 publish the certificate in a specific location. The location 962 is indicated in the http field of pubLocation. 964 pubLocation contains the address at which the certificate is to be 965 placed. The choice in the general name field is dictated by the 966 pubMethod selection in this structure. 968 Publication locations can be supplied in any order. All locations 969 are to be processed by the CA for purposes of publication. 971 6.4 Archive Options Control 973 The pkiArchiveOptions control enables subscribers to supply 974 information needed to establish an archive of the private key 975 corresponding to the public key of the certification request. It is 976 defined by the following OID and syntax: 978 id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } 980 PKIArchiveOptions ::= CHOICE { 981 encryptedPrivKey [0] EncryptedKey, 982 -- the actual value of the private key 983 keyGenParameters [1] KeyGenParameters, 984 -- parameters which allow the private key to be re-generated 985 archiveRemGenPrivKey [2] BOOLEAN } 986 -- set to TRUE if sender wishes receiver to archive the private 987 -- key of a key pair that the receiver generates in response to 988 -- this request; set to FALSE if no archival is desired. 990 EncryptedKey ::= CHOICE { 991 encryptedValue EncryptedValue, -- deprecated 992 envelopedData [0] EnvelopedData } 993 -- The encrypted private key MUST be placed in the envelopedData 994 -- encryptedContentInfo encryptedContent OCTET STRING. 996 EncryptedValue ::= SEQUENCE { 997 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 998 -- the intended algorithm for which the value will be used 999 symmAlg [1] AlgorithmIdentifier OPTIONAL, 1000 -- the symmetric algorithm used to encrypt the value 1001 encSymmKey [2] BIT STRING OPTIONAL, 1002 -- the (encrypted) symmetric key used to encrypt the value 1003 keyAlg [3] AlgorithmIdentifier OPTIONAL, 1004 -- algorithm used to encrypt the symmetric key 1005 valueHint [4] OCTET STRING OPTIONAL, 1006 -- a brief description or identifier of the encValue content 1007 -- (may be meaningful only to the sending entity, and used only 1008 -- if EncryptedValue might be re-examined by the sending entity 1009 -- in the future) 1010 encValue BIT STRING } 1011 -- The use of the EncryptedValue field has been deprecated in favor 1012 -- of the EnvelopedData structure. 1013 -- 1014 -- When EncryptedValue is used to carry a private key (as opposed to 1015 -- a certificate), implementations MUST support the encValue field 1016 -- containing an encrypted PrivateKeyInfo as defined in [PKCS11], 1017 -- section 12.11. If encValue contains some other format/encoding 1018 -- for the private key, the first octet of valueHint MAY be used 1019 -- to indicate the format/encoding (but note that the possible values 1020 -- of this octet are not specified at this time). In all cases, the 1021 -- intendedAlg field MUST be used to indicate at least the OID of 1022 -- the intended algorithm of the private key, unless this information 1023 -- is known a priori to both sender and receiver by some other means. 1025 KeyGenParameters ::= OCTET STRING 1027 The fields of PKIArchiveOptions have the following meaning: 1029 encryptedPrivKey contains an encrypted version of the private key. 1031 keyGenParameters contains the information needed by the requestor 1032 to regenerate the private key. As an example, for many RSA 1033 implementations one could send the first random number(s) tested 1034 for primality. The structure to go here is not defined by this 1035 document. CRPs that define content for this structure MUST define 1036 not only the content that is to go here but how that data is 1037 shrouded from unauthorized access. 1039 archiveRemGenPrivKey indicates that the requestor desires that the 1040 key generated by the CA/RA on the requestor's behalf be archived. 1042 The fields of EncryptedKey have the following meaning: 1044 encryptedValue is longer used. This field has been deprecated 1045 along with the EncryptedValue structure. 1047 envelopedData contains the encrypted value of the private key. 1048 CPRs that use this structure MUST define the entity or entities 1049 for whom the data is to be encrypted (the EE, escrow agents, CAs) 1050 and how that key or set of keys is to be determined. Details on 1051 constructing an EnvelopedData structure are found in [CMS]. The 1052 encrypted content MUST be an id-ct-encKeyWithID. The identifier 1053 can be omitted unless this structure is also being used to do 1054 proof-of-possession. 1056 6.5 OldCert ID Control 1058 If present, the OldCertID control specifies the certificate to be 1059 updated by the current certification request. The OID and syntax is: 1061 id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } 1063 CertId ::= SEQUENCE { 1064 issuer GeneralName, 1065 serialNumber INTEGER 1066 } 1068 6.6 Protocol Encryption Key Control 1070 If present, the protocolEncrKey control specifies a key the CA is to 1071 use in encrypting a response to CertReqMessages. The OID for this 1072 control is id-regCtrl-protocolEncrKey. The parameter structure for 1074 this field is SubjectPublicKeyInfo. (This structure is defined in 1075 [PROFILE].) 1077 id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } 1079 This control is used when a CA has information to send to the 1080 subscriber that needs to be encrypted. Such information includes a 1081 private key generated by the CA for use by the subscriber. 1083 7. RegInfo Controls 1085 This section documents the controls that are to be placed in the 1086 regInfo field of the CertReqMsg structure. 1088 7.1 utf8Pairs 1090 This control is used to convey text based information from the 1091 Subject to an RA to a CA issuing a certificate. The OID for this 1092 structure is id-regInfo-utf8Paris and has a type of UTF8String. 1094 id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 } 1096 The name is terminated by the question mark character ('?'). The 1097 value is terminated by the percent character '%'. Name value pairs 1098 can be repeated. Thus the syntax is: 1100 Name?Value%[Name?Value%]* 1102 The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%' 1103 (%25) if they are not being used for their reserved purpose. Names 1104 MUST NOT start with a numeric character. 1106 This control can appear multiple times in the regInfo structure. 1107 Resolution of conflicts of information is a matter of local policy on 1108 the RA/CA. 1110 Appendix A contains a set of common names and data formats 1111 corresponding to fields that commonly appear in certificates and 1112 directories. 1114 7.2 certReq 1116 This control is designed to deal with the problem where an RA needs 1117 to modify the certificate template proposed by a Subject, but the 1118 Subject used the certificate template as part of its POP calculation. 1119 In this case the RA can place a new certificate template in the 1120 regInfo sequence. 1122 This control has the OID id-regInfo-certReq and the structure 1123 CertRequest. There can only be one instance of this attribute in the 1124 regInfo sequence. If this control exists in the regInfo structure 1125 then the certificate template in the request is ignored. The RA MUST 1126 copy all data from the core template to this attribute. 1128 id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } 1130 8. Object Identifiers 1132 The OID id-pkix has the value 1134 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1135 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1137 -- arc for Internet X.509 PKI protocols and their components 1138 id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) } 1140 -- arc for Registration Controls in CRMF 1141 id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } 1143 -- arc for Registration Info in CRMF 1144 id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) } 1146 9. Security Considerations 1148 Enrollment protocols, by their very nature, involve large amounts of 1149 private information. This can include private keys, identity 1150 numbers, credit card numbers and the like. The security of any CRP 1151 is based on the security mechanisms of the protocol and/or process 1152 used to communicate between CAs, RAs and EEs. All protocols must 1153 provide for masking, either via encryption or off-line processing, of 1154 all subscriber-sensitive information. 1156 Many enrollment protocols provide for the initial establishment of 1157 identity between the CA/RA and the EE by the use of a token. 1158 Generally this token is delivered using an out-of-band delivery 1159 method (such as the governmental mail system). The security of any 1160 out-of-band exchange needs to be commensurate with the risk that the 1161 CA/RA will tolerate with regard to interception of the token by a 1162 third party. 1164 Implementation must implement Proof-of-Possession (POP) values during 1165 certificate enrollment processes. A good POP algorithm needs to 1166 provide proof of two things: 1) that the key is tied to a specific 1167 user and 2) that the user has use of the key in question. Failure to 1169 implement POP allows for people to create certificates where the 1170 public key and the name values do not correctly bind. This allows 1171 for impersonation on signature keys and interception of encrypted 1172 messages. 1174 Implementations must use high entropy random number generators in 1175 producing private keys. Implementations must randomly generate 1176 content-encryption keys, message-authentication keys, initialization 1177 vectors (IVs), salt, and padding. The use of inadequate pseudo- 1178 random number generators (PRNGs) to generate cryptographic keys can 1179 result in little or no security. An attacker may find it much easier 1180 to reproduce the PRNG environment that produced the keys, searching 1181 the resulting small set of possibilities, rather than brute force 1182 searching the whole key space. The generation of quality random 1183 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in 1184 this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality 1185 PRNG technique. 1187 Implementations must protect private keys. The compromise of a 1188 signer's private key permits third parties to masquerade as the 1189 signer. The compromise of a decryption private key allows for 1190 interception of messages by a third party. 1192 One feature of the certificate message request syntax is for the key 1193 generation to be performed remotely from the creation of the 1194 certificate request. This feature should never be used for 1195 generation of signing keys. If signing keys are generated for the 1196 user, then an element of repudiation comes into play. The user can 1197 claim that an item was signed by the entity that generated the key as 1198 well as any entity that might have seen the key value during transfer 1199 from the generator the to EE. Care must be taken to protect 1200 encryption keys by the remote key generator to protect againist 1201 interception of the keys by a third party. This means that the 1202 encryption algorithms used need to be secure, and content encryption 1203 key or key encryption key must be used to mask the private key during 1204 transport back to the user. CRP protocols must never assume that a 1205 signature key generated by the user can be used to decrypt the 1206 package that an encryption private key is transported in. 1208 This document describes a method by which key escrow may be done. 1209 There are several issues that need to be taken into account when 1210 doing key escrow. First, the client must be able to correctly 1211 identify the entity to which a key is to be escrowed or the CRP must 1212 provide a method by which the client can discover this information. 1213 A CRP cannot assume that the key escrow agent and the CA are the same 1214 entity and thus have the same names. Second, the algorithms used 1215 mask the private key or other key generation information during 1217 transport to the escrow agent need to be commensurate with the value 1218 of the data being protected by the key. Third, the escrow agent needs 1219 to provide sufficient safeguards that an escrowed key is returned 1220 only to entities that should be able to obtain the private key. This 1221 generally should be restricted to the entity that escrowed the data. 1222 Fourth, the escrow data base needs to be stored in a secure manner. 1223 One common method for doing this is to re-encrypt the data to keys 1224 that only the escrow agent has access to. In this case one may need 1225 to escrow the escrow agent key as well. Access to either the escrow 1226 agent or the archived key would amount to access to all private keys 1227 that have been escrowed with that agent. 1229 10. IANA Considerations 1231 This document defines Registration Controls and Registration Info 1232 objects. These objects are all defined by object identifiers (OIDs). 1233 The OIDs for the objects were assigned from an arc delegated by the 1234 IANA to the PKIX Working Group. No further action by the IANA is 1235 necessary for this document or any anticipated updates. 1237 This document defines a CMS Content Type. This object is defined by 1238 an object identifier (OID) assigned from an arc delegated to the 1239 S/MIME Working Group. No further action by IANA is necessary for 1240 this document or any anticipated updates. 1242 11. References 1244 11.1 Normative References 1246 [PKCS1] Jonsson, J., B. Kaliski, "Public-Key Cryptography Standards 1247 (PKCS) #1: RSA Cryptography Specifications 2.1", RFC 3447, 1248 February 2003. 1250 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 1251 Hashing for Message Authentication", RFC 2104, February 1997. 1253 [PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - 1254 "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA 1255 Security Inc., June 2001. 1257 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 1261 X.509 Public Key Infrastructure Certificate and 1262 Certificate Revocation List (CRL) Profile", RFC 3280, 1263 April 2002. 1265 [PKIXALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and 1266 Identifiers for the Internet X.509 Public Key Infrastructure 1267 Certificate and Certificate Revocation List (CRL) Profile", 1268 RFC 3279, April 2002. 1270 [CMS] Housley, R, "Cryptographic Message Syntax (CMS)", 1271 RFC 3369, August 2002 1273 [RFC 2875] Prafullchandra, H., J. Schaad, "Diffie-Hellman Proof-of- 1274 Possession Algorithms" RFC 2875, June 2000. 1276 11.2 Informative References 1278 [DSS] National Institute of Standards and Technology, FIPS Pub 186: 1279 Digital Signature Standard, May 1994. 1281 [PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax 1282 Standard", PKCS #8 v1.2, November 1993. 1284 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 1285 Recommendations for Security, RFC 1750, December 1994. 1287 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 1288 SHA-1", RFC 2202, September 1997. 1290 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, 1291 "Uniform Resource Locators (URL)", RFC 1738, December 1994. 1293 12. Acknowledgments 1295 The working group would like to thank Michael Myers, Carlisle Adams, 1296 Dave Solo and David Kemp who authored the original version of this 1297 document. 1299 The working group also gratefully acknowledges the contributions of 1300 Barbara Fox, Warwick Ford, Russ Housley and John Pawling, whose 1301 review and comments significantly clarified and improved the utility 1302 of this specification. The members of the ca-talk mailing list also 1303 provided significant input with respect to interoperability testing. 1305 The text of Appendix C (Why do POP) was taken from an e-mail message 1306 by Al Arsenault and was originally part of the PKIX Roadmap document. 1308 13. Authors' Addresses 1310 Jim Schaad 1311 Soaring Hawk Consulting 1312 PO Box 675 1314 Gold Bar, WA 98251 1316 EMail: jimsch@exmsft.com 1318 Appendix A. Use of RegInfo for Name-Value Pairs 1320 The "value" field of the id-regInfo-utf8Pairs string (with "tag" 1321 field equal to 12 and appropriate "length" field) will contain a 1322 series of UTF8 name/value pairs. 1324 This Appendix lists some common examples of such pairs for the 1325 purpose of promoting interoperability among independent 1326 implementations of this specification. It is recognized that this 1327 list is not exhaustive and will grow with time and implementation 1328 experience. 1330 A.1. Defined Names 1332 The following table defines a recommended set of named elements. The 1333 value in the column "Name Value" is the exact text string that will 1334 appear in the regInfo. 1336 Name Value 1337 ---------- 1338 version -- version of this variation of regInfo use 1339 corp_company -- company affiliation of subscriber 1340 org_unit -- organizational unit 1341 mail_firstName -- personal name component 1342 mail_middleName -- personal name component 1343 mail_lastName -- personal name component 1344 mail_email -- subscriber's email address 1345 jobTitle -- job title of subscriber 1346 employeeID -- employee identification number or string 1347 mailStop -- mail stop 1348 issuerName -- name of CA 1349 subjectName -- name of Subject 1350 validity -- validity interval 1352 For example: 1354 version?1%corp_company?Example, Inc.%org_unit?Engineering% 1355 mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% 1356 mail_email?john@example.com% 1358 A.2 IssuerName, SubjectName and Validity Value Encoding 1360 When they appear in id-regInfo-utf8Pairs syntax as named elements, 1361 the encoding of values for issuerName, subjectName and validity SHALL 1362 use the following syntax. The characters [] indicate an optional 1363 field, ::= and | have their usual BNF meanings, and all other symbols 1364 (except spaces which are insignificant) outside non-terminal names 1365 are terminals. Alphabetics are case-sensitive. 1367 issuerName ::= 1368 subjectName ::= 1369 ::= | : 1371 ::= validity ? []-[] 1372 ::=