idnits 2.17.1 draft-nystrom-pkcs10-v1-7-00.txt: 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 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 323: '...HM.&Type({IOSet}{@algorithm}) OPTIONAL...' RFC 2119 keyword, line 461: '...HM.&Type({IOSet}{@algorithm}) OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2000) is 8679 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '9' on line 542 looks like a reference -- Missing reference section? '2' on line 519 looks like a reference -- Missing reference section? '3' on line 522 looks like a reference -- Missing reference section? '4' on line 525 looks like a reference -- Missing reference section? '11' on line 550 looks like a reference -- Missing reference section? '10' on line 546 looks like a reference -- Missing reference section? '12' on line 554 looks like a reference -- Missing reference section? '13' on line 558 looks like a reference -- Missing reference section? '8' on line 538 looks like a reference -- Missing reference section? '14' on line 562 looks like a reference -- Missing reference section? '7' on line 534 looks like a reference -- Missing reference section? '5' on line 528 looks like a reference -- Missing reference section? '0' on line 433 looks like a reference -- Missing reference section? '1' on line 516 looks like a reference -- Missing reference section? '6' on line 531 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT M. Nystrom 2 Expires: January 2001 B. Kaliski 3 Intended Category: Informational RSA Security 4 July 2000 6 PKCS #10: Certification Request Syntax Specification 7 Version 1.7 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 RFC2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo represents a republication of PKCS #10 v1.7 from RSA 35 Laboratories' Public-Key Cryptography Standards (PKCS) series, and 36 change control is retained within the PKCS process. The remainder of 37 the text is taken from that specification. 39 This memo describes a syntax for certification requests. 41 Table of Contents 43 1. Introduction ................................................. 2 44 2. Definitions and notation ..................................... 2 45 2.1 Definitions ................................................. 2 46 2.2 Notation .................................................... 4 47 3. Overview ..................................................... 4 48 4. Certification request syntax ................................. 5 49 4.1 CertificationRequestInfo .................................... 5 50 4.2 CertificationRequest ........................................ 7 51 5. Security considerations ...................................... 8 52 6. Authors' addresses ........................................... 8 54 Appendices 56 A. ASN.1 module ................................................. 10 57 B. Intellectual property considerations ......................... 11 58 C. Revision history ............................................. 11 59 D. References ................................................... 12 60 E. Contact information & About PKCS ............................. 13 62 1. Introduction 64 This document describes syntax for certification requests. A 65 certification request consists of a distinguished name, a public key, 66 and optionally a set of attributes, collectively signed by the entity 67 requesting certification. Certification requests are sent to a 68 certification authority, which transforms the request into an X.509 69 [9] public-key certificate. (In what form the certification authority 70 returns the newly signed certificate is outside the scope of this 71 document. A PKCS #7 [2] message is one possibility.) 73 The intention of including a set of attributes is twofold: to provide 74 other information about a given entity , or a "challenge password" by 75 which the entity may later request certificate revocation; and to 76 provide attributes for inclusion in X.509 certificates. A non- 77 exhaustive list of attributes is given in PKCS #9 [3]. 79 Certification authorities may also require non-electronic forms of 80 request and may return non-electronic replies. It is expected that 81 descriptions of such forms, which are outside the scope of this 82 document, will be available from certification authorities. 84 The preliminary intended application of this document is to support 85 PKCS #7 cryptographic messages, but it is expected that other 86 applications will be developed (see e.g. [4]). 88 2. Definitions and notation 90 2.1 Definitions 92 For the purposes of this document, the following definitions apply. 94 ALGORITHM An information object class defined in X.509 to 95 describe objects composed of an algorithm (a unique 96 object identifier) and its parameters (any ASN.1 97 type). The values of objects in this class can be 98 represented by the ASN.1 type AlgorithmIdentifier{}. 99 ALGORITHM is defined as the "useful" information 100 object class TYPE-IDENTIFIER, specified in [11], 101 Annex A. 103 AlgorithmIdentifier{} 104 A useful parameterized version of X.509 type 105 AlgorithmIdentifier is defined in this 106 document. This type tightly binds pairs of algorithm 107 object identifiers to their associated parameter 108 types. When referenced, the single parameter of 109 AlgorithmIdentifier{} specifies a constraint on the 110 pairs of values that may appear in that instance of 111 the type. The encoded values of AlgorithmIdentifier{} 112 are equivalent to those of type AlgorithmIdentifier. 114 ASN.1 Abstract Syntax Notation One, as defined in the 115 ASN.1 standards ([10], [11], [12], and [13]). 117 ATTRIBUTE This class describes objects composed of an 118 attribute (a unique object identifier) and an 119 associated set of attribute values (any ASN.1 120 type). The values of objects in this class can be 121 represented by type Attribute{}. 123 Attribute{} A useful parameterized version of X.501 [8] type 124 Attribute is defined in this document. This type 125 tightly binds pairs of attribute type object 126 identifiers to one or more attribute values 127 types. In the ASN.1 open type notation, an attribute 128 type is defined as ATTRIBUTE.&id and an attribute 129 value as ATTRIBUTE.&Type. When referenced, the 130 single parameter of Attribute{} specifies a 131 constraint on the pairs of values that may appear in 132 an instance of the type. The encoded values of 133 Attribute{} are equivalent to those of type 134 Attribute. 136 BER Basic Encoding Rules for ASN.1, as defined in X.690 137 ([14]). 139 Certificate A type that binds a subject entity's distinguished 140 name to a public key with a digital signature. This 141 type is defined in X.509. This type also contains 142 the distinguished name of the certificate issuer 143 (the signer), an issuer-specific serial number, the 144 issuer's signature algorithm identifier, a validity 145 period, and an optional set of certificate 146 extensions. 148 DER Distinguished Encoding Rules for ASN.1, as defined 149 in X.690. DER is a subset of BER. 151 Name A type that uniquely identifies or "distinguishes" 152 objects in an X.500 [7] directory. This type is 153 defined in X.501. In an X.509 certificate, the type 154 identifies the certificate issuer and the 155 certificate subject, the entity whose public key is 156 certified. 158 2.2 Notation 160 No special notation is used in this document. 162 3. Overview 164 A certification request consists of three parts: "certification 165 request information," a signature algorithm identifier, and a digital 166 signature on the certification request information. The certification 167 request information consists of the entity's distinguished name, the 168 entity's public key, and a set of attributes providing other 169 information about the entity. 171 The process by which a certification request is constructed involves 172 the following steps: 174 1. A CertificationRequestInfo value containing a subject 175 distinguished name, a subject public key, and optionally a 176 set of attributes is constructed by an entity requesting 177 certification. 179 2. The CertificationRequestInfo value is signed with the 180 subject entity's private key. (See Section 4.2.) 182 3. The CertificationRequestInfo value, a signature algorithm 183 identifier, and the entity's signature are collected 184 together into a CertificationRequest value, defined below. 186 A certification authority fulfills the request by authenticating the 187 requesting entity and verifying the entity's signature, and, if the 188 request is valid, constructing an X.509 certificate from the 189 distinguished name and public key, the issuer name, and the 190 certification authority's choice of serial number, validity period, 191 and signature algorithm. If the certification request contains any 192 PKCS #9 attributes, the certification authority may also use the 193 values in these attributes as well as other information known to the 194 certification authority to construct X.509 certificate extensions. 196 In what form the certification authority returns the new certificate 197 is outside the scope of this document. One possibility is a PKCS #7 198 cryptographic message with content type signedData, following the 199 degenerate case where there are no signers. The return message may 200 include a certification path from the new certificate to the 201 certification authority. It may also include other certificates such 202 as cross-certificates that the certification authority considers 203 helpful, and it may include certificate-revocation lists (CRLs). 204 Another possibility is that the certification authority inserts the 205 new certificate into a central database. 207 Note 1 - An entity would typically send a certification request after 208 generating a public-key/private-key pair, but may also do so after a 209 change in the entity's distinguished name. 211 Note 2 - The signature on the certification request prevents an 212 entity from requesting a certificate with another party's public key. 213 Such an attack would give the entity the minor ability to pretend to 214 be the originator of any message signed by the other party. This 215 attack is significant only if the entity does not know the message 216 being signed and the signed part of the message does not identify the 217 signer. The entity would still not be able to decrypt messages 218 intended for the other party, of course. 220 Note 3 - How the entity sends the certification request to a 221 certification authority is outside the scope of this document. Both 222 paper and electronic forms are possible. 224 Note 4 - This document is not compatible with the certification 225 request syntax for Privacy-Enhanced Mail, as described in RFC 1424 226 [5]. The syntax here differs in three respects: It allows a set of 227 attributes; it does not include issuer name, serial number, or 228 validity period; and it does not require an "innocuous" message to be 229 signed. This document is designed to minimize request size, an 230 important feature for certification authorities accepting requests on 231 paper. 233 4. Certification request syntax 235 This section is divided into two parts. The first part describes the 236 certification-request-information type CertificationRequestInfo, and 237 the second part describes the top-level type CertificationRequest. 239 4.1 CertificationRequestInfo 240 Certification request information shall have ASN.1 type 241 CertificationRequestInfo: 243 CertificationRequestInfo ::= SEQUENCE { 244 version INTEGER { v1(0) } (v1,...), 245 subject Name, 246 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 247 attributes [0] Attributes{{ CRIAttributes }} 248 } 250 SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE { 251 algorithm AlgorithmIdentifier {{IOSet}}, 252 subjectPublicKey BIT STRING 253 } 255 PKInfoAlgorithms ALGORITHM ::= { 256 ... -- add any locally defined algorithms here -- } 258 Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }} 260 CRIAttributes ATTRIBUTE ::= { 261 ... -- add any locally defined attributes here -- } 263 Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { 264 type ATTRIBUTE.&id({IOSet}), 265 values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) 266 } 268 The components of type CertificationRequestInfo have the following 269 meanings: 271 version is the version number, for compatibility with future 272 revisions of this document. It shall be 0 for this version 273 of the standard. 275 subject is the distinguished name of the certificate subject 276 (the entity whose public key is to be certified). 278 subjectPublicKeyInfo contains information about the public key 279 being certified. The information identifies the entity's 280 public-key algorithm (and any associated parameters); 281 examples of public-key algorithms include the rsaEncryption 282 object identifier from PKCS #1 [1]. The information also 283 includes a bit-string representation of the entity's public 284 key. For the public-key algorithm just mentioned, the bit 285 string contains the DER encoding of a value of PKCS #1 type 286 RSAPublicKey. The values of type SubjectPublicKeyInfo{} 287 allowed for subjectPKInfo are constrained to the values 288 specified by the information object set PKInfoAlgorithms, 289 which includes the extension marker (...). Definitions of 290 specific algorithm objects are left to specifications that 291 reference this document. Such specifications will be 292 interoperable with their future versions if any additional 293 algorithm objects are added after the extension marker. 295 attributes is a collection of attributes providing additional 296 information about the subject of the certificate. Some 297 attribute types that might be useful here are defined in 298 PKCS #9. An example is the challenge-password attribute, 299 which specifies a password by which the entity may request 300 certificate revocation. Another example is information to 301 appear in X.509 certificate extensions (e.g. the 302 extensionRequest attribute from PKCS #9). The values of type 303 Attributes{} allowed for attributes are constrained to the 304 values specified by the information object set 305 CRIAttributes. Definitions of specific attribute objects are 306 left to specifications that reference this document. Such 307 specifications will be interoperable with their future 308 versions if any additional attribute objects are added after 309 the extension marker. 311 4.2 CertificationRequest 313 A certification request shall have ASN.1 type CertificationRequest: 315 CertificationRequest ::= SEQUENCE { 316 certificationRequestInfo CertificationRequestInfo, 317 signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }}, 318 signature BIT STRING 319 } 321 AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE { 322 algorithm ALGORITHM.&id({IOSet}), 323 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 324 } 326 SignatureAlgorithms ALGORITHM ::= { 327 ... -- add any locally defined algorithms here -- } 329 The components of type CertificationRequest have the following 330 meanings: 332 certificateRequestInfo is the "certification request 333 information." It is the value being signed. 335 signatureAlgorithm identifies the signature algorithm (and any 336 associated parameters) under which the certification-request 337 information is signed. For example, a specification might 338 include an ALGORITHM object for PKCS #1's 339 md5WithRSAEncryption in the information object set 340 SignatureAlgorithms: 342 SignatureAlgorithms ALGORITHM ::= { 343 ..., 344 { NULL IDENTIFIED BY md5WithRSAEncryption } 345 } 347 signature is the result of signing the certification request 348 information with the certification request subject's private 349 key. 351 The signature process consists of two steps: 353 1. The value of the certificationRequestInfo component is DER 354 encoded, yielding an octet string. 356 2. The result of step 1 is signed with the certification 357 request subject's private key under the specified signature 358 algorithm, yielding a bit string, the signature. 360 Note - An equivalent syntax for CertificationRequest could be 361 written: 363 CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo } 364 (CONSTRAINED BY { -- Verify or sign encoded 365 -- CertificationRequestInfo -- }) 367 EncodedCertificationRequestInfo ::= 368 TYPE-IDENTIFIER.&Type(CertificationRequestInfo) 370 SIGNED { ToBeSigned } ::= SEQUENCE { 371 toBeSigned ToBeSigned, 372 algorithm AlgorithmIdentifier { {SignatureAlgorithms} }, 373 signature BIT STRING 374 } 376 5. Security considerations 378 Security issues are discussed throughout this memo. 380 6. Authors' addresses 382 Magnus Nystr�m 383 RSA Security 384 Box 10704 385 S-121 29 Stockholm 386 Sweden 388 Email: magnus@rsasecurity.com 390 Burt Kaliski 391 RSA Security 392 20 Crosby Drive 393 Bedford, MA 01730 USA 395 Email: bkaliski@rsasecurity.com 397 APPENDICES 399 A. ASN.1 Module 401 This appendix includes all of the ASN.1 type and value definitions 402 contained in this document in the form of the ASN.1 module PKCS-10. 404 PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 405 pkcs-10(10) modules(1) pkcs-10(1)} 407 DEFINITIONS IMPLICIT TAGS ::= 409 BEGIN 411 -- EXPORTS All -- 413 -- All types and values defined in this module are exported for use 414 -- in other ASN.1 modules. 416 IMPORTS 418 informationFramework, authenticationFramework 419 FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1) 420 usefulDefinitions(0) 3} 422 ATTRIBUTE, Name 423 FROM InformationFramework informationFramework 425 ALGORITHM 426 FROM AuthenticationFramework authenticationFramework; 428 -- Certificate requests 429 CertificationRequestInfo ::= SEQUENCE { 430 version INTEGER { v1(0) } (v1,...), 431 subject Name, 432 subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, 433 attributes [0] Attributes{{ CRIAttributes }} 434 } 436 SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE { 437 algorithm AlgorithmIdentifier {{IOSet}}, 438 subjectPublicKey BIT STRING 439 } 441 PKInfoAlgorithms ALGORITHM ::= { 442 ... -- add any locally defined algorithms here -- } 444 Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }} 445 CRIAttributes ATTRIBUTE ::= { 446 ... -- add any locally defined attributes here -- } 448 Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { 449 type ATTRIBUTE.&id({IOSet}), 450 values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) 451 } 453 CertificationRequest ::= SEQUENCE { 454 certificationRequestInfo CertificationRequestInfo, 455 signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }}, 456 signature BIT STRING 457 } 459 AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE { 460 algorithm ALGORITHM.&id({IOSet}), 461 parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL 462 } 464 SignatureAlgorithms ALGORITHM ::= { 465 ... -- add any locally defined algorithms here -- } 467 END 469 B. Intellectual property considerations 471 RSA Security makes no patent claims on the general constructions 472 described in this document, although specific underlying techniques 473 may be covered. 475 License to copy this document is granted provided that it is 476 identified as "RSA Security Inc. Public-Key Cryptography Standards 477 (PKCS)" in all material mentioning or referencing this document. 479 RSA Security makes no representations regarding intellectual property 480 claims by other parties. Such determination is the responsibility of 481 the user. 483 C. Revision history 485 Version 1.0 487 Version 1.0 was the previous version of this document (also 488 published as "version 1.5" in [6]). 490 Version 1.7 492 This version incorporates several editorial changes, including 493 updates to the references, and changes to ASN.1 type 494 definitions. The following substantive changes have been made: 496 - This version refers to X.680-X.690, the current international 497 standards for ASN.1 and its encoding rules. All references to 498 X.208 and X.209 have been eliminated. 500 - The X.690 standard requires that the encoded values of SET OF 501 components be sorted in ascending order under DER. Regardless 502 of this, applications should not rely on the ordering of 503 attribute components. 505 - All references to PKCS #6 Extended-Certificate Syntax Standard 506 have been removed. With the addition of extensions to X.509 507 version 3 certificates, RSA Laboratories is withdrawing 508 support for PKCS #6. 510 Note - The reason for using version 1.7 for this document is to avoid 511 confusion with [6], which is named version 1.5, and an unsupported 512 PKCS #10 version named Version 1.6. 514 D. References 516 [1] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0, 517 October 1998. 519 [2] RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard. 520 Version 1.5, November 1993. 522 [3] RSA Laboratories. PKCS #9: Selected Attribute Types. Version 2.0, 523 February 2000. 525 [4] C. Adams, S. Farrell. RFC 2510: Internet X.509 Public Key 526 Infrastructure - Certificate Management Protocols. March 1999. 528 [5] B. Kaliski. RFC 1424: Privacy Enhancement for Internet Electronic 529 Mail: Part IV: Key Certification and Related Services. February 1993. 531 [6] B. Kaliski. RFC 2314: PKCS #10: Certification Request Syntax 532 Version 1.5. March 1998. 534 [7] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998, 535 Information technology - Open Systems Interconnection - The 536 Directory: Overview of concepts, models and services. 538 [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995, 539 Information technology - Open Systems Interconnection - The 540 Directory: Models. 542 [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, 543 Information technology - Open Systems Interconnection -The Directory: 544 Authentication framework. 546 [10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, 547 Information Technology - Abstract Syntax Notation One (ASN.1): 548 Specification of Basic Notation. 550 [11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, 551 Information Technology - Abstract Syntax Notation One (ASN.1): 552 Information Object Specification. 554 [12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, 555 Information Technology - Abstract Syntax Notation One (ASN.1): 556 Constraint Specification. 558 [13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, 559 Information Technology - Abstract Syntax Notation One (ASN.1): 560 Parameterization of ASN.1 Specifications. 562 [14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, 563 Information Technology - ASN.1 Encoding Rules: Specification of Basic 564 Encoding Rules (BER), Canonical Encoding Rules (CER) and 565 Distinguished Encoding Rules (DER). 567 E. Contact Information & About PKCS 569 The Public-Key Cryptography Standards are specifications produced by 570 RSA Laboratories in cooperation with secure systems developers 571 worldwide for the purpose of accelerating the deployment of public- 572 key cryptography. First published in 1991 as a result of meetings 573 with a small group of early adopters of public-key technology, the 574 PKCS documents have become widely referenced and implemented. 575 Contributions from the PKCS series have become part of many formal 576 and de facto standards, including ANSI X9 documents, PKIX, SET, 577 S/MIME, and SSL. 579 Further development of PKCS occurs through mailing list discussions 580 and occasional workshops, and suggestions for improvement are 581 welcome. For more information, contact: 583 PKCS Editor 584 RSA Laboratories 585 20 Crosby Drive 586 Bedford, MA 01730 USA 587 pkcs-editor@rsasecurity.com 588 http://www.rsasecurity.com/rsalabs/pkcs