idnits 2.17.1 draft-ietf-dnssec-certs-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-23) 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-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-certs-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-certs-02.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-02.txt,', but the file name used is 'draft-ietf-dnssec-certs-02' == 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 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... algorithm field MUST BE zero and the ...' RFC 2119 keyword, line 123: '... SHOULD BE zero....' RFC 2119 keyword, line 154: '...rtion of the CERT RR MUST begin with a...' RFC 2119 keyword, line 156: '...itself. The URL SHOULD be such that a...' RFC 2119 keyword, line 168: '...ETF PKIX profile SHOULD be indicated b...' (2 more instances...) 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 (September 1998) is 9352 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 155 looks like a reference -- Missing reference section? 'RFC 1991' on line 268 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT CERTs in the DNS 2 Expires September 1998 4 Storing Certificates in the Domain Name System (DNS) 5 ------- ------------ -- --- ------ ---- ------ ----- 7 Donald E. Eastlake 3rd 8 Olafur Gudmundsson 10 Status of This Document 12 This draft, file name draft-ietf-dnssec-certs-02.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 learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 ftp.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 34 Abstract 36 Cryptographic public key are frequently published and their 37 authenticity demonstrated by certificate systems. A CERT resource 38 record (RR) is defined so that such certificates and related 39 certificate revocation lists can be stored in the Domain Name System 40 (DNS). 42 Table of Contents 44 Status of This Document....................................1 45 Abstract...................................................1 47 Table of Contents..........................................2 49 1. Introduction............................................3 51 2. The CERT Resource Record................................4 52 2.1 Certificate Type Values................................4 53 2.2 Text Representation of CERT RRs........................5 54 2.3 X.509 OIDs.............................................6 56 3. Appropriate Owner Names for CERT RRs....................7 57 3.1 X.509 CERT RR Names....................................7 58 3.2 PGP CERT RR Names......................................8 60 4. Performance Considerations..............................9 61 5. Security Considerations.................................9 63 References................................................10 64 Authors Addresses.........................................10 65 Expiration and File Name..................................10 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 and 5 below cover performance and security considerations, 86 respectively. 88 2. The CERT Resource Record 90 The CERT resource record (RR) has the structure given below. Its RR 91 type code is 37. 93 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 94 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 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | type | key tag | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | algorithm | / 99 +---------------+ certificate or CRL / 100 / / 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 103 The type field is the certificate type as define in section 2.1 104 below. 106 The algorithm field has the same meaning as the algorithm field in 107 KEY and SIG RRs [draft-ietf-dnssec-secext2-*.txt] except that a zero 108 algorithm field indicates the algorithm is unknown to a secure DNS, 109 which may simply be the result of it not having been standardized for 110 secure DNS. 112 The key tag field is the 16 bit value computed for the key embedded 113 in the certificate as specified in the DNSSEC Standard [draft-ietf- 114 dnssec-secext2-*.txt]. This field is used as an efficiency measure 115 to pick which CERT RRs may be applicable to a particular key. The 116 key tag can be calculated for the key in question and then only CERT 117 RRs with the same key tag need be examined. However, the key must 118 always be transformed to the format it would have as the public key 119 portion of a KEY RR before the key tag is computed. This is only 120 possible if the key is applicable to an algorithm (and limits such as 121 key size limits) defined for DNS security. If it is not, the 122 algorithm field MUST BE zero and the tag field is meaningless and 123 SHOULD BE zero. 125 2.1 Certificate Type Values 127 The following values are defined or reserved: 129 Value Mnemonic Certificate Type 130 ----- -------- ----------- ---- 131 0 reserved 132 1 PKIX X.509 as per PKIX 133 2 SPKI SPKI cert 134 3 PGP PGP cert 135 4-252 available for IANA assignment 136 253 URL URL private 137 254 OID OID private 138 255-65534 available for IANA assignment 139 65535 reserved 141 The PKIX type is reserved to indicate an X.509 certificate conforming 142 to the profile being defined by the IETF PKIX working group. The 143 certificate section will start with a one byte unsigned OID length 144 and then an X.500 OID indicating the nature of the remainder of the 145 certificate section (see 2.3 below). 147 The SPKI type is reserved to indicate a certificate formated as to be 148 specified by the IETF SPKI working group. 150 The PGP type indicates a Pretty Good Privacy certificate as described 151 in RFC 1991 and its extensions and successors. 153 The URL private type indicates a certificate format defined by a URL 154 prefix. The certificate portion of the CERT RR MUST begin with a 155 null terminated URL [RFC 1738] and the data after the null is the 156 private format certificate itself. The URL SHOULD be such that a 157 retrieval from it will lead to documentation on the format of the 158 certificate. Recognition of private certificate types need not be 159 based on URL equality but can use various forms of pattern matching 160 so that, for example, subtype or version information can also be 161 encoded into the URL. 163 The OID private type indicates a private format certificate specified 164 by an ISO OID prefix. The certificate section will start with a one 165 byte unsigned OID length and then an OID indicating the nature of the 166 remainder of the certificate section. This can be an X.509 167 certificate format or some other format. X.509 certificates that 168 conform to the IETF PKIX profile SHOULD be indicated by the PKIX 169 type, not the OID private type. Recognition of private certificate 170 types need not be based on OID equality but can use various forms of 171 pattern matching such as OID prefix. 173 2.2 Text Representation of CERT RRs 175 The RDATA portion of a CERT RR has the type field as an unsigned 176 integer or as a mnemonic symbol as listed in section 2.1 above. 178 The key tag field is represented as an unsigned integer. 180 The algorithm field is represented as an unsigned integer or a 181 mnemonic symbol as listed in [draft-ietf-dnssec-secext2-*.txt]. 183 The certificate / CRL portion is represented in base 64 and may be 184 divided up into any number of white space separated substrings, down 185 to single base 64 digits, which are concatenated to obtain the full 186 signature. These substrings can span lines using the standard 187 parenthesis. 189 Note that the certificate / CRL portion may have internal sub-fields 190 but these do not appear in the master file representation. For 191 example, with type 254, there will be an OID size, an OID, and then 192 the certificate / CRL proper. But only a single logical base 64 193 string will appear in the text representation. 195 2.3 X.509 OIDs 197 OIDs have been defined in connection with the X.500 directory for 198 user certificates, certification authority certificates, revocations 199 of certification authority, and revocations of user certificates. 200 The following table lists the OIDs and their length prefixed hex 201 format for use in CERT RRs: 203 id-at-userCertificate 204 = { joint-iso-ccitt(2) ds(5) at(4) 36 } 205 == 0x 03 55 04 24 206 id-at-cACertificate 207 = { joint-iso-ccitt(2) ds(5) at(4) 37 } 208 == 0x 03 55 04 25 209 id-at-authorityRevocationList 210 = { joint-iso-ccitt(2) ds(5) at(4) 38 } 211 == 0x 03 55 04 26 212 id-at-certificateRevocationList 213 = { joint-iso-ccitt(2) ds(5) at(4) 39 } 214 == 0x 03 55 04 27 216 3. Appropriate Owner Names for CERT RRs 218 It is recommended that certificate CERT RRs be stored under a domain 219 name related to their subject, i.e., the name of the entity intended 220 to control the private key corresponding to the public key being 221 certified. It is recommended that certificate revocation list CERT 222 RRs be stored under a domain name related to their issuer. 224 3.1 X.509 CERT RR Names 226 Some X.509 versions permit multiple names to be associated with 227 subjects and issuers under "Subject Alternate Name" and "Issuer 228 Alternate Name". 230 The following is the recommended locations of CERT storage are as 231 follows in priority order: 233 (1) If a domain name is included in the identification in the 234 certificate or CRL, that should be used. 235 (2) If a domain name is not included but an IP address is included, 236 then the translation of that IP address into the appropriate 237 inverse domain name should be used. 238 (3) If neither of the above it used but a URI containing a domain 239 name is present, that domain name should be used. 240 (4) If none of the above is included but a character string name is 241 included, then it should be treated as described for PGP names in 242 4.2 below. 243 (4) If none of the above apply, then the distinguished name (DN) 244 should be mapped into a domain name as specified in RFC 2247. 246 Example 1: Assume that an X.509v3 certificate is issued to /CN=John 247 Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative 248 names of (a) string "John (the Man) Doe", (b) domain name john- 249 doe.com, and (c) uri . Then 250 the storage locations recommended, in priority order, would be 251 (1) john-doe.com, 252 (2) www.secure.john-doe.com, and 253 (3) Doe.com.xy. 255 Example 2: Assume that an X.509v3 certificate is issued to /CN=James 256 Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names 257 of (a) domain name widget.foo.example, (b) IPv4 address 258 10.251.13.201, and (c) string "James Hacker 259 ". Then the storage locations 260 recommended, in priority order, would be 261 (1) widget.foo.example, 262 (2) 201.13.251.10.in-addr.arpa, and 263 (3) hacker.mail.widget.foo.example. 265 3.2 PGP CERT RR Names 267 PGP signed keys (certificates) use a general character string name 268 [RFC 1991]. However, it is recommended by PGP that such names include 269 the RFC 822 email address of the party, as in "Leslie Example 270 ". If such a format is used, the CERT should be 271 under the standard translation of the email address into a domain 272 name, which would be leslie.host.example in this case. If no RFC 822 273 name can be extracted from the string name no specific domain name is 274 recommended. 276 4. Performance Considerations 278 Current Domain Name System (DNS) implementations are optimized for 279 small transfers, typically not more than 512 bytes including 280 overhead. While larger transfers will perform correctly and work is 281 underway to make larger transfers more efficient, it is still 282 advisable at this time to make every reasonable effort to minimize 283 the size of certificates stored within the DNS. Steps that can be 284 taken may include using the fewest possible optional or extensions 285 fields and using short field values for variable length fields that 286 must be included. 288 5. Security Considerations 290 By definition, certificates contains their own authenticating 291 signature. Thus it is reasonable to store certificates in non-secure 292 DNS zones or to retrieve certificates from DNS with DNS security 293 checking not implemented or deferred for efficiency. The results MAY 294 be trusted if the certificate chain is verified back to a known 295 trusted key and this conforms with the user's security policy. 297 Alternatively, if certificates are retrieved from a secure DNS zone 298 with DNS security checking enabled and are verified by DNS security, 299 the key within the retrieved certificate MAY be trusted without 300 verifying the certificate chain if this conforms with the user's 301 security policy. 303 CERT RRs are not used in connection with securing the DNS security 304 additions so there are no security considerations related to CERT RRs 305 and securing the DNS itself. 307 References 309 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 310 STD 13, November 1987. 312 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 313 Specifications", STD 13, November 1987. 315 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 316 Resource Locators (URL)", December 1994. 318 RFC 1991 - D. Atkins, W. Stallings & P. Zimmermann, "PGP Message 319 Exchange Formats", August 1996. 321 RFC 2247 - S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 322 "Using Domains in LDAP/X.500 Distinguished Names", January 1998. 324 draft-ietf-dnssec-secext2-*.txt - D. Eastlake, "Domain Name System 325 (DNS) Security Extensions", ?. 327 Authors Addresses 329 Donald E. Eastlake 3rd 330 CyberCash, Inc. 331 318 Acton Street 332 Carlisle, MA 01741 USA 334 Telephone: +1 978 287 4877 335 +1 703 620-4200 (main office, Reston, VA) 336 FAX: +1 978 371 7148 337 email: dee@cybercash.com 339 Olafur Gudmundsson 340 Trusted Information Systems 341 3060 Washington Road, Route 97 342 Glenwood, MD 21738 USA 344 Telephone: +1 301 854 6889 345 email: ogud@tis.com 347 Expiration and File Name 349 This draft expires September 1998. 351 Its file name is draft-ietf-dnssec-certs-02.txt.