idnits 2.17.1 draft-jabley-dnssec-trust-anchor-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2016) is 2887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational J. Schlyter 5 Expires: November 24, 2016 Kirei AB 6 G. Bailey 7 Independent 8 P. Hoffman 9 ICANN 10 May 23, 2016 12 DNSSEC Trust Anchor Publication for the Root Zone 13 draft-jabley-dnssec-trust-anchor-14 15 Abstract 17 The root zone of the Domain Name System (DNS) has been 18 cryptographically signed using DNS Security Extensions (DNSSEC). 20 In order to obtain secure answers from the root zone of the DNS using 21 DNSSEC, a client must configure a suitable trust anchor. This 22 document describes the format and publication mechanisms IANA has 23 used to distribute the DNSSEC trust anchors. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 24, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4 62 2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5 65 2.1.3. Converting from XML to DS Records . . . . . . . . . . 6 66 2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 7 67 2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9 69 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9 70 3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9 71 4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 8.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 13 79 Appendix B. About this Document . . . . . . . . . . . . . . . . 13 80 B.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. 86 Security extensions to the DNS (DNSSEC) are described in [RFC4033], 87 [RFC4034], [RFC4035], [RFC4509], [RFC5155] and [RFC5702]. 89 A discussion of operational practices relating to DNSSEC can be found 90 in [RFC6781]. 92 In the DNSSEC protocol, resource record sets (RRSets) are signed 93 cryptographically. This means that a response to a query contains 94 signatures that allow the integrity and authenticity of the RRSet to 95 be verified. DNSSEC signatures are validated by following a chain of 96 signatures to a "trust anchor". The reason for trusting a trust 97 anchor is outside the DNSSEC protocol, but having one or more trust 98 anchors is required for the DNSSEC protocol to work. 100 The publication of trust anchors for the root zone of the DNS is an 101 IANA function performed by ICANN. A detailed description of 102 corresponding key management practices can be found in [DPS], which 103 can be retrieved from the IANA Repository at . 106 This document describes the formats and distribution methods of 107 DNSSEC trust anchors that have been used by IANA for the root zone of 108 the DNS since 2010. Other organizations might have different formats 109 and mechansims for distributing DNSSEC trust anchors for the root 110 zone; however, most operators and software vendors have chosen to 111 rely on the IANA trust anchors. 113 IMPORTANT NOTE: at the time of this writing, IANA intends to change 114 the formats and distribution methods in the future. If such a change 115 happens, IANA will publish the changes on its web site at 116 . 118 The formats and distribution methods described in this document are a 119 complement to, not a substitute for, the automated DNSSEC trust 120 anchor update protocol described in [RFC5011]. That protocol allows 121 for secure in-band succession of trust anchors when trust has already 122 been established. This document describes one way to establish an 123 initial trust anchor that can be used by [RFC5011]. 125 1.1. Definitions 127 The term "trust anchor" is used in many different contexts in the 128 security community. Many of the common definitions conflict because 129 they are specific to a specific system, such as just for DNSSEC or 130 just for S/MIME messages. 132 In cryptographic systems with hierarchical structure, a trust anchor 133 is an authoritative entity for which trust is assumed and not 134 derived. The format of the entity differs in different systems, but 135 the basic idea, that trust is assumed and not derived, is common to 136 all the common uses of the term "trust anchor". 138 The root zone trust anchor formats published by IANA are defined in 139 Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY 140 RR or DS RR hash of a DNSKEY RR". Note that the formats defined here 141 do not match the definition of "trust anchor" from [RFC4033]; 142 however, a system that wants to convert the trusted material from 143 IANA into a DS RR can do so. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics 151 IANA publishes trust anchors for the root zone in three formats: 153 o an XML document that contains the hashes of the DNSKEY records 155 o certificates in PKIX format [RFC5280] that contain DS records and 156 the full public key of DNSKEY records 158 o certificate signing requests (CSRs) in PKCS#10 format [RFC2986] 159 that contain DS records and the full public key of DNSKEY records 161 These formats and the semantics associated with each are described in 162 the rest of this section. 164 2.1. Hashes in XML 166 The XML document contains a set of hashes for the DNSKEY records that 167 can be used to validate the root zone. The hashes are consistent 168 with the defined presentation format of Delegation Signer (DS) 169 resource records from [RFC4034]. 171 2.1.1. XML Syntax 173 A Relax NG Compact Schema for the documents used to publish trust 174 anchors is given in Figure 1. 176 datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" 178 start = element TrustAnchor { 179 attribute id { xsd:string }, 180 attribute source { xsd:string }, 181 element Zone { xsd:string }, 183 keydigest+ 184 } 186 keydigest = element KeyDigest { 187 attribute id { xsd:string }, 188 attribute validFrom { xsd:dateTime }, 189 attribute validUntil { xsd:dateTime }?, 191 element KeyTag { 192 xsd:nonNegativeInteger { maxInclusive = "65535" } }, 193 element Algorithm { 194 xsd:nonNegativeInteger { maxInclusive = "255" } }, 195 element DigestType { 196 xsd:nonNegativeInteger { maxInclusive = "255" } }, 197 element Digest { xsd:hexBinary } 198 } 200 Figure 1 202 2.1.2. XML Semantics 204 The TrustAnchor element is the container for all of the trust anchors 205 in the file. 207 The id attribute in the TrustAnchor element is an opaque string that 208 identifies the set of trust anchors. Its value has no particular 209 semantics. Note that the id element in the TrustAnchor element is 210 different than the id element in the KeyDigest element, described 211 below. 213 The source attribute in the TrustAnchor element gives information 214 about where to obtain the TrustAnchor container. It is likely to be 215 a URL, and is advisory only. 217 The Zone element in the TrustAnchor element states to which DNS zone 218 this container applies. The root zone is indicated by a single 219 period (.) character, without any quotation marks. 221 The TrustAnchor element contains one or more KeyDigest elements. 222 Each KeyDigest element represents the digest of a DNSKEY record in 223 the zone defined in the Zone element. 225 The id attribute in the KeyDigest element is an opaque string that 226 identifies the hash. Its value is used in the file names and URI of 227 the other trust anchor formats. This is described in Section 3.1. 228 For example, if the value of the id attribute in the KeyDigest 229 element is "Kjqmt7v", the URI for the CSR that is associated with 230 this hash will be . 231 Note that the id element in the KeyDigest element is different than 232 the id element in the TrustAnchor element, described above. 234 The validFrom and validUntil attributes in the KeyDigest element 235 specify the range of times that the KeyDigest element can be used as 236 a trust anchor. Note that the KeyDigest element is optional; if it 237 is not given, the trust anchor can be used until a KeyDigest element 238 covering the same DNSKEY record but having a validUntil attribute is 239 trusted by the relying party. Relying parties SHOULD NOT use a 240 KeyDigest outside of the time range given in the validFrom and 241 validUntil attributes. 243 The KeyTag element in the KeyDigest element contains the key tag for 244 the DNSKEY record represented in this KeyDigest. 246 The Algorithm element in the KeyDigest element contains the signing 247 algorithm identifier for the DNSKEY record represented in this 248 KeyDigest. 250 The DigestType element in the KeyDigest element contains the digest 251 algorithm identifier for the DNSKEY record represented in this 252 KeyDigest. 254 The Digest element in the KeyDigest element contains the hexadecimal 255 representation of the hash for the DNSKEY record represented in this 256 KeyDigest. 258 2.1.3. Converting from XML to DS Records 260 The display format for the DS record that is the equivalent of a 261 KeyDigest element can be constructed by marshaling the KeyTag, 262 Algorithm, DigestType, and Digest elements. For example, assume that 263 the TrustAnchor element contains: 265 266 269 . 270 271 19036 272 8 273 2 274 275 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 276 277 278 280 The DS record would be: 282 . IN DS 19036 8 2 283 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 285 2.1.4. XML Example 287 Figure 2 describes two fictitious trust anchors for the root zone. 289 291 294 . 295 298 34291 299 5 300 1 301 c8cb3d7fe518835490af8029c23efbce6b6ef3e2 302 303 305 12345 306 5 307 1 308 a3cf809dbdbc835716ba22bdc370d2efa50f21c7 309 310 312 Figure 2 314 2.2. Certificates 316 Each public key that can be used as a trust anchor is represented as 317 a certificate in PKIX format. Each certificate is signed by the 318 ICANN certificate authority. The SubjectPublicKeyInfo in the 319 certificate represents the public key of the KSK. The Subject field 320 has the following attributes: 322 O: the string "ICANN". 324 OU: the string "IANA". 326 CN: the string "Root Zone KSK" followed by the time and date of key 327 generation in the format specified in [RFC3339]. For example, a 328 CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00". 330 resourceRecord: a string in the presentation format of the 331 Delegation Signer (DS) [RFC4034] resource record for the DNSSEC 332 public key. 334 The "resourceRecord" attribute in the Subject is defined as follows: 336 ResourceRecord 337 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 338 mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) } 340 DEFINITIONS IMPLICIT TAGS ::= 342 BEGIN 344 -- EXPORTS ALL -- 346 IMPORTS 348 caseIgnoreMatch FROM SelectedAttributeTypes 349 { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 } 351 ; 353 iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 354 dod(6) internet(1) private(4) enterprise(1) 1000 } 356 iana-dns OBJECT IDENTIFIER ::= { iana 53 } 358 resourceRecord ATTRIBUTE ::= { 359 WITH SYNTAX IA5String 360 EQUALITY MATCHING RULE caseIgnoreIA5Match 361 ID iana-dns 362 } 364 END 366 2.3. Certificate Signing Requests 368 Each public key that can be used as a trust anchor is represented as 369 a certificate signing request (CSR) in PKCS#10 format. The 370 SubjectPublicKeyInfo and Subject field are the same as for 371 certificates (see Section 2.2 above). 373 3. Root Zone Trust Anchor Retrieval 375 3.1. Retrieving Trust Anchors with HTTPS and HTTP 377 Trust anchors are available for retrieval using HTTPS and HTTP. 379 In this section, all URLs are given using the "https:" scheme. If 380 HTTPS cannot be used, replace the "https:" scheme with "http:". 382 The URL for retrieving the set of hashes described in Section 2.1 is 383 . 385 The URL for retrieving the PKIX certificate described in Section 2.2 386 is , with the 387 string "KEYDIGEST-ID" replaced the "id" attribute from the KeyDigest 388 element from the XML file, as described in Section 2.1.2. 390 The URL for retrieving the CSR described in Section 2.3 is 391 , with the 392 string "KEYDIGEST-ID" replaced the "id" attribute from the KeyDigest 393 element from the XML file, as described in Section 2.1.2. 395 4. Accepting DNSSEC Trust Anchors 397 A validator operator can choose whether or not to accept the trust 398 anchors described in this document using whatever policy they want. 399 In order to help validator operators verify the content and origin of 400 trust anchors they receive, IANA uses digital signatures that chain 401 to an ICANN-controlled CA over the trust anchor data. 403 It is important to note that the ICANN CA is not a DNSSEC trust 404 anchor. Instead, it is an optional mechanism for verifying the 405 content and origin of the XML and certificate trust anchors. It is 406 also important to note that the ICANN CA cannot be used to verify the 407 origin of the trust anchor in the CSR format. 409 The content and origin of the XML file can be verified using a 410 digital signature on the file. IANA provides a detached CMS 411 [RFC5652] that chains to the ICANN CA with the XML file. The URL for 412 a detached CMS signature for the XML file is . 415 Another method IANA uses to help validator operators verify the 416 content and origin of trust anchors they receive is to use the TLS 417 protocol for distributing the trust anchors. Currently, the CA used 418 for data.iana.org is well-known, that is, one that is a WebTrust- 419 accredited Certificate Authority. If a system retrieving the trust 420 anchors trusts the CA that IANA uses for the "data.iana.org" web 421 server, HTTPS SHOULD be used instead of HTTP in order to have 422 assurance of data origin. 424 5. IANA Considerations 426 Key Signing Key (KSK) management for the root zone is an IANA 427 function. This document describes an initial set of publication 428 mechanisms for trust anchors related to that management. In the 429 future, additional publication schemes may also be made available, in 430 which case they will be described in a new document that updates this 431 one. 433 Section 2.2 serves as the reference for id-mod-dns-resource-record, 434 value 70, in the SMI Security for PKIX Module Identifier registry. 436 6. Security Considerations 438 This document describes how DNSSEC trust anchors for the root zone of 439 the DNS are published. Many DNSSEC clients will only configure IANA- 440 issued trust anchors for the DNS root to perform validation. As a 441 consequence, reliable publication of trust anchors is important. 443 This document aims to specify carefully the means by which such trust 444 anchors are published, as an aid to the formats and retrieval methods 445 described here being integrated usefully into user environments. 447 7. Acknowledgements 449 Many pioneers paved the way for the deployment of DNSSEC in the root 450 zone of the DNS, and the authors hereby acknowledge their substantial 451 collective contribution. 453 This document incorporates suggestions made by Alfred Hoenes, whose 454 contributions are appreciated. 456 8. References 458 8.1. Normative References 460 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 461 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 462 . 464 [RFC1035] Mockapetris, P., "Domain names - implementation and 465 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 466 November 1987, . 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 474 Request Syntax Specification Version 1.7", RFC 2986, 475 DOI 10.17487/RFC2986, November 2000, 476 . 478 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 479 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 480 . 482 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 483 Rose, "DNS Security Introduction and Requirements", 484 RFC 4033, DOI 10.17487/RFC4033, March 2005, 485 . 487 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 488 Rose, "Resource Records for the DNS Security Extensions", 489 RFC 4034, DOI 10.17487/RFC4034, March 2005, 490 . 492 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 493 Rose, "Protocol Modifications for the DNS Security 494 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 495 . 497 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 498 (DS) Resource Records (RRs)", RFC 4509, 499 DOI 10.17487/RFC4509, May 2006, 500 . 502 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 503 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 504 September 2007, . 506 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 507 Security (DNSSEC) Hashed Authenticated Denial of 508 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 509 . 511 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 512 Housley, R., and W. Polk, "Internet X.509 Public Key 513 Infrastructure Certificate and Certificate Revocation List 514 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 515 . 517 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 518 RFC 5652, DOI 10.17487/RFC5652, September 2009, 519 . 521 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 522 and RRSIG Resource Records for DNSSEC", RFC 5702, 523 DOI 10.17487/RFC5702, October 2009, 524 . 526 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 527 Operational Practices, Version 2", RFC 6781, 528 DOI 10.17487/RFC6781, December 2012, 529 . 531 8.2. Informative References 533 [DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, 534 "DNSSEC Practice Statement for the Root Zone KSK 535 Operator", October 2010, . 538 Appendix A. Historical Note 540 The first KSK for use in the root zone of the DNS was generated at a 541 key ceremony at an ICANN Key Management Facility (KMF) in Culpeper, 542 Virginia, USA on 2010-06-16. This key entered production during a 543 second key ceremony held at an ICANN KMF in El Segundo, California, 544 USA on 2010-07-12. The resulting trust anchor was first published on 545 2010-07-15. 547 Appendix B. About this Document 549 [RFC Editor: please remove this section, including all subsections, 550 prior to publication.] 552 B.1. Discussion 554 This document is not the product of any IETF working group. However, 555 communities interested in similar technical work can be found at the 556 IETF in the DNSOP and DNSEXT working groups. 558 The team responsible for deployment of DNSSEC in the root zone can be 559 reached at rootsign@icann.org. 561 The authors also welcome feedback sent to them directly. 563 Authors' Addresses 565 Joe Abley 566 Dyn, Inc. 567 470 Moore Street 568 London, ON N6C 2C2 569 Canada 571 Phone: +1 519 670 9327 572 Email: jabley@dyn.com 573 Jakob Schlyter 574 Kirei AB 576 Email: jakob@kirei.se 578 Guillaume Bailey 579 Independent 581 Email: GuillaumeBailey@outlook.com 583 Paul Hoffman 584 ICANN 586 Email: paul.hoffman@icann.org