idnits 2.17.1 draft-ietf-dnssec-certs-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-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-04.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-certs-04.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-certs-04.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-04.txt,', but the file name used is 'draft-ietf-dnssec-certs-04' == 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 (June 1999) is 9081 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? 'RFC 1738' on line 38 looks like a reference -- Missing reference section? 'RFC 2396' on line 164 looks like a reference -- Missing reference section? 'RFC2119' on line 95 looks like a reference -- Missing reference section? '0' on line 246 looks like a reference -- Missing reference section? '1' on line 247 looks like a reference -- Missing reference section? '2' on line 248 looks like a reference -- Missing reference section? '3' on line 249 looks like a reference -- Missing reference section? '4' on line 250 looks like a reference -- Missing reference section? '5' on line 251 looks like a reference -- Missing reference section? '6' on line 252 looks like a reference -- Missing reference section? '7' on line 253 looks like a reference -- Missing reference section? '8' on line 254 looks like a reference -- Missing reference section? 'RFC 2440' on line 295 looks like a reference -- Missing reference section? 'RFC 2434' on line 321 looks like a reference Summary: 9 errors (**), 1 flaw (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT CERTs in the DNS 2 December 1998 3 Expires June 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-04.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 draft 2 to 3: update author info, add RFC 2119 35 reference, change dates, add IANA Considerations] [[changes from 36 draft 3 to 4: update author info, change dates, tweak IANA 37 Considerations including adding reference to RFC 2434, update URL 38 references [RFC 1738] to absolute URI references [RFC 2396], update 39 PGP references to new RFC 2440 ]] 41 Abstract 43 Cryptographic public key are frequently published and their 44 authenticity demonstrated by certificates. A CERT resource record 45 (RR) is defined so that such certificates and related certificate 46 revocation lists can be stored in the Domain Name System (DNS). 48 Table of Contents 50 Status of This Document....................................1 51 Abstract...................................................1 53 Table of Contents..........................................2 55 1. Introduction............................................3 56 2. The CERT Resource Record................................3 57 2.1 Certificate Type Values................................4 58 2.2 Text Representation of CERT RRs........................5 59 2.3 X.509 OIDs.............................................5 60 3. Appropriate Owner Names for CERT RRs....................6 61 3.1 X.509 CERT RR Names....................................6 62 3.2 PGP CERT RR Names......................................7 63 4. Performance Considerations..............................8 64 5. IANA Considerations.....................................8 65 6. Security Considerations.................................8 67 References.................................................9 68 Authors Addresses..........................................9 69 Expiration and File Name..................................10 71 1. Introduction 73 Public keys are frequently published in the form of a certificate and 74 their authenticity is commonly demonstrated by certificates and 75 related certificate revocation lists (CRLs). A certificate is a 76 binding, through a cryptographic digital signature, of a public key, 77 a validity interval and/or conditions, and identity, authorization, 78 or other information. A certificate revocation list is a list of 79 certificates that are revoked, and incidental information, all signed 80 by the signer (issuer) of the revoked certificates. Examples are 81 X.509 certificates/CRLs in the X.500 directory system or PGP 82 certificates/revocations used by PGP software. 84 Section 2 below specifies a CERT resource record (RR) for the storage 85 of certificates in the Domain Name System. 87 Section 3 discusses appropriate owner names for CERT RRs. 89 Sections 4, 5, and 6 below cover performance, IANA, and security 90 considerations, respectively. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. The CERT Resource Record 98 The CERT resource record (RR) has the structure given below. Its RR 99 type code is 37. 101 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | type | key tag | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | algorithm | / 107 +---------------+ certificate or CRL / 108 / / 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 111 The type field is the certificate type as define in section 2.1 112 below. 114 The algorithm field has the same meaning as the algorithm field in 115 KEY and SIG RRs [draft-ietf-dnssec-secext2-*.txt] except that a zero 116 algorithm field indicates the algorithm is unknown to a secure DNS, 117 which may simply be the result of the algorithm not having been 118 standardized for secure DNS. 120 The key tag field is the 16 bit value computed for the key embedded 121 in the certificate as specified in the DNSSEC Standard [draft-ietf- 122 dnssec-secext2-*.txt]. This field is used as an efficiency measure 123 to pick which CERT RRs may be applicable to a particular key. The 124 key tag can be calculated for the key in question and then only CERT 125 RRs with the same key tag need be examined. However, the key must 126 always be transformed to the format it would have as the public key 127 portion of a KEY RR before the key tag is computed. This is only 128 possible if the key is applicable to an algorithm (and limits such as 129 key size limits) defined for DNS security. If it is not, the 130 algorithm field MUST BE zero and the tag field is meaningless and 131 SHOULD BE zero. 133 2.1 Certificate Type Values 135 The following values are defined or reserved: 137 Value Mnemonic Certificate Type 138 ----- -------- ----------- ---- 139 0 reserved 140 1 PKIX X.509 as per PKIX 141 2 SPKI SPKI cert 142 3 PGP PGP cert 143 4-252 available for IANA assignment 144 253 URI URI private 145 254 OID OID private 146 255-65534 available for IANA assignment 147 65535 reserved 149 The PKIX type is reserved to indicate an X.509 certificate conforming 150 to the profile being defined by the IETF PKIX working group. The 151 certificate section will start with a one byte unsigned OID length 152 and then an X.500 OID indicating the nature of the remainder of the 153 certificate section (see 2.3 below). (NOTE: X.509 certificates do 154 not include their X.500 directory type designating OID as a prefix.) 156 The SPKI type is reserved to indicate a certificate formated as to be 157 specified by the IETF SPKI working group. 159 The PGP type indicates a Pretty Good Privacy certificate as described 160 in RFC 2440 and its extensions and successors. 162 The URI private type indicates a certificate format defined by an 163 absolute URI. The certificate portion of the CERT RR MUST begin with 164 a null terminated URI [RFC 2396] and the data after the null is the 165 private format certificate itself. The URI SHOULD be such that a 166 retrieval from it will lead to documentation on the format of the 167 certificate. Recognition of private certificate types need not be 168 based on URI equality but can use various forms of pattern matching 169 so that, for example, subtype or version information can also be 170 encoded into the URI. 172 The OID private type indicates a private format certificate specified 173 by a an ISO OID prefix. The certificate section will start with a 174 one byte unsigned OID length and then a BER encoded OID indicating 175 the nature of the remainder of the certificate section. This can be 176 an X.509 certificate format or some other format. X.509 certificates 177 that conform to the IETF PKIX profile SHOULD be indicated by the PKIX 178 type, not the OID private type. Recognition of private certificate 179 types need not be based on OID equality but can use various forms of 180 pattern matching such as OID prefix. 182 2.2 Text Representation of CERT RRs 184 The RDATA portion of a CERT RR has the type field as an unsigned 185 integer or as a mnemonic symbol as listed in section 2.1 above. 187 The key tag field is represented as an unsigned integer. 189 The algorithm field is represented as an unsigned integer or a 190 mnemonic symbol as listed in [draft-ietf-dnssec-secext2-*.txt]. 192 The certificate / CRL portion is represented in base 64 and may be 193 divided up into any number of white space separated substrings, down 194 to single base 64 digits, which are concatenated to obtain the full 195 signature. These substrings can span lines using the standard 196 parenthesis. 198 Note that the certificate / CRL portion may have internal sub-fields 199 but these do not appear in the master file representation. For 200 example, with type 254, there will be an OID size, an OID, and then 201 the certificate / CRL proper. But only a single logical base 64 202 string will appear in the text representation. 204 2.3 X.509 OIDs 206 OIDs have been defined in connection with the X.500 directory for 207 user certificates, certification authority certificates, revocations 208 of certification authority, and revocations of user certificates. 209 The following table lists the OIDs, their BER encoding, and their 210 length prefixed hex format for use in CERT RRs: 212 id-at-userCertificate 213 = { joint-iso-ccitt(2) ds(5) at(4) 36 } 214 == 0x 03 55 04 24 215 id-at-cACertificate 216 = { joint-iso-ccitt(2) ds(5) at(4) 37 } 217 == 0x 03 55 04 25 218 id-at-authorityRevocationList 219 = { joint-iso-ccitt(2) ds(5) at(4) 38 } 220 == 0x 03 55 04 26 221 id-at-certificateRevocationList 222 = { joint-iso-ccitt(2) ds(5) at(4) 39 } 223 == 0x 03 55 04 27 225 3. Appropriate Owner Names for CERT RRs 227 It is recommended that certificate CERT RRs be stored under a domain 228 name related to their subject, i.e., the name of the entity intended 229 to control the private key corresponding to the public key being 230 certified. It is recommended that certificate revocation list CERT 231 RRs be stored under a domain name related to their issuer. 233 Following some of the guidelines below may result in the use in DNS 234 names of characters that require DNS quoting which is to use a 235 backslash followed by the octal representation of the ASCII code for 236 the character such as \000 for NULL. 238 3.1 X.509 CERT RR Names 240 Some X.509 versions permit multiple names to be associated with 241 subjects and issuers under "Subject Alternate Name" and "Issuer 242 Alternate Name". For example, x.509v3 has such Alternate Names with 243 an ASN.1 specification as follows: 245 GeneralName ::= CHOICE { 246 otherName [0] INSTANCE OF OTHER-NAME, 247 rfc822Name [1] IA5String, 248 dNSName [2] IA5String, 249 x400Address [3] EXPLICIT OR-ADDRESS.&Type, 250 directoryName [4] EXPLICIT Name, 251 ediPartyName [5] EDIPartyName, 252 uniformResourceIdentifier [6] IA5String, 253 iPAddress [7] OCTET STRING, 254 registeredID [8] OBJECT IDENTIFIER 255 } 257 The recommended locations of CERT storage are as follows, in priority 258 order: 260 (1) If a domain name is included in the identification in the 261 certificate or CRL, that should be used. 262 (2) If a domain name is not included but an IP address is included, 263 then the translation of that IP address into the appropriate 264 inverse domain name should be used. 265 (3) If neither of the above it used but a URI containing a domain 266 name is present, that domain name should be used. 267 (4) If none of the above is included but a character string name is 268 included, then it should be treated as described for PGP names in 269 3.2 below. 270 (5) If none of the above apply, then the distinguished name (DN) 271 should be mapped into a domain name as specified in RFC 2247. 273 Example 1: Assume that an X.509v3 certificate is issued to /CN=John 274 Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative 275 names of (a) string "John (the Man) Doe", (b) domain name john- 276 doe.com, and (c) uri . Then 277 the storage locations recommended, in priority order, would be 278 (1) john-doe.com, 279 (2) www.secure.john-doe.com, and 280 (3) Doe.com.xy. 282 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 283 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 284 of (a) domain name widget.foo.example, (b) IPv4 address 285 10.251.13.201, and (c) string "James Hacker 286 ". Then the storage locations 287 recommended, in priority order, would be 288 (1) widget.foo.example, 289 (2) 201.13.251.10.in-addr.arpa, and 290 (3) hacker.mail.widget.foo.example. 292 3.2 PGP CERT RR Names 294 PGP signed keys (certificates) use a general character string User ID 295 [RFC 2440]. However, it is recommended by PGP that such names include 296 the RFC 822 email address of the party, as in "Leslie Example 297 ". If such a format is used, the CERT should be 298 under the standard translation of the email address into a domain 299 name, which would be leslie.host.example in this case. If no RFC 822 300 name can be extracted from the string name no specific domain name is 301 recommended. 303 4. Performance Considerations 305 Current Domain Name System (DNS) implementations are optimized for 306 small transfers, typically not more than 512 bytes including 307 overhead. While larger transfers will perform correctly and work is 308 underway to make larger transfers more efficient, it is still 309 advisable at this time to make every reasonable effort to minimize 310 the size of certificates stored within the DNS. Steps that can be 311 taken may include using the fewest possible optional or extensions 312 fields and using short field values for variable length fields that 313 must be included. 315 5. IANA Considerations 317 Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can 318 only be assigned by an IETF standards action [RFC 2434] (and this 319 document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). 320 Certificate types 0x0100 through 0xFEFF are assigned through IETF 321 Consensus [RFC 2434] based on RFC documentation of the certificate 322 type. The availability of private types under 0x00FD and 0x00FE 323 should satisfy most requirements for proprietary or private types. 325 6. Security Considerations 327 By definition, certificates contain their own authenticating 328 signature. Thus it is reasonable to store certificates in non-secure 329 DNS zones or to retrieve certificates from DNS with DNS security 330 checking not implemented or deferred for efficiency. The results MAY 331 be trusted if the certificate chain is verified back to a known 332 trusted key and this conforms with the user's security policy. 334 Alternatively, if certificates are retrieved from a secure DNS zone 335 with DNS security checking enabled and are verified by DNS security, 336 the key within the retrieved certificate MAY be trusted without 337 verifying the certificate chain if this conforms with the user's 338 security policy. 340 CERT RRs are not used in connection with securing the DNS security 341 additions so there are no security considerations related to CERT RRs 342 and securing the DNS itself. 344 References 346 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 347 STD 13, November 1987. 349 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 350 Specifications", STD 13, November 1987. 352 RFC 2119 - S. Bradner, "Key words for use in RFCs to Indicate 353 Requirement Levels", March 1997. 355 RFC 2247 - S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 356 "Using Domains in LDAP/X.500 Distinguished Names", January 1998. 358 RFC 2396 - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform 359 Resource Identifiers (URI): Generic Syntax", August 1998. 361 RFC 2440 - J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP 362 Message Format", November 1998 364 RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 365 Considerations Section in RFCs", October 1998. 367 draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System 368 (DNS) Security Extensions". 370 Authors Addresses 372 Donald E. Eastlake 3rd 373 IBM 374 65 Shindegan Hill Road 375 RR#1 376 Carmel, NY 10512 USA 378 Telephone: +1-914-784-7913 (w) 379 +1-914-276-2668 (h) 380 FAX: +1-914-784-3833 (w-fax) 381 email: dee3@us.ibm.com 383 Olafur Gudmundsson 384 TIS Labs at Network Associates 385 3060 Washington Rd, Route 97 386 Glenwood MD 21738 388 Telephone: +1 443-259-2389 389 email: ogud@tis.com 391 Expiration and File Name 393 This draft expires June 1999. 395 Its file name is draft-ietf-dnssec-certs-04.txt.