idnits 2.17.00 (12 Aug 2021) /tmp/idnits6421/draft-ietf-pkix-rfc2511bis-04.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 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 are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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: '...MAX) of AttributeTypeAndValue OPTIONAL...' RFC 2119 keyword, line 87: '...he regInfo field SHOULD only contain s...' RFC 2119 keyword, line 90: '... information MAY include subscriber ...' RFC 2119 keyword, line 94: '...lated to certificate content SHOULD be...' (81 more instances...) 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1019 -- Looks like a reference, but probably isn't: '1' on line 1021 -- Looks like a reference, but probably isn't: '2' on line 1023 -- Looks like a reference, but probably isn't: '3' on line 1025 -- Looks like a reference, but probably isn't: '4' on line 1027 -- Looks like a reference, but probably isn't: '5' on line 865 -- Looks like a reference, but probably isn't: '6' on line 866 -- Looks like a reference, but probably isn't: '7' on line 867 -- Looks like a reference, but probably isn't: '8' on line 868 -- Looks like a reference, but probably isn't: '9' on line 869 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 970, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11' -- 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: 11 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Myers (TraceRoute Security) 2 PKIX Working Group C. Adams (Entrust) 3 December 2001 D. Solo (Citicorp) 4 expires in six months D. Kemp (DoD) 6 Internet X.509 Public Key Infrastructure 7 Certificate Request Message Format (CRMF) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright (C) The Internet Society (2001). All Rights Reserved. 32 1. Abstract 34 This document describes the Certificate Request Message Format 35 (CRMF). This syntax is used to convey a request for a certificate to 36 a Certification Authority (CA) (possibly via a Registration Authority 37 (RA)) for the purposes of X.509 certificate production. The request 38 will typically include a public key and associated registration 39 information. 41 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 42 in this document (in uppercase, as shown) are to be interpreted as 43 described in RFC 2119. 45 2. Overview 47 Construction of a certification request involves the following steps: 49 a) A CertRequest value is constructed. This value may include the 50 public key, all or a portion of the end-entity's (EE's) name, 51 other requested certificate fields, and additional control 52 information related to the registration process. 54 b) A proof of possession (of the private key corresponding to the 55 public key for which a certificate is being requested) value may 56 be calculated across the CertRequest value. 58 c) Additional registration information may be combined with the 59 proof of possession value and the CertRequest structure to form a 60 CertReqMessage. 62 d) The CertReqMessage is securely communicated to a CA. Specific 63 means of secure transport are beyond the scope of this 64 specification. 66 3. CertReqMessage Syntax 68 A certificate request message is composed of the certificate request, 69 an 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 79 } 81 The proof of possession field is used to demonstrate that the entity 82 to be associated with the certificate is actually in possession of 83 the corresponding private key. This field may be calculated across 84 the contents of the certReq field and varies in structure and content 85 by public key algorithm type and operational mode. 87 The regInfo field SHOULD only contain supplementary information 88 related to the context of the certification request when such 89 information is required to fulfill a certification request. This 90 information MAY include subscriber contact information, billing 91 information or other ancillary information useful to fulfillment of 92 the certification request. 94 Information directly related to certificate content SHOULD be 95 included in the certReq content. However, inclusion of additional 96 certReq content by RAs may invalidate the pop field. Data therefore 97 intended for certificate content MAY be provided in regInfo. 99 See Section 8 and Appendix B for example regInfo contents. 101 4. Proof of Possession (POP) 103 In order to prevent certain attacks and to allow a CA/RA to properly 104 check the validity of the binding between an end entity and a key 105 pair, the PKI management operations specified here make it possible 106 for an end entity to prove that it has possession of (i.e., is able 107 to use) the private key corresponding to the public key for which a 108 certificate is requested. A given CA/RA is free to choose how to 109 enforce POP (e.g., out-of-band procedural means versus the CRMF in- 110 band message) in its certification exchanges (i.e., this may be a 111 policy issue). However, it is MANDATED that CAs/RAs MUST enforce POP 112 by some means because there are currently many non-PKIX operational 113 protocols in use (various electronic mail protocols are one example) 114 that do not explicitly check the binding between the end entity and 115 the private key. Until operational protocols that do verify the 116 binding (for signature, encryption, and key agreement key pairs) 117 exist, and are ubiquitous, this binding can only be assumed to have 118 been verified by the CA/RA. Therefore, if the binding is not verified 119 by the CA/RA, certificates in the Internet Public-Key Infrastructure 120 end up being somewhat less meaningful. 122 POP is accomplished in different ways depending on the type of key 123 for which a certificate is requested. If a key can be used for 124 multiple purposes (e.g., an RSA key) then any of the methods MAY be 125 used. 127 This specification allows for cases where POP is validated by the CA, 128 the RA, or both. Some policies may require the CA to verify POP 129 during certification, in which case the RA MUST forward the end 130 entity's CertRequest and ProofOfPossession fields unaltered to the 131 CA, and as an option MAY also verify POP. If the CA is not required 132 by policy to verify POP, then the RA SHOULD forward the end entity's 133 request and proof unaltered to the CA as above. If this is not 134 possible (for example because the RA verifies POP by an out-of-band 135 method), then the RA MAY attest to the CA that the required proof has 136 been validated. If the CA uses an out-of-band method to verify POP 137 (such as physical delivery of CA-generated private keys), then the 138 ProofOfPossession field is not used. 140 4.1 Signature Keys 142 For signature keys, the end entity can sign a value to prove 143 possession of the private key. 145 4.2 Key Encipherment Keys 147 For key encipherment keys, the end entity can provide the private key 148 to the CA/RA, or can be required to decrypt a value in order to prove 149 possession of the private key. Decrypting a value can be achieved 150 either directly or indirectly. 152 The direct method is for the RA/CA to issue a random challenge to 153 which an immediate response by the end entity is required. 155 The indirect method is to issue a certificate which is encrypted for 156 the end entity (and have the end entity demonstrate its ability to 157 decrypt this certificate in a confirmation message). This allows a CA 158 to issue a certificate in a form which can only be used by the 159 intended end entity. 161 4.3 Key Agreement Keys 163 For key agreement keys, the end entity can use any of the three 164 methods given in Section 5.2 for encryption keys. For the direct and 165 indirect methods, the end entity and the PKI management entity (i.e., 166 CA or RA) must establish a shared secret key in order to prove that 167 the end entity has possession of the private key (i.e., in order to 168 decrypt the encrypted certificate or to construct the response to the 169 issued challenge). Note that this need not impose any restrictions 170 on the keys that can be certified by a given CA -- in particular, for 171 Diffie-Hellman keys the end entity may freely choose its algorithm 172 parameters -- provided that the CA can generate a short-term (or 173 one-time) key pair with the appropriate parameters when necessary. 175 The end entity may also MAC the certificate request (using a shared 176 secret key derived from a Diffie-Hellman computation) as a fourth 177 alternative for demonstrating POP. This option may be used only if 178 the CA already has a DH certificate that is known to the end entity 179 and if the EE is willing to use the CA's DH parameters. 181 4.4 Proof of Possession Syntax 183 ProofOfPossession ::= CHOICE { 184 raVerified [0] NULL, 185 -- used if the RA has already verified that the requester is in 186 -- possession of the private key 187 signature [1] POPOSigningKey, 188 keyEncipherment [2] POPOPrivKey, 189 keyAgreement [3] POPOPrivKey } 191 POPOSigningKey ::= SEQUENCE { 192 poposkInput [0] POPOSigningKeyInput OPTIONAL, 193 algorithmIdentifier AlgorithmIdentifier, 194 signature BIT STRING } 195 -- The signature (using "algorithmIdentifier") is on the 196 -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg 197 -- certReq CertTemplate contains the subject and publicKey values, 198 -- then poposkInput MUST be omitted and the signature MUST be 199 -- computed on the DER-encoded value of CertReqMsg certReq. If 200 -- the CertReqMsg certReq CertTemplate does not contain both the 201 -- public key and subject values (i.e., if it contains only one 202 -- of these, or neither), then poposkInput MUST be present and 203 -- MUST be signed. 205 POPOSigningKeyInput ::= SEQUENCE { 206 authInfo CHOICE { 207 sender [0] GeneralName, 208 -- used only if an authenticated identity has been 209 -- established for the sender (e.g., a DN from a 210 -- previously-issued and currently-valid certificate) 211 publicKeyMAC PKMACValue }, 212 -- used if no authenticated GeneralName currently exists for 213 -- the sender; publicKeyMAC contains a password-based MAC 214 -- on the DER-encoded value of publicKey 215 publicKey SubjectPublicKeyInfo } -- from CertTemplate 217 PKMACValue ::= SEQUENCE { 218 algId AlgorithmIdentifier, 219 -- the algorithm value shall be PasswordBasedMac 220 -- {1 2 840 113533 7 66 13} 221 -- the parameter value is PBMParameter 222 value BIT STRING } 224 POPOPrivKey ::= CHOICE { 225 thisMessage [0] BIT STRING, 226 -- posession is proven in this message (which contains the private 227 -- key itself (encrypted for the CA)) 228 subsequentMessage [1] SubsequentMessage, 229 -- possession will be proven in a subsequent message 230 dhMAC [2] BIT STRING } 231 -- for keyAgreement (only), possession is proven in this message 232 -- (which contains a MAC (over the DER-encoded value of the 233 -- certReq parameter in CertReqMsg, which must include both subject 234 -- and publicKey) based on a key derived from the end entity's 235 -- private DH key and the CA's public DH key); 236 -- the dhMAC value MUST be calculated as per the directions given 237 -- in Appendix A. 239 SubsequentMessage ::= INTEGER { 240 encrCert (0), 241 -- requests that resulting certificate be encrypted for the 242 -- end entity (following which, POP will be proven in a 243 -- confirmation message) 244 challengeResp (1) } 245 -- requests that CA/RA engage in challenge-response exchange with 246 -- end entity in order to prove private key possession 248 It is expected that protocols which incorporate this specification 249 will include the confirmation and challenge-response messages 250 necessary to a complete protocol. 252 4.4.1 Use of Password-Based MAC 254 The following algorithm SHALL be used when publicKeyMAC is used in 255 POPOSigningKeyInput to prove the authenticity of a request. 257 PBMParameter ::= SEQUENCE { 258 salt OCTET STRING, 259 owf AlgorithmIdentifier, 260 -- AlgId for a One-Way Function (SHA-1 recommended) 261 iterationCount INTEGER, 262 -- number of times the OWF is applied 263 mac AlgorithmIdentifier 264 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 265 } -- or HMAC [RFC2104, RFC2202]) 267 The process of using PBMParameter to compute publicKeyMAC and so 268 authenticate the origin of a public key certification request 269 consists of two stages. The first stage uses shared secret 270 information to produce a MAC key. The second stage MACs the public 271 key in question using this MAC key to produce an authenticated value. 273 Initialization of the first stage of algorithm assumes the existence 274 of a shared secret distributed in a trusted fashion between CA/RA and 275 end-entity. The salt value is appended to the shared secret and the 276 one way function (owf) is applied iterationCount times, where the 277 salted secret is the input to the first iteration and, for each 278 successive iteration, the input is set to be the output of the 279 previous iteration, yielding a key K. 281 In the second stage, K and the public key are inputs to HMAC as 282 documented in [HMAC] to produce a value for publicKeyMAC as follows: 284 publicKeyMAC = Hash( K XOR opad, Hash( K XOR ipad, public key) ) 286 where ipad and opad are defined in [RFC2104]. 288 The AlgorithmIdentifier for owf SHALL be SHA-1 {1 3 14 3 2 26} and 289 for mac SHALL be HMAC-SHA1 {1 3 6 1 5 5 8 1 2}. 291 5. CertRequest syntax 293 The CertRequest syntax consists of a request identifier, a template 294 of certificate content, and an optional sequence of control 295 information. 297 CertRequest ::= SEQUENCE { 298 certReqId INTEGER, -- ID for matching request and reply 299 certTemplate CertTemplate, --Selected fields of cert to be issued 300 controls Controls OPTIONAL } -- Attributes affecting issuance 302 CertTemplate ::= SEQUENCE { 303 version [0] Version OPTIONAL, 304 serialNumber [1] INTEGER OPTIONAL, 305 signingAlg [2] AlgorithmIdentifier OPTIONAL, 306 issuer [3] Name OPTIONAL, 307 validity [4] OptionalValidity OPTIONAL, 308 subject [5] Name OPTIONAL, 309 publicKey [6] SubjectPublicKeyInfo OPTIONAL, 310 issuerUID [7] UniqueIdentifier OPTIONAL, 311 subjectUID [8] UniqueIdentifier OPTIONAL, 312 extensions [9] Extensions OPTIONAL } 314 OptionalValidity ::= SEQUENCE { 315 notBefore [0] Time OPTIONAL, 316 notAfter [1] Time OPTIONAL } --at least one must be present 318 Time ::= CHOICE { 319 utcTime UTCTime, 320 generalTime GeneralizedTime } 322 6. Controls Syntax 324 The generator of a CertRequest may include one or more control values 325 pertaining to the processing of the request. 327 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 329 The following controls are defined (it is recognized that this list 330 may expand over time): regToken; authenticator; pkiPublicationInfo; 331 pkiArchiveOptions; oldCertID; protocolEncrKey. 333 6.1 Registration Token Control 335 A regToken control contains one-time information (either based on a 336 secret value or on knowledge) intended to be used by the CA to verify 337 the identity of the subject prior to issuing a certificate. Upon 338 receipt of a certification request containing a value for regToken, 339 the receiving CA verifies the information in order to confirm the 340 identity claimed in the certification request. 342 The value for regToken may be generated by the CA and provided out of 343 band to the subscriber, or may otherwise be available to both the CA 344 and the subscriber. The security of any out-of-band exchange should 345 be commensurate with the risk of the CA accepting an intercepted 346 value from someone other than the intended subscriber. 348 The regToken control would typically be used only for initialization 349 of an end entity into the PKI, whereas the authenticator control (see 350 Section 7.2) would typically be used for initial as well as 351 subsequent certification requests. 353 In some instances of use the value for regToken could be a text 354 string or a numeric quantity such as a random number. The value in 355 the latter case could be encoded either as a binary quantity or as a 356 text string representation of the binary quantity. To ensure a 357 uniform encoding of values regardless of the nature of the quantity, 358 the encoding of regToken SHALL be UTF8. 360 6.2 Authenticator Control. 362 An authenticator control contains information used in an ongoing 363 basis to establish a non-cryptographic check of identity in 364 communication with the CA. Examples include: mother's maiden name, 365 last four digits of social security number, or other knowledge-based 366 information shared with the subscriber's CA; a hash of such 367 information; or other information produced for this purpose. The 368 value for an authenticator control may be generated by the subscriber 369 or by the CA. 371 In some instances of use the value for authenticator could be a text 372 string or a numeric quantity such as a random number. The value in 373 the latter case could be encoded either as a binary quantity or as a 374 text string representation of the binary quantity. To ensure a 375 uniform encoding of values regardless of the nature of the quantity, 376 the encoding of authenticator SHALL be UTF8. 378 6.3 Publication Information Control 380 The pkiPublicationInfo control enables subscribers to control the 381 CA's publication of the certificate. It is defined by the following 382 syntax: 384 PKIPublicationInfo ::= SEQUENCE { 385 action INTEGER { 386 dontPublish (0), 387 pleasePublish (1) }, 388 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } 390 -- pubInfos MUST NOT be present if action is "dontPublish" 391 -- (if action is "pleasePublish" and pubInfos is omitted, 392 -- "dontCare" is assumed) 394 SinglePubInfo ::= SEQUENCE { 395 pubMethod INTEGER { 396 dontCare (0), 397 x500 (1), 398 web (2), 399 ldap (3) }, 400 pubLocation GeneralName OPTIONAL } 402 If the dontPublish option is chosen, the requester indicates that the 403 PKI should not publish the certificate (this may indicate that the 404 requester intends to publish the certificate him/herself). 406 If the dontCare method is chosen, or if the PKIPublicationInfo 407 control is omitted from the request, the requester indicates that the 408 PKI MAY publish the certificate using whatever means it chooses. 410 If the requester wishes the certificate to appear in at least some 411 locations but wishes to enable the CA to make the certificate 412 available in other repositories, set two values of SinglePubInfo for 413 pubInfos: one with x500, web or ldap value and one with dontCare. 415 The pubLocation field, if supplied, indicates where the requester 416 would like the certificate to be found (note that the CHOICE within 417 GeneralName includes a URL and an IP address, for example). 419 6.4 Archive Options Control 421 The pkiArchiveOptions control enables subscribers to supply 422 information needed to establish an archive of the private key 423 corresponding to the public key of the certification request. It is 424 defined by the following syntax: 426 PKIArchiveOptions ::= CHOICE { 427 encryptedPrivKey [0] EncryptedKey, 428 -- the actual value of the private key 429 keyGenParameters [1] KeyGenParameters, 430 -- parameters which allow the private key to be re-generated 431 archiveRemGenPrivKey [2] BOOLEAN } 432 -- set to TRUE if sender wishes receiver to archive the private 433 -- key of a key pair which the receiver generates in response to 434 -- this request; set to FALSE if no archival is desired. 436 EncryptedKey ::= CHOICE { 437 encryptedValue EncryptedValue, 438 envelopedData [0] EnvelopedData } 439 -- The encrypted private key MUST be placed in the envelopedData 440 -- encryptedContentInfo encryptedContent OCTET STRING. 442 EncryptedValue ::= SEQUENCE { 443 intendedAlg [0] AlgorithmIdentifier OPTIONAL, 444 -- the intended algorithm for which the value will be used 445 symmAlg [1] AlgorithmIdentifier OPTIONAL, 446 -- the symmetric algorithm used to encrypt the value 447 encSymmKey [2] BIT STRING OPTIONAL, 448 -- the (encrypted) symmetric key used to encrypt the value 449 keyAlg [3] AlgorithmIdentifier OPTIONAL, 450 -- algorithm used to encrypt the symmetric key 451 valueHint [4] OCTET STRING OPTIONAL, 452 -- a brief description or identifier of the encValue content 453 -- (may be meaningful only to the sending entity, and used only 454 -- if EncryptedValue might be re-examined by the sending entity 455 -- in the future) 456 encValue BIT STRING } 457 -- When EncryptedValue is used to carry a private key (as opposed to 458 -- a certificate), implementations MUST support the encValue field 459 -- containing an encrypted PrivateKeyInfo as defined in [PKCS11], 460 -- section 12.11. If encValue contains some other format/encoding 461 -- for the private key, the first octet of valueHint MAY be used 462 -- to indicate the format/encoding (but note that the possible values 463 -- of this octet are not specified at this time). In all cases, the 464 -- intendedAlg field MUST be used to indicate at least the OID of 465 -- the intended algorithm of the private key, unless this information 466 -- is known a priori to both sender and receiver by some other means. 468 KeyGenParameters ::= OCTET STRING 470 An alternative to sending the key is to send the information about 471 how to re-generate the key using the KeyGenParameters choice (e.g., 472 for many RSA implementations one could send the first random numbers 473 tested for primality). The actual syntax for this parameter may be 474 defined in a subsequent version of this document or in another 475 standard. 477 6.5 OldCert ID Control 479 If present, the OldCertID control specifies the certificate to be 480 updated by the current certification request. The syntax of its 481 value is: 483 CertId ::= SEQUENCE { 484 issuer GeneralName, 485 serialNumber INTEGER 486 } 488 6.6 Protocol Encryption Key Control 490 If present, the protocolEncrKey control specifies a key the CA is to 491 use in encrypting a response to CertReqMessages. 493 This control can be used when a CA has information to send to the 494 subscriber that needs to be encrypted. Such information includes a 495 private key generated by the CA for use by the subscriber. 497 The encoding of protocolEncrKey SHALL be SubjectPublicKeyInfo. 499 7. Object Identifiers 501 The OID id-pkix has the value 503 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 504 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 506 -- arc for Internet X.509 PKI protocols and their components 507 id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) } 509 -- Registration Controls in CRMF 510 id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) } 511 id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 } 512 id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 } 513 id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 } 514 id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 } 515 id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 } 516 id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 } 518 -- Registration Info in CRMF 519 id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) } 520 id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 } 521 --with syntax UTF8STRING 522 id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 } 523 --with syntax CertRequest 525 8. Security Considerations 527 The security of CRMF delivery is reliant upon the security mechanisms 528 of the protocol or process used to communicate with CAs. Such 529 protocol or process needs to ensure the integrity, data origin 530 authenticity, and privacy of the message. Encryption of a CRMF is 531 strongly recommended if it contains subscriber-sensitive information 532 and if the CA has an encryption certificate that is known to the end 533 entity. 535 9. References 537 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 538 Hashing for Message Authentication", RFC 2104, February 1997. 540 [PKCS11] RSA Laboratories, The Public-Key Cryptography Standards - 541 "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA 542 Security Inc., June 2001. 544 10. Acknowledgments 546 The authors gratefully acknowledge the contributions of Barbara Fox, 547 Warwick Ford, Russ Housley and John Pawling, whose review and 548 comments significantly clarified and improved the utility of this 549 specification. The members of the ca-talk mailing list also 550 provided significant input with respect to interoperability testing. 552 11. Authors' Addresses 554 Michael Myers 555 TraceRoute Security, Inc. 557 EMail: myers@coastside.net 559 Carlisle Adams 560 Entrust, Inc. 561 1000 Innovation Drive, 562 Ottawa, Canada, K2K 3E7 564 EMail: cadams@entrust.com 566 Dave Solo 567 Citicorp 568 666 Fifth Ave, 3rd Floor 569 New York, Ny 10103 571 EMail: david.solo@citicorp.com 573 David Kemp 574 National Security Agency 575 Suite 6734 576 9800 Savage Road 577 Fort Meade, MD 20755 579 EMail: dpkemp@missi.ncsc.mil 581 Appendix A. Constructing "dhMAC" 583 This Appendix describes the method for computing the bit string 584 "dhMAC" in the proof-of-possession POPOPrivKey structure for Diffie- 585 Hellman certificate requests. 587 1. The entity generates a DH public/private key-pair. 589 The DH parameters used to calculate the public SHOULD be those 590 specified in the CA's DH certificate. 592 From CA's DH certificate: 593 CApub = g^x mod p (where g and p are the established DH 594 parameters and x is the CA's private 595 DH component) 596 For entity E: 597 DH private value = y 598 Epub = DH public value = g^y mod p 600 2. The MACing process will then consist of the following steps. 602 a) The value of the certReq field is DER encoded, yielding a binary 603 string. This will be the 'text' referred to in [HMAC], the data to 604 which HMAC-SHA1 is applied. 606 b) A shared DH secret is computed, as follows, 607 shared secret = Kec = g^xy mod p 609 [This is done by the entity E as CApub^y and by the CA as Epub^x, 610 where CApub is retrieved from the CA's DH certificate and Epub is 611 retrieved from the actual certification request.] 613 c) A key K is derived from the shared secret Kec and the subject and 614 issuer names in the CA's certificate as follows: 616 K = SHA1(DER-encoded-subjectName | Kec | DER-encoded-issuerName) 618 where "|" means concatenation. If subjectName in the CA 619 certificate is an empty SEQUENCE then DER-encoded-subjectAltName 620 should be used instead; similarly, if issuerName is an empty 621 SEQUENCE then DER-encoded-issuerAltName should be used instead. 623 d) Compute HMAC-SHA1 over the data 'text' as per [RFC2104] as: 624 SHA1(K XOR opad, SHA1(K XOR ipad, text)) 626 where, 627 opad (outer pad) = the byte 0x36 repeated 64 times 628 and 629 ipad (inner pad) = the byte 0x5C repeated 64 times. 631 Namely, 633 (1) Append zeros to the end of K to create a 64 byte string 634 (e.g., if K is of length 16 bytes it will be appended with 635 48 zero bytes 0x00). 636 (2) XOR (bitwise exclusive-OR) the 64 byte string computed in 637 step (1) with ipad. 638 (3) Append the data stream 'text' to the 64 byte string 639 resulting from step (2). 640 (4) Apply SHA1 to the stream generated in step (3). 641 (5) XOR (bitwise exclusive-OR) the 64 byte string computed in 642 step (1) with opad. 643 (6) Append the SHA1 result from step (4) to the 64 byte string 644 resulting from step (5). 645 (7) Apply SHA1 to the stream generated in step (6) and output 646 the result. 648 Sample code is also provided in [RFC2104, RFC2202]. 650 e) The output of (d) is encoded as a BIT STRING (the value "dhMAC"). 652 3. The proof-of-possession process requires the CA to carry out 653 steps (a) through (d) and then simply compare the result of step 654 (d) with what it received as the "dhMAC" value. If they match then 655 the following can be concluded. 657 1) The Entity possesses the private key corresponding to the 658 public key in the certification request (because it needed the 659 private key to calculate the shared secret). 661 2) Only the intended CA can actually verify the request (because 662 the CA requires its own private key to compute the same shared 663 secret). This helps to protect from rogue CAs. 665 References 667 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed 668 Hashing for Message Authentication", RFC 2104, February 669 1997. 671 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 672 SHA-1", RFC 2202, September 1997. 674 Acknowledgements 676 The details of this Appendix were provided by Hemma Prafullchandra. 678 Appendix B. Use of RegInfo for Name-Value Pairs 680 The "value" field of the id-regInfo-utf8Pairs string (with "tag" 681 field equal to 12 and appropriate "length" field) will contain a 682 series of UTF8 name/value pairs. 684 This Appendix lists some common examples of such pairs for the 685 purpose of promoting interoperability among independent 686 implementations of this specification. It is recognized that this 687 list is not exhaustive and will grow with time and implementation 688 experience. 690 B.1. Example Name/Value Pairs 692 When regInfo is used to convey one or more name-value pairs (via id- 693 regInfo-utf8Pairs), the first and subsequent pairs SHALL be 694 structured as follows: 696 [name?value][%name?value]*% 698 This string is then encoded into a UTF8STRING and placed into the 699 regInfo SEQUENCE. 701 Reserved characters are encoded using the %xx mechanism of [RFC1738], 702 unless they are used for their reserved purposes. 704 The following table defines a recommended set of named elements. 705 The value in the column "Name Value" is the exact text string that 706 will appear in the regInfo. 708 Name Value 709 ---------- 710 version -- version of this variation of regInfo use 711 corp_company -- company affiliation of subscriber 712 org_unit -- organizational unit 713 mail_firstName -- personal name component 714 mail_middleName -- personal name component 715 mail_lastName -- personal name component 716 mail_email -- subscriber's email address 717 jobTitle -- job title of subscriber 718 employeeID -- employee identification number or string 719 mailStop -- mail stop 720 issuerName -- name of CA 721 subjectName -- name of Subject 722 validity -- validity interval 724 For example: 726 version?1%corp_company?Acme, Inc.%org_unit?Engineering% 727 mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader% 728 mail_email?john@acme.com% 730 B.1.1. IssuerName, SubjectName and Validity Value Encoding 732 When they appear in id-regInfo-utf8Pairs syntax as named elements, 733 the encoding of values for issuerName, subjectName and validity SHALL 734 use the following syntax. The characters [] indicate an optional 735 field, ::= and | have their usual BNF meanings, and all other symbols 736 (except spaces which are insignificant) outside non-terminal names 737 are terminals. Alphabetics are case-sensitive. 739 issuerName ::= 740 subjectName ::= 741 ::= | : 743 ::= validity ? []-[] 744 ::=