idnits 2.17.1 draft-ietf-pkix-opp-ftp-http-04.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-19) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 1, 1998) is 9424 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) == Unused Reference: 'RFC 959' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC 1738' is defined on line 269, but no explicit reference was found in the text == Unused Reference: 'RFC 2068' is defined on line 272, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley, SPYRUS 3 Internet Draft P. Hoffman, IMC 4 expires in six months July 1, 1998 6 Internet X.509 Public Key Infrastructure 8 Operational Protocols: FTP and HTTP 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 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 To view the entire list of current Internet-Drafts, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 27 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 30 Abstract 32 The protocol conventions described in this document satisfy some of 33 the operational requirements of the Internet Public Key 34 Infrastructure (PKI). This document specifies the conventions for 35 using the File Transfer Protocol (FTP) and the Hypertext Transfer 36 Protocol (HTTP) to obtain certificates and certificate revocation 37 lists (CRLs) from PKI repositories. Additional mechanisms addressing 38 PKIX operational requirements are specified in separate documents. 40 Please send comments on this document to the ietf-pkix@imc.org mail 41 list. 43 1 Introduction 45 This specification is part of a multi-part standard for the Internet 46 Public Key Infrastructure (PKI) using X.509 certificates and 47 certificate revocation lists (CRLs). This document specifies the 48 conventions for using the File Transfer Protocol (FTP) and the 49 Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs 50 from PKI repositories. Additional mechanisms addressing PKI 51 repository access are specified in separate documents. 53 1.1. Model 55 The following is a simplified view of the architectural model assumed 56 by the Internet PKI specifications. 58 +---+ 59 | C | +------------+ 60 | e | <-------------------->| End entity | 61 | r | Operational +------------+ 62 | t | transactions ^ 63 | | and management | Management 64 | / | transactions | transactions 65 | | | PKI users 66 | C | v 67 | R | -------------------+--+-----------+----------------- 68 | L | ^ ^ 69 | | | | PKI management 70 | | v | entities 71 | R | +------+ | 72 | e | <---------------------| RA | <---+ | 73 | p | Publish certificate +------+ | | 74 | o | | | 75 | s | | | 76 | I | v v 77 | t | +------------+ 78 | o | <------------------------------| CA | 79 | r | Publish certificate +------------+ 80 | y | Publish CRL ^ 81 | | | 82 +---+ Management | 83 transactions | 84 v 85 +------+ 86 | CA | 87 +------+ 89 The components in this model are: 91 End Entity: user of PKI certificates and/or end user system that 92 is the subject of a certificate; 94 CA: certification authority; 95 RA: registration authority, i.e., an optional system to 96 which a CA delegates certain management functions; 98 Repository: a system or collection of distributed systems that 99 store certificates and CRLs and serves as a means of 100 distributing these certificates and CRLs to end 101 entities. 103 1.2. Certificate and CRL Repository 105 Some CAs mandate the use of on-line validation services, while others 106 distribute CRLs to allow certificate users to perform certificate 107 validation themselves. In general, CAs make CRLs available to 108 certificate users by publishing them in the Directory. The Directory 109 is also the normal distribution mechanism for certificates. However, 110 Directory Services are not available in many parts of the Internet 111 today. The File Transfer Protocol (FTP) defined in RFC 959 and the 112 Hypertext Transfer Protocol (HTTP) defined in RFC 2068 offer 113 alternate methods for certificate and CRL distribution. 115 End entities and CAs may retrieve certificates and CRLs from the 116 repository using FTP or HTTP. End entities may publish their own 117 certificate in the repository using FTP or HTTP, and RAs and CAs may 118 publish certificates and CRLs in the repository using FTP or HTTP. 120 2 FTP Conventions 122 Within certificate extensions and CRL extensions, the URI form of 123 GeneralName is used to specify the location where issuer certificates 124 and CRLs may be obtained. For instance, a URI identifying the 125 subject of a certificate may be carried in subjectAltName certificate 126 extension. An IA5String describes the use of anonymous FTP to fetch 127 certificate or CRL information. For example: 129 ftp://ftp.netcom.com/sp/spyrus/housley.cer 130 ftp://ftp.your.org/pki/id48.cer 131 ftp://ftp.your.org/pki/id48.no42.crl 133 Internet users may publish the URI reference to a file that contains 134 their certificate on their business card. This practice is useful 135 when there is no Directory entry for that user. FTP is widely 136 deployed, and anonymous FTP are accommodated by many firewalls. 137 Thus, FTP is an attractive alternative to Directory access protocols 138 for certificate and CRL distribution. While this service satisfies 139 the requirement to retrieve information related to a certificate 140 which is already identified by a URI, it is not intended to satisfy 141 the more general problem of finding a certificate for a user about 142 whom some other information, such as their electronic mail address or 143 corporate affiliation, is known. 145 For convenience, the names of files that contain certificates should 146 have a suffix of ".cer". Each ".cer" file contains exactly one 147 certificate, encoded in DER format. Likewise, the names of files 148 that contain CRLs should have a suffix of ".crl". Each ".crl" file 149 contains exactly one CRL, encoded in DER format. 151 3 HTTP Conventions 153 Within certificate extensions and CRL extensions, the URI form of 154 GeneralName is used to specify the location where issuer certificates 155 and CRLs may be obtained. For instance, a URI identifying the 156 subject of a certificate may be carried in subjectAltName certificate 157 extension. An IA5String describes the use of HTTP to fetch 158 certificate or CRL information. For example: 160 http://www.netcom.com/sp/spyrus/housley.cer 161 http://www.your.org/pki/id48.cer 162 http://www.your.org/pki/id48.no42.crl 164 Internet users may publish the URI reference to a file that contains 165 their certificate on their business card. This practice is useful 166 when there is no Directory entry for that user. HTTP is widely 167 deployed, and HTTP is accommodated by many firewalls. Thus, HTTP is 168 an attractive alternative to Directory access protocols for 169 certificate and CRL distribution. While this service satisfies the 170 requirement to retrieve information related to a certificate which is 171 already identified by a URI, it is not intended to satisfy the more 172 general problem of finding a certificate for a user about whom some 173 other information, such as their electronic mail address or corporate 174 affiliation, is known. 176 For convenience, the names of files that contain certificates should 177 have a suffix of ".cer". Each ".cer" file contains exactly one 178 certificate, encoded in DER format. Likewise, the names of files 179 that contain CRLs should have a suffix of ".crl". Each ".crl" file 180 contains exactly one CRL, encoded in DER format. 182 4 MIME registrations 184 Two MIME types are defined to support the transfer of certificates 185 and CRLs. They are: 187 application/pkix-cert 188 application/pkix-crl 190 4.1. application/pkix-cert 192 To: ietf-types@iana.org 193 Subject: Registration of MIME media type application/pkix-cert 195 MIME media type name: application 197 MIME subtype name: pkix-cert 199 Required parameters: None 201 Optional parameters: version (default value is "1") 203 Encoding considerations: will be none for 8-bit transports and most likely 204 Base64 for SMTP or other 7-bit transports 206 Security considerations: Carries a cryptographic certificate 208 Interoperability considerations: None 210 Published specification: draft-ietf-pkix-ipki-part1 212 Applications which use this media type: Any MIME-complaint transport 214 Additional information: 215 Magic number(s): None 216 File extension(s): .CER 217 Macintosh File Type Code(s): none 219 Person & email address to contact for further information: 220 Russ Housley 222 Intended usage: COMMON 224 Author/Change controller: 225 Russ Housley 227 4.2. application/pkix-crl 229 To: ietf-types@iana.org 230 Subject: Registration of MIME media type application/pkix-crl 232 MIME media type name: application 234 MIME subtype name: pkix-crl 236 Required parameters: None 237 Optional parameters: version (default value is "1") 239 Encoding considerations: will be none for 8-bit transports and most likely 240 Base64 for SMTP or other 7-bit transports 242 Security considerations: Carries a cryptographic certificate revocation 243 list 245 Interoperability considerations: None 247 Published specification: draft-ietf-pkix-ipki-part1 249 Applications which use this media type: Any MIME-complaint transport 251 Additional information: 252 Magic number(s): None 253 File extension(s): .CRL 254 Macintosh File Type Code(s): none 256 Person & email address to contact for further information: 257 Russ Housley 259 Intended usage: COMMON 261 Author/Change controller: 262 Russ Housley 264 References 266 [RFC 959] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)," 267 RFC 959, October 1985. 269 [RFC 1738] T. Berners-Lee, L. Masinter, and M. McCahill, "Uniform 270 Resource Locators (URL)," December 1994. 272 [RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and 273 T. Berners-Lee; "Hypertext Transfer Protocol -- HTTP/1.1," 274 RFC 2068, January 1997. 276 Security Considerations 278 Since certificates and CRLs are digitally signed, no additional 279 integrity service is necessary. Neither certificates nor CRLs need 280 be kept secret, and anonymous access to certificates and CRLs is 281 generally acceptable. Thus, no privacy service is necessary. 283 HTTP caching proxies are common on the Internet, and some proxies do 284 not check for the latest version of an object correctly. If an HTTP 285 request for a certificate or CRL goes through a misconfigured or 286 otherwise broken proxy, the proxy may return an out-of-date response. 288 Operators of FTP sites and World Wide Web servers should authenticate 289 end entities who publish certificates as well as CAs and RAs who 290 publish certificates and CRLs. However, authentication is not 291 necessary to retrieve certificates and CRLs. 293 Author Addresses 295 Russell Housley 296 SPYRUS 297 381 Elden Street, Suite 1120 298 Herndon, VA 20170 USA 299 housley@spyrus.com 301 Paul Hoffman 302 Internet Mail Consortium 303 127 Segre Place 304 Santa Cruz, CA 95060 USA 305 phoffman@imc.org