idnits 2.17.1 draft-ietf-dnssec-certs-03.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-25) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-certs-03.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-certs-03.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-certs-03.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-certs-03.txt,', but the file name used is 'draft-ietf-dnssec-certs-03' == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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 (May 1999) is 9112 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? 'RFC2119' on line 91 looks like a reference -- Missing reference section? 'RFC 1738' on line 160 looks like a reference -- Missing reference section? '0' on line 242 looks like a reference -- Missing reference section? '1' on line 243 looks like a reference -- Missing reference section? '2' on line 244 looks like a reference -- Missing reference section? '3' on line 245 looks like a reference -- Missing reference section? '4' on line 246 looks like a reference -- Missing reference section? '5' on line 247 looks like a reference -- Missing reference section? '6' on line 248 looks like a reference -- Missing reference section? '7' on line 249 looks like a reference -- Missing reference section? '8' on line 250 looks like a reference -- Missing reference section? 'RFC 1991' on line 291 looks like a reference Summary: 9 errors (**), 1 flaw (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT CERTs in the DNS 2 November 1998 3 Expires May 1999 5 Storing Certificates in the Domain Name System (DNS) 6 ------- ------------ -- --- ------ ---- ------ ----- 8 Donald E. Eastlake 3rd, Olafur Gudmundsson 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-certs-03.txt, is intended to 13 become a Proposed Standard RFC. Distribution of this document is 14 unlimited. Comments should be sent to the DNSSEC mailing list or to the authors. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 [changes from previous draft: update author info, add RFC 2119 35 reference, change dates, add IANA Considerations] 37 Abstract 39 Cryptographic public key are frequently published and their 40 authenticity demonstrated by certificates. A CERT resource record 41 (RR) is defined so that such certificates and related certificate 42 revocation lists can be stored in the Domain Name System (DNS). 44 Table of Contents 46 Status of This Document....................................1 47 Abstract...................................................1 49 Table of Contents..........................................2 51 1. Introduction............................................3 52 2. The CERT Resource Record................................3 53 2.1 Certificate Type Values................................4 54 2.2 Text Representation of CERT RRs........................5 55 2.3 X.509 OIDs.............................................5 56 3. Appropriate Owner Names for CERT RRs....................6 57 3.1 X.509 CERT RR Names....................................6 58 3.2 PGP CERT RR Names......................................7 59 4. Performance Considerations..............................8 60 5. IANA Considerations.....................................8 61 6. Security Considerations.................................8 63 References.................................................9 64 Authors Addresses..........................................9 65 Expiration and File Name...................................9 67 1. Introduction 69 Public keys are frequently published in the form of a certificate and 70 their authenticity is commonly demonstrated by certificates and 71 related certificate revocation lists (CRLs). A certificate is a 72 binding, through a cryptographic digital signature, of a public key, 73 a validity interval and/or conditions, and identity, authorization, 74 or other information. A certificate revocation list is a list of 75 certificates that are revoked, and incidental information, all signed 76 by the signer (issuer) of the revoked certificates. Examples are 77 X.509 certificates/CRLs in the X.500 directory system or PGP 78 certificates/revocations used by PGP software. 80 Section 2 below specifies a CERT resource record (RR) for the storage 81 of certificates in the Domain Name System. 83 Section 3 discusses appropriate owner names for CERT RRs. 85 Sections 4, 5, and 6 below cover performance, IANA, and security 86 considerations, respectively. 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. The CERT Resource Record 94 The CERT resource record (RR) has the structure given below. Its RR 95 type code is 37. 97 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 98 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | type | key tag | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | algorithm | / 103 +---------------+ certificate or CRL / 104 / / 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 107 The type field is the certificate type as define in section 2.1 108 below. 110 The algorithm field has the same meaning as the algorithm field in 111 KEY and SIG RRs [draft-ietf-dnssec-secext2-*.txt] except that a zero 112 algorithm field indicates the algorithm is unknown to a secure DNS, 113 which may simply be the result of the algorithm not having been 114 standardized for secure DNS. 116 The key tag field is the 16 bit value computed for the key embedded 117 in the certificate as specified in the DNSSEC Standard [draft-ietf- 118 dnssec-secext2-*.txt]. This field is used as an efficiency measure 119 to pick which CERT RRs may be applicable to a particular key. The 120 key tag can be calculated for the key in question and then only CERT 121 RRs with the same key tag need be examined. However, the key must 122 always be transformed to the format it would have as the public key 123 portion of a KEY RR before the key tag is computed. This is only 124 possible if the key is applicable to an algorithm (and limits such as 125 key size limits) defined for DNS security. If it is not, the 126 algorithm field MUST BE zero and the tag field is meaningless and 127 SHOULD BE zero. 129 2.1 Certificate Type Values 131 The following values are defined or reserved: 133 Value Mnemonic Certificate Type 134 ----- -------- ----------- ---- 135 0 reserved 136 1 PKIX X.509 as per PKIX 137 2 SPKI SPKI cert 138 3 PGP PGP cert 139 4-252 available for IANA assignment 140 253 URL URL private 141 254 OID OID private 142 255-65534 available for IANA assignment 143 65535 reserved 145 The PKIX type is reserved to indicate an X.509 certificate conforming 146 to the profile being defined by the IETF PKIX working group. The 147 certificate section will start with a one byte unsigned OID length 148 and then an X.500 OID indicating the nature of the remainder of the 149 certificate section (see 2.3 below). (NOTE: X.509 certificates do 150 not include their X.500 directory type designating OID as a prefix.) 152 The SPKI type is reserved to indicate a certificate formated as to be 153 specified by the IETF SPKI working group. 155 The PGP type indicates a Pretty Good Privacy certificate as described 156 in RFC 1991 and its extensions and successors. 158 The URL private type indicates a certificate format defined by a URL. 159 The certificate portion of the CERT RR MUST begin with a null 160 terminated URL [RFC 1738] and the data after the null is the private 161 format certificate itself. The URL SHOULD be such that a retrieval 162 from it will lead to documentation on the format of the certificate. 163 Recognition of private certificate types need not be based on URL 164 equality but can use various forms of pattern matching so that, for 165 example, subtype or version information can also be encoded into the 166 URL. 168 The OID private type indicates a private format certificate specified 169 by a an ISO OID prefix. The certificate section will start with a 170 one byte unsigned OID length and then a BER encoded OID indicating 171 the nature of the remainder of the certificate section. This can be 172 an X.509 certificate format or some other format. X.509 certificates 173 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX 174 type, not the OID private type. Recognition of private certificate 175 types need not be based on OID equality but can use various forms of 176 pattern matching such as OID prefix. 178 2.2 Text Representation of CERT RRs 180 The RDATA portion of a CERT RR has the type field as an unsigned 181 integer or as a mnemonic symbol as listed in section 2.1 above. 183 The key tag field is represented as an unsigned integer. 185 The algorithm field is represented as an unsigned integer or a 186 mnemonic symbol as listed in [draft-ietf-dnssec-secext2-*.txt]. 188 The certificate / CRL portion is represented in base 64 and may be 189 divided up into any number of white space separated substrings, down 190 to single base 64 digits, which are concatenated to obtain the full 191 signature. These substrings can span lines using the standard 192 parenthesis. 194 Note that the certificate / CRL portion may have internal sub-fields 195 but these do not appear in the master file representation. For 196 example, with type 254, there will be an OID size, an OID, and then 197 the certificate / CRL proper. But only a single logical base 64 198 string will appear in the text representation. 200 2.3 X.509 OIDs 202 OIDs have been defined in connection with the X.500 directory for 203 user certificates, certification authority certificates, revocations 204 of certification authority, and revocations of user certificates. 205 The following table lists the OIDs, their BER encoding, and their 206 length prefixed hex format for use in CERT RRs: 208 id-at-userCertificate 209 = { joint-iso-ccitt(2) ds(5) at(4) 36 } 210 == 0x 03 55 04 24 211 id-at-cACertificate 212 = { joint-iso-ccitt(2) ds(5) at(4) 37 } 213 == 0x 03 55 04 25 214 id-at-authorityRevocationList 215 = { joint-iso-ccitt(2) ds(5) at(4) 38 } 216 == 0x 03 55 04 26 217 id-at-certificateRevocationList 218 = { joint-iso-ccitt(2) ds(5) at(4) 39 } 219 == 0x 03 55 04 27 221 3. Appropriate Owner Names for CERT RRs 223 It is recommended that certificate CERT RRs be stored under a domain 224 name related to their subject, i.e., the name of the entity intended 225 to control the private key corresponding to the public key being 226 certified. It is recommended that certificate revocation list CERT 227 RRs be stored under a domain name related to their issuer. 229 Following some of the guidelines below may result in the use in DNS 230 names of characters that require DNS quoting which is to use a 231 backslash followed by the octal representation of the ASCII code for 232 the character such as \000 for NULL. 234 3.1 X.509 CERT RR Names 236 Some X.509 versions permit multiple names to be associated with 237 subjects and issuers under "Subject Alternate Name" and "Issuer 238 Alternate Name". For example, x.509v3 has such Alternate Names with 239 an ASN.1 specification as follows: 241 GeneralName ::= CHOICE { 242 otherName [0] INSTANCE OF OTHER-NAME, 243 rfc822Name [1] IA5String, 244 dNSName [2] IA5String, 245 x400Address [3] EXPLICIT OR-ADDRESS.&Type, 246 directoryName [4] EXPLICIT Name, 247 ediPartyName [5] EDIPartyName, 248 uniformResourceIdentifier [6] IA5String, 249 iPAddress [7] OCTET STRING, 250 registeredID [8] OBJECT IDENTIFIER 251 } 253 The recommended locations of CERT storage are as follows, in priority 254 order: 256 (1) If a domain name is included in the identification in the 257 certificate or CRL, that should be used. 258 (2) If a domain name is not included but an IP address is included, 259 then the translation of that IP address into the appropriate 260 inverse domain name should be used. 261 (3) If neither of the above it used but a URI containing a domain 262 name is present, that domain name should be used. 263 (4) If none of the above is included but a character string name is 264 included, then it should be treated as described for PGP names in 265 3.2 below. 266 (5) If none of the above apply, then the distinguished name (DN) 267 should be mapped into a domain name as specified in RFC 2247. 269 Example 1: Assume that an X.509v3 certificate is issued to /CN=John 270 Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative 271 names of (a) string "John (the Man) Doe", (b) domain name john- 272 doe.com, and (c) uri . Then 273 the storage locations recommended, in priority order, would be 274 (1) john-doe.com, 275 (2) www.secure.john-doe.com, and 276 (3) Doe.com.xy. 278 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 279 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 280 of (a) domain name widget.foo.example, (b) IPv4 address 281 10.251.13.201, and (c) string "James Hacker 282 ". Then the storage locations 283 recommended, in priority order, would be 284 (1) widget.foo.example, 285 (2) 201.13.251.10.in-addr.arpa, and 286 (3) hacker.mail.widget.foo.example. 288 3.2 PGP CERT RR Names 290 PGP signed keys (certificates) use a general character string name 291 [RFC 1991]. However, it is recommended by PGP that such names include 292 the RFC 822 email address of the party, as in "Leslie Example 293 ". If such a format is used, the CERT should be 294 under the standard translation of the email address into a domain 295 name, which would be leslie.host.example in this case. If no RFC 822 296 name can be extracted from the string name no specific domain name is 297 recommended. 299 4. Performance Considerations 301 Current Domain Name System (DNS) implementations are optimized for 302 small transfers, typically not more than 512 bytes including 303 overhead. While larger transfers will perform correctly and work is 304 underway to make larger transfers more efficient, it is still 305 advisable at this time to make every reasonable effort to minimize 306 the size of certificates stored within the DNS. Steps that can be 307 taken may include using the fewest possible optional or extensions 308 fields and using short field values for variable length fields that 309 must be included. 311 5. IANA Considerations 313 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can 314 only be assigned by an IETF standards action (and this Proposed 315 Standard asigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. 316 Certificate types 0x0100 through 0xFEFF are assigned based on RFC 317 documentation of the certificate type. The availability of private 318 types under 0x00FD and 0x00FE should satisfy most requirements for 319 proprietary or private types. 321 6. Security Considerations 323 By definition, certificates contain their own authenticating 324 signature. Thus it is reasonable to store certificates in non-secure 325 DNS zones or to retrieve certificates from DNS with DNS security 326 checking not implemented or deferred for efficiency. The results MAY 327 be trusted if the certificate chain is verified back to a known 328 trusted key and this conforms with the user's security policy. 330 Alternatively, if certificates are retrieved from a secure DNS zone 331 with DNS security checking enabled and are verified by DNS security, 332 the key within the retrieved certificate MAY be trusted without 333 verifying the certificate chain if this conforms with the user's 334 security policy. 336 CERT RRs are not used in connection with securing the DNS security 337 additions so there are no security considerations related to CERT RRs 338 and securing the DNS itself. 340 References 342 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 343 STD 13, November 1987. 345 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 346 Specifications", STD 13, November 1987. 348 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 349 Resource Locators (URL)", December 1994. 351 RFC 1991 - D. Atkins, W. Stallings & P. Zimmermann, "PGP Message 352 Exchange Formats", August 1996. 354 RFC 2247 - S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 355 "Using Domains in LDAP/X.500 Distinguished Names", January 1998. 357 draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System 358 (DNS) Security Extensions". 360 Authors Addresses 362 Donald E. Eastlake 3rd 363 IBM 364 318 Acton Street 365 Carlisle, MA 01741 USA 367 Telephone: +1-978-287-4877 368 +1-914-784-7913 369 FAX: +1-978-371-7148 370 email: dee3@us.ibm.com 372 Olafur Gudmundsson 373 Trusted Information Systems 374 3060 Washington Road, Route 97 375 Glenwood, MD 21738 USA 377 Telephone: +1-301-854-6889 378 email: ogud@tis.com 380 Expiration and File Name 382 This draft expires May 1999. 384 Its file name is draft-ietf-dnssec-certs-03.txt.