idnits 2.17.1 draft-ietf-pem-forms-01.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-26) 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (1 September 1992) is 11560 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'FORMS-ID' on line 3 -- Looks like a reference, but probably isn't: '1-3' on line 46 == Unused Reference: '1' is defined on line 332, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 336, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 339, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Kaliski 3 INTERNET-DRAFT [FORMS-ID] RSA Laboratories 4 1 September 1992 6 Privacy Enhancement for Internet Electronic Mail: 7 Part IV: Key Certification and Related Services 9 STATUS OF THIS MEMO 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 This draft document will be submitted to the RFC editor as a 27 standards document. References within the text of this Internet Draft 28 to this document as an RFC, or to related Internet Drafts cited as 29 "RFC [1113+]", "RFC [1114+]", and "RFC [1115+]" are not intended to 30 carry any connotation about the progression of these Internet Drafts 31 through the IAB standards-track review cycle. Distribution of this 32 memo is unlimited. Comments should be sent to . 34 ACKNOWLEDGEMENT 36 This document is the product of many discussions at RSA Data 37 Security, at Trusted Information Systems, and on the mailing list. Contributors include Dave Balenson, Jim 39 Bidzos, Pat Cain, Vint Cerf, Pam Cochrane, Steve Dusse, Jeff Fassett, 40 Craig Finseth, Jim Galvin, Mike Indovina, Bob Jueneman, Steve Kent, 41 John Lowry, Paul McKenney, Jeff Thompson, and Charles Wu. 43 1. Executive Summary 45 This document describes three types of service in support of Internet 46 Privacy-Enhanced Mail (PEM) [1-3]: key certification, certificate- 47 revocation list (CRL) storage, and CRL retrieval. Such services are 48 among those required of an RFC [1114+] certification authority. Other 49 services such as certificate revocation and certificate retrieval are 50 left to the certification authority to define, although they may be 51 based on the services described in this document. 53 Each service involves an electronic-mail request and an electronic- 54 mail reply. The request is either an RFC [1113+] privacy-enhanced 55 message or a message with a new syntax defined in this document. The 56 new syntax follows the general RFC [1113+] syntax but has a different 57 process type, thereby distinguishing it from ordinary privacy- 58 enhanced messages. The reply is either an RFC [1113+] privacy- 59 enhanced message, or an ordinary unstructured message. 61 Replies that are privacy-enhanced messages can be processed like any 62 other privacy-enhanced message, so that the new certificate or the 63 retrieved CRLs can be inserted into the requestor's database during 64 normal privacy-enhanced mail processing. 66 Certification authorities may also require non-electronic forms of 67 request and may return non-electronic replies. It is expected that 68 descriptions of such forms, which are outside the scope of this 69 document, will be available through a certification authority's 70 "information" service. 72 2. Overview of Services 74 This section describes the three services in general terms. 76 The electronic-mail address to which requests are sent is left to the 77 certification authority to specify. It is expected that certification 78 authorities will advertise their addresses as part of an 79 "information" service. Replies are sent to the address in the "Reply- 80 To:" field of the request, and if that field is omitted, to the 81 address in the "From:" field. 83 2.1 Key Certification 85 The key-certification service signs a certificate containing a 86 specified subject name and public key. The service takes a 87 certification request (see Section 3.1), signs a certificate 88 constructed from the request, and returns a certification reply (see 89 Section 3.2) containing the new certificate. 91 The certification request specifies the requestor's subject name and 92 public key in the form of a self-signed certificate. The 93 certification request contains two signatures, both computed with the 94 requestor's private key: 96 1. The signature on the self-signed certificate, having the 97 cryptographic purpose of preventing a requestor from 98 requesting a certificate with another party's public key. 99 (See Section 4.) 101 2. A signature on some encapsulated text, having the 102 practical purpose of allowing the certification authority 103 to construct an ordinary RFC [1113+] privacy-enhanced 104 message as a reply, with user-friendly encapsulated text. 105 (RFC [1113+] does not provide for messages with 106 certificates but no encapsulated text; and the self- 107 signed certificate is not "user friendly" text.) The text 108 should be something innocuous like "Hello world!" 110 A requestor would typically send a certification request after 111 generating a public-key/private-key pair, but may also do so after a 112 change in the requestor's distinguished name. 114 A certification authority signs a certificate only if both signatures 115 in the certification request are valid. 117 The new certificate contains the subject name and public key from the 118 self-signed certificate, and an issuer name, serial number, validity 119 period, and signature algorithm of the certification authority's 120 choice. (The validity period may be derived from the self-signed 121 certificate.) Following RFC [1114+], the issuer may be any whose 122 distinguished name is superior to the subject's distinguished name, 123 typically the one closest to the subject. The certification authority 124 signs the certificate with the issuer's private key, then transforms 125 the request into a reply containing the new certificate (see Section 126 3.2 for details). 128 The certification reply includes a certification path from the new 129 certificate to the RFC [1114+] Internet certification authority. It 130 may also include other certificates such as cross-certificates that 131 the certification authority considers helpful to the requestor. 133 2.2 CRL Storage 135 The CRL storage service stores CRLs. The service takes a CRL-storage 136 request (see Section 3.3) specifying the CRLs to be stored, stores 137 the CRLs, and returns a CRL-storage reply (see Section 3.4) 138 acknowledging the request. 140 The certification authority stores a CRL only if its signature and 141 certification path are valid, following concepts in RFC [1114+]. 142 (Although a certification path is not required in a CRL-storage 143 request, it may help the certification authority validate the CRL.) 145 2.3 CRL Retrieval 147 The CRL retrieval service retrieves the latest CRLs of specified 148 certificate issuers. The service takes a CRL-retrieval request (see 149 Section 3.5), retrieves the latest CRLs the request specifies, and 150 returns a CRL-retrieval reply (see Section 3.6) containing the CRLs. 152 There may be more than one "latest" CRL for a given issuer, if that 153 issuer has more than one public key (see RFC [1114+] for details). 155 The CRL-retrieval reply includes a certification path from each 156 retrieved CRL to the RFC [1114+] Internet certification authority. It 157 may also include other certificates such as cross-certificates that 158 the certification authority considers helpful to the requestor. 160 3. Syntax 162 This section describes the syntax of requests and replies for the 163 three services, giving simple examples. 165 3.1 Certification request 167 A certification request is an RFC [1113+] MIC-ONLY or MIC-CLEAR 168 privacy-enhanced message containing a self-signed certificate. There 169 is only one signer. 171 The fields of the self-signed certificate (which has type 172 Certificate, as in RFC [1114+]) are as follows: 174 version is 0 176 serialNumber is arbitrary; the value 0 is suggested unless the 177 certification authority specifies otherwise 179 signature is the algorithm by which the self-signed 180 certificate is signed; it need not be the same as the 181 algorithm by which the requested certificate is to be 182 signed 184 issuer is the requestor's distinguished name 185 validity is arbitrary; the value with start and end both at 186 12:00am GMT, January 1, 1970, is suggested unless the 187 certification authority specifies otherwise 189 subject is the requestor's distinguished name 191 subjectPublicKeyInfo is the requestor's public key 193 The requestor's MIC encryption algorithm must be asymmetric (e.g., 194 RSA) and the MIC algorithm must be keyless (e.g., RSA-MD2, not MAC), 195 so that anyone can verify the signature. 197 Example: 199 To: cert-service@ca.domain 200 From: requestor@host.domain 202 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 203 Proc-Type: 4,MIC-ONLY 204 Content-Domain: RFC822 205 Originator-Certificate: 206 MIC-Info: RSA,RSA-MD2, 208 209 -----END PRIVACY-ENHANCED MESSAGE----- 211 3.2 Certification reply 213 A certification reply is an RFC [1113+] MIC-ONLY or MIC-CLEAR privacy- 214 enhanced message containing a new certificate, its certification path 215 to the RFC [1114+] Internet certification authority, and possibly 216 other certificates. There is only one signer. The "MIC-Info:" field 217 and encapsulated text are taken directly from the certification 218 request. The reply has the same process type (MIC-ONLY or MIC-CLEAR) 219 as the request. 221 Since the reply is an ordinary privacy-enhanced message, the new 222 certificate can be inserted into the requestor's database during 223 normal privacy-enhanced mail processing. The requestor can forward 224 the reply to other requestors to disseminate the certificate. 226 Example: 228 To: requestor@host.domain 229 From: cert-service@ca.domain 231 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 232 Proc-Type: 4,MIC-ONLY 233 Content-Domain: RFC822 234 Originator-Certificate: 235 Issuer-Certificate: 236 MIC-Info: RSA,RSA-MD2, 238 239 -----END PRIVACY-ENHANCED MESSAGE----- 241 3.3 CRL-storage request 243 A CRL-storage request is an RFC [1113+] CRL-type privacy-enhanced 244 message containing the CRLs to be stored and optionally their 245 certification paths to the RFC [1114+] Internet certification 246 authority. 248 Example: 250 To: cert-service@ca.domain 251 From: requestor@host.domain 253 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 254 Proc-Type: 4,CRL 255 CRL: 256 Originator-Certificate: 257 CRL: 258 Originator-Certificate: 259 -----END PRIVACY-ENHANCED MESSAGE----- 261 3.4 CRL-storage reply 263 A CRL-storage reply is an ordinary message acknowledging the storage 264 of CRLs. No particular syntax is specified. 266 3.5 CRL-retrieval request 268 A CRL-retrieval request is a new type of privacy-enhanced message, 269 distinguished from RFC [1113+] privacy-enhanced messages by the 270 process type CRL-RETRIEVAL-REQUEST. 272 The request has two or more encapsulated header fields: the required 273 "Proc-Type:" field and one or more "Issuer:" fields. The fields must 274 appear in the order just described. There is no encapsulated text, so 275 there is no blank line separating the fields from encapsulated text. 277 Each "Issuer:" field specifies an issuer whose latest CRL is to be 278 retrieved. The field contains a value of type Name specifying the 279 issuer's distinguished name. The value is encoded as in an RFC 280 [1113+] "Originator-ID-Asymmetric:" field (i.e., according to the 281 Basic Encoding Rules, then in ASCII). 283 Example: 285 To: cert-service@ca.domain 286 From: requestor@host.domain 288 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 289 Proc-Type: 4,CRL-RETRIEVAL-REQUEST 290 Issuer: 291 Issuer: 292 -----END PRIVACY-ENHANCED MESSAGE----- 294 3.6 CRL-retrieval reply 296 A CRL-retrieval reply is an RFC [1113+] CRL-type privacy-enhanced 297 message containing retrieved CRLs, their certification paths to the 298 RFC [1114+] Internet certification authority, and possibly other 299 certificates. 301 Since the reply is an ordinary privacy-enhanced message, the 302 retrieved CRLs can be inserted into the requestor's database during 303 normal privacy-enhanced mail processing. The requestor can forward 304 the reply to other requestors to disseminate the CRLs. 306 Example: 308 To: requestor@host.domain 309 From: cert-service@ca.domain 311 -----BEGIN PRIVACY-ENHANCED MESSAGE----- 312 Proc-Type: 4,CRL 313 CRL: 314 Originator-Certificate: 315 CRL: 316 Originator-Certificate: 317 -----END PRIVACY-ENHANCED MESSAGE----- 319 4. Security Considerations 321 The self-signed certificate (Section 3.1) prevents a requestor from 322 requesting a certificate with another party's public key. Such an 323 attack would give the requestor the minor ability to pretend to be 324 the originator of any message signed by the other party. This attack 325 is significant only if the requestor does not know the message being 326 signed, and the signed part of the message does not identify the 327 signer. The requestor would still not be able to decrypt messages 328 intended for the other party, of course. 330 References 332 [1] RFC [1113+], Privacy Enhancement for Internet Electronic Mail: 333 Part I: Message Encryption and Authentication Procedures, J. 334 Linn, ?, 1992. 336 [2] RFC [1114+], Privacy Enhancement for Internet Electronic Mail: 337 Part II: Certificate-Based Key Management, S. Kent, ?, 1992. 339 [3] RFC [1115+], Privacy Enhancement for Internet Electronic Mail: 340 Part III: Algorithms, Modes, and Identifiers, D. Balenson, ?, 341 1992. 343 Author's Address 345 Burton S. Kaliski Jr. 346 RSA Laboratories (a division of RSA Data Security, Inc.) 347 10 Twin Dolphin Drive 348 Redwood City, CA 94065 350 Phone: (415) 595-7703 351 FAX: (415) 595-4126 352 EMail: burt@rsa.com