idnits 2.17.1 draft-ietf-dnssec-certs-00.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-27) 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-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-certs-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-certs-00.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-00.txt,', but the file name used is 'draft-ietf-dnssec-certs-00' == 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. ** 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 141: '... meaningless and SHOULD BE zero and th...' RFC 2119 keyword, line 173: '...rtion of the CERT RR MUST begin with a...' RFC 2119 keyword, line 175: '...itself. The URL SHOULD be such that a...' RFC 2119 keyword, line 184: '...ETF PKIX profile SHOULD be indicated b...' RFC 2119 keyword, line 307: '...eved certificate MAY be trusted withou...' 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 (March 1998) is 9540 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 2065' on line 198 looks like a reference -- Missing reference section? 'RFC 1738' on line 174 looks like a reference -- Missing reference section? 'RFC 1991' on line 276 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT CERTs in the DNS 2 September 1997 3 Expires March 1998 5 Storing Certificates in the Domain Name System 6 ------- ------------ -- --- ------ ---- ------ 8 Donald E. Eastlake 3rd 9 Olafur Gudmundsson 11 Status of This Document 13 This draft, file name draft-ietf-dnssec-certs-00.txt, is intended to 14 be become a Proposed Standard RFC. Distribution of this document is 15 unlimited. Comments should be sent to the DNSSEC mailing list or to the authors. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 32 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 33 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 35 Abstract 37 Cryptographic public key are frequently published and their 38 authenticity demonstrated by certification systems. A CERT resource 39 record (RR) is defined so that such certificates and certificate 40 revocation lists can be conveniently stored in the Domain Name System 41 (DNS). 43 RFC 2065 specifies a Proposed Standard for storing cryptographic 44 public keys in the DNS via the KEY resource record (RR). In 45 addition to defining the CERT RR as above, a certificate flag bit is 46 also allocated out of the KEY RR flag field to indicate that a key 47 may be authenticated by one or more CERT RRs stored under the same 48 owner name as the KEY RR. 50 A separate document, draft-ietf-dnssec-indirect-key-00.txt, provides 51 aaditional ways of references keys or certificates within or outside 52 the DNS. 54 Table of Contents 56 Status of This Document....................................1 58 Abstract...................................................2 60 Table of Contents..........................................3 62 1. Introduction............................................4 64 2. The CERT Resource Record................................5 65 2.1 Certificate Type Values................................5 66 2.2 Text Representation of CERT RRs........................6 67 2.3 X.509 OIDs.............................................7 69 3. The KEY Resorce Record CERT Flag Bit....................8 71 4. Appropriate Owner Names for CERT RRs....................9 72 4.1 X.509 CERT RR Names....................................9 73 4.2 PGP CERT RR Names......................................9 75 5. Performance Considerations.............................10 76 6. Security Considerations................................10 78 References................................................11 79 Authors Addresses.........................................11 80 Expiration and File Name..................................11 82 1. Introduction 84 Public keys are frequently published in the form of a certificate and 85 their authenticity is commonly demonstrated by certificates and 86 certificate revocation lists (CRLs). A certificate is a binding, 87 through a cryptographic digital signature, of a public key, a validty 88 interval and/or conditions, and identity and/or authorization 89 information. A certificate revocation list is a list of certificates 90 that are revoked and incidental information all signed by the signer 91 (issuer) of the revoked certificates. Examples are X.509 92 certificates/CRLs in the X.500 directory system or PGP 93 certificates/revocations used by PGP software. 95 Section 2 below specifies a CERT resource record (RR) for the storage 96 of certificates in the Doman Name System. 98 Section 3 below specifies a certificate flag bit in the KEY RR [RFC 99 2065] to hint at the presence of a certificate authenticating the 100 key. 102 Section 4 discusses appropriate owner names for CERT RRs when their 103 owner name is not constrained by a KEY RR with the CERT flag bit on. 105 Sections 5 and 6 below cover performance and security considerations, 106 respectively. 108 2. The CERT Resource Record 110 The CERT resource record (RR) has the structure given below. Its RR 111 type code is TBD. 113 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | type | key tag | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | algorithm | / 119 +---------------+ certificate or CRL / 120 / | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 123 The type field is the certificate type as define in section 2.1 124 below. 126 The algorithm field has the same meaning as the algorithm field in 127 KEY and SIG RRs [RFC 2065] except that a zero algorithm field 128 indicates that the algorithm is not one that is not known to have 129 been standardized for DNSSEC. 131 The key tag field is the 16 bit value computed for the key embedded 132 in the certificate as specified in the DNSSEC Standard. This field 133 is used as an efficiency measure to pick which CERT RRs may be 134 applicable to a particular KEY RR. The key tag can be calculated for 135 the KEY RR in question and then only CERT RRs with the same key tag 136 need be examined. In general, the key in a certificate must be 137 transformed to the format it would have as the public key portion of 138 a KEY RR before the key tag is computed. This is only possible if 139 the key is applicable to an algorithm (and limits such as key size 140 limits) defined for DNS security. If it is not, the tag field is 141 meaningless and SHOULD BE zero and the algorithm field MUST BE zero. 143 2.1 Certificate Type Values 145 The following values are initially defined or reserved: 147 Value Mnemonic Certificate Type 148 ----- -------- ----------- ---- 149 0 reserved 150 1 PKIX X.509 as per PKIX 151 2 SPKI SPKI cert 152 3 PGP PGP cert 153 4-252 available for IANA assignment 154 253 URL URL private 155 254 OID OID private 157 255-65534 available for IANA assignment 158 65535 reserved 160 The PKIX type is reserved to indicate an X.509 certificate conforming 161 to the profile being defined by the IETF PKIX working group. The 162 certificate section will start with a one byte unsigned OID length 163 and then an X.500 OID indicating the nature of the remainder of the 164 certificate section (see 2.3 below). 166 The SPKI type is reserved to indicate a certificate formated as to be 167 specified by the IETF SPKI working group. 169 The PGP type indicates a Pretty Good Privacy certificate as described 170 in RFC 1991 and its extensions and successors. 172 The URL private type indicates a format certificate defined by a URL 173 prefix. The certificate portion of the CERT RR MUST begin with a 174 null terminated URL [RFC 1738] and the data after the null is the 175 private format certificate itself. The URL SHOULD be such that a 176 retrieval from it will lead to documentation on the format of the 177 certificate. 179 The OID private type indicates a private format certificate specified 180 by an ISO OID prefix. The certificate section will start with a one 181 byte unsigned OID length and then an OID indicating the nature of the 182 remainder of the certificate section. This can be an X.509 183 certificate or some other format. X.509 certificates that conform to 184 the IETF PKIX profile SHOULD be indicated by the PKIX type, not the 185 OID private type. 187 2.2 Text Representation of CERT RRs 189 The RDATA portion of a CERT RR has the type field as an unsigned 190 integer or as a mnemonic symbol as listed in section 2.1 above. 192 The key tag field is represented as an unsigned integer. 194 The algorithm field is represented as an unsigned integer or a 195 mnemonic symbol as listed in RFC 2065 or other RFCs supplemental to 196 RFC 2065. 198 The certificate portion is represented in base 64 [RFC 2065] and may 199 be divided up into any number of white space separated substrings, 200 down to single base 64 digits, which are concatenated to obtain the 201 full signature. These substrings can span lines using the standard 202 parenthesis. 204 Note that the certificate (or CRL) portion may have internal sub- 205 fields but these do not appear in the master file representation. 206 For example, with type 254, there will be an OID size, an OID, and 207 then the certificate proper. But only a single logical base 64 string 208 will appear in the text representation. 210 2.3 X.509 OIDs 212 OIDs have been defined in connection with the X.500 directory for 213 user certificates, certification authority certificates, revocations 214 of certification authority, and revocations of user certificates. 215 The following table lists the OIDs and their length prefixed hex 216 format for use in CERT RRs: 218 id-at-userCertificate 219 = { joint-iso-ccitt(2) ds(5) at(4) 36 } 220 == 0x 03 55 04 24 221 id-at-cACertificate 222 = { joint-iso-ccitt(2) ds(5) at(4) 37 } 223 == 0x 03 55 04 25 224 id-at-authorityRevocationList 225 = { joint-iso-ccitt(2) ds(5) at(4) 38 } 226 == 0x 03 55 04 26 227 id-at-certificateRevocationList 228 = { joint-iso-ccitt(2) ds(5) at(4) 39 } 229 == 0x 03 55 04 27 231 3. The KEY Resorce Record CERT Flag Bit 233 Bit 4 in the KEY resource record (RR) is defined as the certificate 234 flag bit. It indicates that any software which is sensitive to or 235 wishes to process certificates and/or certificate revocation lists 236 should do an additional retrieval from the Domain Name System for 237 CERT RRs with the same owner name as the KEY RR in question. The 238 presence of the CERT bit does not imply that there is a CERT record 239 for that KEY stored in DNS, it is just a hint. 241 When KEY RRs are presented in text form, the certificate flag bit may 242 be symbolically presented as the mnemonic "CERT". 244 4. Appropriate Owner Names for CERT RRs 246 CERT RR's to be found via the KEY RR CERT flag bit described in 247 section 3 above must be stored under the same name as the KEY RR in 248 question. However, there may be CERT RRs that are not constrained by 249 a KEY RR with the CERT flag bit and it may be desired to name a CERT 250 RR so that it can be found with some convenience. It is recommended 251 that certificate CERT RRs be stored under a domain name related to 252 their subject and certificate revocation list CERT RRs be stored 253 under a domain name related to their issuer. 255 4.1 X.509 CERT RR Names 257 X.509 has versions some of which permit multiple names to be 258 associated with subjects and issuers under "Subject Alternate Name" 259 and "Issuer Alternate Name". 261 If a domain name is included in the identification in the certificate 262 or CRL, that should be used. If a domain name is not included but an 263 IP address is included, then the translation of that IP address into 264 the appropriate inverse domain name should be used. If neither of 265 the above it used but a URI containing a domain name is present, that 266 domain name should be used. If none of the above is included but a 267 character string name is included, then it should be treated as 268 described for PGP names in 4.2 below. If none of the above apply, 269 then the distinguished name (DN) that is required by X.509 should be 270 ... [maybe some of the SMTP <-> X.400 RFCs give a conversion for a 271 subset of DNs but it is generally undefined...] 273 4.2 PGP CERT RR Names 275 PGP signed keys (certificates) use a general character string name 276 [RFC 1991]. However, it is recommended by PGP that such names 277 include the RFC 822 email address of the party, as in "Leslie Example 278 ". If such a format is used, the CERT should be 279 under the standard translation of the email address into a domain 280 name, which would be leslie.host.example in this case. If no RFC 822 281 name can be extracted from the string name ... [Probably it's 282 undefined...] 284 5. Performance Considerations 286 Current Domain Name System (DNS) implementations are optimized for 287 small transfers, typically not more than 512 bytes including 288 overhead. While larger transfers will perform correctly and work is 289 underway to make larger transfers more efficient, it is still 290 advisable at this time to make every effort to minimize the size of 291 certificates stored within the DNS. Steps that can be taken may 292 include using the fewest possible optional or extentions fields and 293 using short field values for variable length fields that must be 294 included. 296 6. Security Considerations 298 By definition, certificates contains their own authenticating 299 signature. Thus it is reasonable to store certificates in non-secure 300 DNS zones or to retrieve certificates from DNS with DNS security 301 checking deferred for efficiency. The results can be trusted if the 302 certificate chain is verified back to a known trusted key and this 303 conforms with the user's security policy. 305 Alternatively, if certificates are retrieved from a trusted secure 306 DNS zone with DNS security checking enabled, the key within the 307 retrieved certificate MAY be trusted without verifying the 308 certificate chain if this conforms with the user's security policy. 309 However, it is recommended that the certificate chain be checked in 310 any case for added assurance. 312 CERT RRs are not intended to be used in connection with securing the 313 DNS security additions so there are no security considerations 314 related to CERT and securing the DNS itself. 316 References 318 RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", 319 STD 13, November 1987. 321 RFC 1035 - P. Mockapetris, "Domain Names - Implementation and 322 Specifications", STD 13, November 1987. 324 RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform 325 Resource Locators (URL)", December 1994. 327 RFC 1991 - D. Atkins, W. Stallings & P. Zimmermann, "PGP Message 328 Exchange Formats", August 1996. 330 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 331 Extensions", 01/03/1997. 333 draft-ietf-dnssec-indirect-key-00.txt 335 Authors Addresses 337 Donald E. Eastlake 3rd 338 CyberCash, Inc. 339 318 Acton Street 340 Carlisle, MA 01741 USA 342 Telephone: +1 508 287 4877 343 +1 703 620-4200 (main office, Reston, VA) 344 FAX: +1 508 371 7148 345 EMail: dee@cybercash.com 347 Olafur Gudmundsson 348 Trusted Information Systems 349 3060 Washington Road, Route 97 350 Glenwood, MD 21738 352 Telephone: +1 301 854 6889 353 EMail: ogud@tis.com 355 Expiration and File Name 357 This draft expires March 1998. 359 Its file name is draft-ietf-dnssec-certs-00.txt.