idnits 2.17.1 draft-hoffman-pkcs-certif-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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. 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 (March 16, 1998) is 9532 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 section? '0' on line 244 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Burt Kaliski 2 Expires March 16, 1998 3 5 PKCS #10: Certification Request Syntax 6 Version 1.5 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 This memo provides information for the Internet community. This memo 27 does not specify an Internet standard of any kind. Distribution of 28 this memo is unlimited. 30 Overview 32 This document describes a syntax for certification requests. 34 1. Scope 36 A certification request consists of a distinguished name, a public 37 key, and optionally a set of attributes, collectively signed by the 38 entity requesting certification. Certification requests are sent to a 39 certification authority, who transforms the request to an X.509 40 public-key certificate, or a PKCS #6 extended certificate. (In what 41 form the certification authority returns the newly signed certificate 42 is outside the scope of this document. A PKCS #7 message is one 43 possibility.) 45 The intention of including a set of attributes is twofold: to provide 46 other information about a given entity, such as the postal address to 47 which the signed certificate should be returned if electronic mail is 48 not available, or a "challenge password" by which the entity may 50 RFC nnn PKCS #10: Certification Request Syntax November 1993 52 later request certificate revocation; and to provide attributes for a 53 PKCS #6 extended certificate. A non-exhaustive list of attributes is 54 given in PKCS #9. 56 Certification authorities may also require non-electronic forms of 57 request and may return non-electronic replies. It is expected that 58 descriptions of such forms, which are outside the scope of this 59 document, will be available from the certification authority. 61 The preliminary intended application of this document is to support 62 PKCS #7 cryptographic messages, but is expected that other 63 applications will be developed. 65 2. References 67 PKCS #1 RSA Laboratories. PKCS #1: RSA Encryption 68 Standard. Version 1.5, November 1993. 70 PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate 71 Syntax. Version 1.5, November 1993. 73 PKCS #7 RSA Laboratories. PKCS #7: Cryptographic Message 74 Syntax. Version 1.5, November 1993. 76 PKCS #9 RSA Laboratories. PKCS #9: Selected Attribute 77 Types. Version 1.1, November 1993. 79 RFC 1424 B. Kaliski. RFC 1424: Privacy Enhancement for 80 Internet Electronic Mail: Part IV: Key 81 Certification and Related Services. February 1993. 83 X.208 CCITT. Recommendation X.208: Specification of 84 Abstract Syntax Notation One (ASN.1). 1988. 86 X.209 CCITT. Recommendation X.209: Specification of 87 Basic Encoding Rules for Abstract Syntax Notation 88 One (ASN.1). 1988. 90 X.500 CCITT. Recommendation X.500: The Directory-- 91 Overview of Concepts, Models and 92 Services. 1988. 94 X.501 CCITT. Recommendation X.501: The Directory-- 95 Models. 1988. 97 X.509 CCITT. Recommendation X.509: The Directory-- 98 Authentication Framework. 1988. 100 RFC nnn PKCS #10: Certification Request Syntax November 1993 102 3. Definitions 104 For the purposes of this document, the following definitions apply. 106 AlgorithmIdentifier: A type that identifies an algorithm (by object 107 identifier) and any associated parameters. This type is defined in 108 X.509. 110 Attribute: A type that contains an attribute type (specified by 111 object identifier) and one or more attribute values. This type is 112 defined in X.501. 114 ASN.1: Abstract Syntax Notation One, as defined in X.208. 116 BER: Basic Encoding Rules, as defined in X.209. 118 Certificate: A type that binds an entity's distinguished name to a 119 public key with a digital signature. This type is defined in X.509. 120 This type also contains the distinguished name of the certificate 121 issuer (the signer), an issuer- specific serial number, the issuer's 122 signature algorithm identifier, and a validity period. 124 DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, 125 Section 8.7. 127 Name: A type that uniquely identifies or "distinguishes" objects in a 128 X.500 directory. This type is defined in X.501. In an X.509 129 certificate, the type identifies the certificate issuer and the 130 entity whose public key is certified. 132 4. Symbols and abbreviations 134 No symbols or abbreviations are defined in this document. 136 5. General overview 138 The next section specifies certification request syntax. 140 This document exports one type, CertificationRequest. 142 6. Certification request syntax 144 This section gives the syntax for certification requests. 146 A certification request consists of three parts: "certification 147 request information," a signature algorithm identifier, and a digital 148 signature on the certification request information. The certification 149 request information consists of the entity's distinguished name, the 151 RFC nnn PKCS #10: Certification Request Syntax November 1993 153 entity's public key, and a set of attributes providing other 154 information about the entity. 156 The process by which a certification request is constructed involves 157 the following steps: 159 1. A CertificationRequestInfo value containing a 160 distinguished name, a public key, and optionally a 161 set of attributes is constructed by an entity. 163 2. The CertificationRequestInfo value is signed with 164 the entity's private key. (See Section 6.2.) 166 3. The CertificationRequestInfo value, a signature 167 algorithm identifier, and the entity's signature 168 are collected together into a CertificationRequest 169 value, defined below. 171 A certification authority fulfills the request by verifying the 172 entity's signature, and, if it is valid, constructing a X.509 173 certificate from the distinguished name and public key, as well as an 174 issuer name, serial number, validity period, and signature algorithm 175 of the certification authority's choice. If the certification request 176 contains a PKCS #9 extended-certificate-attributes attribute, the 177 certification authority also constructs a PKCS #6 extended 178 certificate from the X.509 certificate and the extended- certificate- 179 attributes attribute value. 181 In what form the certification authority returns the new certificate 182 is outside the scope of this document. One possibility is a PKCS #7 183 cryptographic message with content type signedData, following the 184 degenerate case where there are no signers. The return message may 185 include a certification path from the new certificate to the 186 certification authority. It may also include other certificates such 187 as cross-certificates that the certification authority considers 188 helpful, and it may include certificate-revocation lists (CRLs). 189 Another possibility is that the certification authority inserts the 190 new certificate into a central database. 192 This section is divided into two parts. The first part describes the 193 certification-request-information type CertificationRequestInfo, and 194 the second part describes the top-level type CertificationRequest. 196 Notes. 198 1. An entity would typically send a certification 199 request after generating a public-key/private-key 201 RFC nnn PKCS #10: Certification Request Syntax November 1993 203 pair, but may also do so after a change in the 204 entity's distinguished name. 206 2. The signature on the certification request 207 prevents an entity from requesting a certificate 208 with another party's public key. Such an attack 209 would give the entity the minor ability to pretend 210 to be the originator of any message signed by the 211 other party. This attack is significant only if 212 the entity does not know the message being signed, 213 and the signed part of the message does not 214 identify the signer. The entity would still not be 215 able to decrypt messages intended for the other 216 party, of course. 218 3. How the entity sends the certification request to 219 a certification authority is outside the scope of 220 this document. Both paper and electronic forms are 221 possible. 223 4. This document is not compatible with the 224 certification request syntax for Privacy-Enhanced 225 Mail, as described in RFC 1424. The syntax in this 226 document differs in three respects: It allows a 227 set of attributes; it does not include issuer 228 name, serial number, or validity period; and it 229 does not require an "innocuous" message to be 230 signed. The syntax in this document is designed to 231 minimize request size, an important constraint for 232 those certification authorities accepting requests 233 on paper. 235 6.1 CertificationRequestInfo 237 Certification request information shall have ASN.1 type 238 CertificationRequestInfo: 240 CertificationRequestInfo ::= SEQUENCE { 241 version Version, 242 subject Name, 243 subjectPublicKeyInfo SubjectPublicKeyInfo, 244 attributes [0] IMPLICIT Attributes } 246 Version ::= INTEGER 248 Attributes ::= SET OF Attribute 250 The fields of type CertificationRequestInfo have the following 252 RFC nnn PKCS #10: Certification Request Syntax November 1993 254 meanings: 256 o version is the version number, for compatibility 257 with future revisions of this document. It shall 258 be 0 for this version of the document. 260 o subject is the distinguished name of the 261 certificate subject (the entity whose public key 262 is to be certified). 264 o subjectPublicKeyInfo contains information about 265 the public key being certified. The information 266 identifies the entity's public-key algorithm (and 267 any associated parameters); examples of public-key 268 algorithms include X.509's rsa and PKCS #1's 269 rsaEncryption. The information also includes a bit- 270 string representation of the entity's public key. 271 For both public-key algorithms just mentioned, the 272 bit string contains the BER encoding of a value of 273 X.509/PKCS #1 type RSAPublicKey. 275 o attributes is a set of attributes providing 276 additional information about the subject of the 277 certificate. Some attribute types that might be 278 useful here are defined in PKCS #9. An example is 279 the challenge-password attribute, which specifies 280 a password by which the entity may request that 281 the certificate revocation. Another example is the 282 extended-certificate-attributes attribute, which 283 specifies attributes for a PKCS #6 extended 284 certificate. 286 6.2 CertificationRequest 288 A certification request shall have ASN.1 type CertificationRequest: 290 CertificationRequest ::= SEQUENCE { 291 certificationRequestInfo CertificationRequestInfo, 292 signatureAlgorithm SignatureAlgorithmIdentifier, 293 signature Signature } 295 SignatureAlgorithmIdentifier ::= AlgorithmIdentifier 297 Signature ::= BIT STRING 299 The fields of type CertificationRequest have the following meanings: 301 o certificateRequestInfo is the "certification 303 RFC nnn PKCS #10: Certification Request Syntax November 1993 305 request information." It is the value being 306 signed. 308 o signatureAlgorithm identifies the signature 309 algorithm (and any associated parameters) under 310 which the certification-request information is 311 signed. Examples include PKCS #1's 312 md2WithRSAEncryption and md5WithRSAEncryption. 314 o signature is the result of signing the 315 certification request information with the 316 certification request subject's private key. 318 The signature process consists of two steps: 320 1. The value of the certificationRequestInfo field is 321 DER encoded, yielding an octet string. 323 2. The result of step 1 is signed with the 324 certification request subject's private key under 325 the specified signature algorithm, yielding a bit 326 string, the signature. 328 Note. The syntax for CertificationRequest could equivalently be 329 written with the X.509 SIGNED macro: 331 CertificationRequest ::= SIGNED CertificateRequestInfo 333 Revision history 335 Version 1.0 337 Version 1.0 is the initial version. 339 Copyright 341 Copyright (c) 1991-1993 RSA Laboratories, a division of RSA Data 342 Security, Inc. Any substantial use of the text from this document 343 must acknowledge RSA Data Security, Inc. RSA Data Security, Inc. 344 requests that all material mentioning or referencing this document 345 identify this as "RSA Data Security, Inc. PKCS #10". 347 Author's Address 349 Burt Kaliski 350 RSA Laboratories East 351 20 Crosby Drive 353 RFC nnn PKCS #10: Certification Request Syntax November 1993 355 Bedford, MA 01730 356 (617) 687-7000 357 burt@rsa.com