From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7958.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7958.txt (limited to 'doc/rfc/rfc7958.txt') diff --git a/doc/rfc/rfc7958.txt b/doc/rfc/rfc7958.txt new file mode 100644 index 0000000..34a1af4 --- /dev/null +++ b/doc/rfc/rfc7958.txt @@ -0,0 +1,787 @@ + + + + + + +Independent Submission J. Abley +Request for Comments: 7958 Dyn, Inc. +Category: Informational J. Schlyter +ISSN: 2070-1721 Kirei AB + G. Bailey + Independent + P. Hoffman + ICANN + August 2016 + + + DNSSEC Trust Anchor Publication for the Root Zone + +Abstract + + The root zone of the Domain Name System (DNS) has been + cryptographically signed using DNS Security Extensions (DNSSEC). + + In order to obtain secure answers from the root zone of the DNS using + DNSSEC, a client must configure a suitable trust anchor. This + document describes the format and publication mechanisms IANA has + used to distribute the DNSSEC trust anchors. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7958. + + + + + + + + + + + + + +Abley, et al. Informational [Page 1] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4 + 2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5 + 2.1.3. Converting from XML to DS Records . . . . . . . . . . 7 + 2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 8 + 2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8 + 2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9 + 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9 + 3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9 + 4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 7.2. Informative References . . . . . . . . . . . . . . . . . 13 + Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 14 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 2] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +1. Introduction + + The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. + DNS Security Extensions (DNSSEC) are described in [RFC4033], + [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]. + + A discussion of operational practices relating to DNSSEC can be found + in [RFC6781]. + + In the DNSSEC protocol, Resource Record Sets (RRSets) are signed + cryptographically. This means that a response to a query contains + signatures that allow the integrity and authenticity of the RRSet to + be verified. DNSSEC signatures are validated by following a chain of + signatures to a "trust anchor". The reason for trusting a trust + anchor is outside the DNSSEC protocol, but having one or more trust + anchors is required for the DNSSEC protocol to work. + + The publication of trust anchors for the root zone of the DNS is an + IANA function performed by ICANN. A detailed description of + corresponding key management practices can be found in [DPS], which + can be retrieved from the IANA Repository at + . + + This document describes the formats and distribution methods of + DNSSEC trust anchors that have been used by IANA for the root zone of + the DNS since 2010. Other organizations might have different formats + and mechanisms for distributing DNSSEC trust anchors for the root + zone; however, most operators and software vendors have chosen to + rely on the IANA trust anchors. + + It is important to note that at the time of this writing, IANA + intends to change the formats and distribution methods in the future. + If such a change happens, IANA will publish the changes on its web + site at . + + The formats and distribution methods described in this document are a + complement to, not a substitute for, the automated DNSSEC trust + anchor update protocol described in [RFC5011]. That protocol allows + for secure in-band succession of trust anchors when trust has already + been established. This document describes one way to establish an + initial trust anchor that can be used by [RFC5011]. + + + + + + + + + + +Abley, et al. Informational [Page 3] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +1.1. Definitions + + The term "trust anchor" is used in many different contexts in the + security community. Many of the common definitions conflict because + they are specific to a specific system, such as just for DNSSEC or + just for S/MIME messages. + + In cryptographic systems with hierarchical structure, a trust anchor + is an authoritative entity for which trust is assumed and not + derived. The format of the entity differs in different systems, but + the basic idea, that trust is assumed and not derived, is common to + all the common uses of the term "trust anchor". + + The root zone trust anchor formats published by IANA are defined in + Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY + RR or DS RR hash of a DNSKEY RR". Note that the formats defined here + do not match the definition of "trust anchor" from [RFC4033]; + however, a system that wants to convert the trusted material from + IANA into a Delegation Signer (DS) RR can do so. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics + + IANA publishes trust anchors for the root zone in three formats: + + o an XML document that contains the hashes of the DNSKEY records + + o certificates in PKIX format [RFC5280] that contain DS records and + the full public key of DNSKEY records + + o Certificate Signing Requests (CSRs) in PKCS #10 format [RFC2986] + that contain DS records and the full public key of DNSKEY records + + These formats and the semantics associated with each are described in + the rest of this section. + +2.1. Hashes in XML + + The XML document contains a set of hashes for the DNSKEY records that + can be used to validate the root zone. The hashes are consistent + with the defined presentation format of DS resource records from + [RFC4034]. + + + + + + +Abley, et al. Informational [Page 4] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +2.1.1. XML Syntax + + A RELAX NG Compact Schema [RELAX-NG] for the documents used to + publish trust anchors is given in Figure 1. + + datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" + + start = element TrustAnchor { + attribute id { xsd:string }, + attribute source { xsd:string }, + element Zone { xsd:string }, + + keydigest+ + } + + keydigest = element KeyDigest { + attribute id { xsd:string }, + attribute validFrom { xsd:dateTime }, + attribute validUntil { xsd:dateTime }?, + + element KeyTag { + xsd:nonNegativeInteger { maxInclusive = "65535" } }, + element Algorithm { + xsd:nonNegativeInteger { maxInclusive = "255" } }, + element DigestType { + xsd:nonNegativeInteger { maxInclusive = "255" } }, + element Digest { xsd:hexBinary } + } + + Figure 1 + +2.1.2. XML Semantics + + The TrustAnchor element is the container for all of the trust anchors + in the file. + + The id attribute in the TrustAnchor element is an opaque string that + identifies the set of trust anchors. Its value has no particular + semantics. Note that the id element in the TrustAnchor element is + different than the id element in the KeyDigest element, described + below. + + The source attribute in the TrustAnchor element gives information + about where to obtain the TrustAnchor container. It is likely to be + a URL and is advisory only. + + + + + + +Abley, et al. Informational [Page 5] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + + The Zone element in the TrustAnchor element states to which DNS zone + this container applies. The root zone is indicated by a single + period (.) character without any quotation marks. + + The TrustAnchor element contains one or more KeyDigest elements. + Each KeyDigest element represents the digest of a DNSKEY record in + the zone defined in the Zone element. + + The id attribute in the KeyDigest element is an opaque string that + identifies the hash. Its value is used in the file names and URI of + the other trust anchor formats. This is described in Section 3.1. + For example, if the value of the id attribute in the KeyDigest + element is "Kjqmt7v", the URI for the CSR that is associated with + this hash will be . + Note that the id element in the KeyDigest element is different than + the id element in the TrustAnchor element described above. + + The validFrom and validUntil attributes in the KeyDigest element + specify the range of times that the KeyDigest element can be used as + a trust anchor. Note that the KeyDigest element is optional; if it + is not given, the trust anchor can be used until a KeyDigest element + covering the same DNSKEY record, but having a validUntil attribute, + is trusted by the relying party. Relying parties SHOULD NOT use a + KeyDigest outside of the time range given in the validFrom and + validUntil attributes. + + The KeyTag element in the KeyDigest element contains the key tag for + the DNSKEY record represented in this KeyDigest. + + The Algorithm element in the KeyDigest element contains the signing + algorithm identifier for the DNSKEY record represented in this + KeyDigest. + + The DigestType element in the KeyDigest element contains the digest + algorithm identifier for the DNSKEY record represented in this + KeyDigest. + + The Digest element in the KeyDigest element contains the hexadecimal + representation of the hash for the DNSKEY record represented in this + KeyDigest. + + + + + + + + + + + +Abley, et al. Informational [Page 6] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +2.1.3. Converting from XML to DS Records + + The display format for the DS record that is the equivalent of a + KeyDigest element can be constructed by marshaling the KeyTag, + Algorithm, DigestType, and Digest elements. For example, assume that + the TrustAnchor element contains: + + + + . + + 19036 + 8 + 2 + + 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + + + + + The DS record would be: + + . IN DS 19036 8 2 + 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 + + + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 7] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +2.1.4. XML Example + + Figure 2 describes two fictitious trust anchors for the root zone. + + + + + . + + 34291 + 5 + 1 + c8cb3d7fe518835490af8029c23efbce6b6ef3e2 + + + 12345 + 5 + 1 + a3cf809dbdbc835716ba22bdc370d2efa50f21c7 + + + + Figure 2 + +2.2. Certificates + + Each public key that can be used as a trust anchor is represented as + a certificate in PKIX format. Each certificate is signed by the + ICANN certificate authority. The SubjectPublicKeyInfo in the + certificate represents the public key of the Key Signing Key (KSK). + The Subject field has the following attributes: + + O: the string "ICANN". + + OU: the string "IANA". + + CN: the string "Root Zone KSK" followed by the time and date of key + generation in the format specified in [RFC3339]. For example, a + CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00". + + resourceRecord: a string in the presentation format of the DS + [RFC4034] resource record for the DNSSEC public key. + + + + +Abley, et al. Informational [Page 8] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + + The "resourceRecord" attribute in the Subject is defined as follows: + + ResourceRecord + { iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) } + + DEFINITIONS IMPLICIT TAGS ::= + + BEGIN + + -- EXPORTS ALL -- + + IMPORTS + + caseIgnoreMatch FROM SelectedAttributeTypes + { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 } + + ; + + iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) + dod(6) internet(1) private(4) enterprise(1) 1000 } + + iana-dns OBJECT IDENTIFIER ::= { iana 53 } + + resourceRecord ATTRIBUTE ::= { + WITH SYNTAX IA5String + EQUALITY MATCHING RULE caseIgnoreMatch + ID iana-dns + } + + END + +2.3. Certificate Signing Requests + + Each public key that can be used as a trust anchor is represented as + a CSR in PKCS #10 format. The SubjectPublicKeyInfo and Subject field + are the same as for certificates (see Section 2.2 above). + +3. Root Zone Trust Anchor Retrieval + +3.1. Retrieving Trust Anchors with HTTPS and HTTP + + Trust anchors are available for retrieval using HTTPS and HTTP. + + In this section, all URLs are given using the "https:" scheme. If + HTTPS cannot be used, replace the "https:" scheme with "http:". + + + + + +Abley, et al. Informational [Page 9] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + + The URL for retrieving the set of hashes described in Section 2.1 is + . + + The URL for retrieving the PKIX certificate described in Section 2.2 + is , with the + string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest + element from the XML file, as described in Section 2.1.2. + + The URL for retrieving the CSR described in Section 2.3 is + , with the + string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest + element from the XML file, as described in Section 2.1.2. + +4. Accepting DNSSEC Trust Anchors + + A validator operator can choose whether or not to accept the trust + anchors described in this document using whatever policy they want. + In order to help validator operators verify the content and origin of + trust anchors they receive, IANA uses digital signatures that chain + to an ICANN-controlled Certificate Authority (CA) over the trust + anchor data. + + It is important to note that the ICANN CA is not a DNSSEC trust + anchor. Instead, it is an optional mechanism for verifying the + content and origin of the XML and certificate trust anchors. It is + also important to note that the ICANN CA cannot be used to verify the + origin of the trust anchor in the CSR format. + + The content and origin of the XML file can be verified using a + digital signature on the file. IANA provides a detached + Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to + the ICANN CA with the XML file. The URL for a detached CMS signature + for the XML file is + . + + (IANA also provided a detached OpenPGP [RFC4880] signature as a + second parallel verification mechanism for the first trust anchor + publication but has indicated that it will not use this parallel + mechanism in the future.) + + Another method IANA uses to help validator operators verify the + content and origin of trust anchors they receive is to use the + Transport Layer Security (TLS) protocol for distributing the trust + anchors. Currently, the CA used for data.iana.org is well known, + that is, one that is a WebTrust-accredited CA. If a system + retrieving the trust anchors trusts the CA that IANA uses for the + "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in + order to have assurance of data origin. + + + +Abley, et al. Informational [Page 10] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +5. IANA Considerations + + This document defines id-mod-dns-resource-record, value 70 (see + Section 2.2), in the "SMI Security for PKIX Module Identifier" + registry. + +6. Security Considerations + + This document describes how DNSSEC trust anchors for the root zone of + the DNS are published. Many DNSSEC clients will only configure IANA- + issued trust anchors for the DNS root to perform validation. As a + consequence, reliable publication of trust anchors is important. + + This document aims to specify carefully the means by which such trust + anchors are published, with the goal of making it easier for those + trust anchors to be integrated into user environments. + +7. References + +7.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification + Request Syntax Specification Version 1.7", RFC 2986, + DOI 10.17487/RFC2986, November 2000, + . + + [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: + Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, + . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + + + +Abley, et al. Informational [Page 11] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, DOI 10.17487/RFC4034, March 2005, + . + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, + DOI 10.17487/RFC4509, May 2006, + . + + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) + Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, + September 2007, . + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, + . + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, + . + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, + RFC 5652, DOI 10.17487/RFC5652, September 2009, + . + + [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY + and RRSIG Resource Records for DNSSEC", RFC 5702, + DOI 10.17487/RFC5702, October 2009, + . + + [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC + Operational Practices, Version 2", RFC 6781, + DOI 10.17487/RFC6781, December 2012, + . + + + + + + + + +Abley, et al. Informational [Page 12] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +7.2. Informative References + + [DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, + "DNSSEC Practice Statement for the Root Zone KSK + Operator", October 2015, + . + + [RELAX-NG] Clark, J., "RELAX NG Compact Syntax", + Committee Specification, November 2002, + . + + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, + DOI 10.17487/RFC4880, November 2007, + . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Abley, et al. Informational [Page 13] + +RFC 7958 Root Zone Trust Anchor Publication August 2016 + + +Appendix A. Historical Note + + The first KSK for use in the root zone of the DNS was generated at a + key ceremony at an ICANN Key Management Facility (KMF) in Culpeper, + Virginia, USA on 2010-06-16. This key entered production during a + second key ceremony held at an ICANN KMF in El Segundo, California, + USA on 2010-07-12. The resulting trust anchor was first published on + 2010-07-15. + +Acknowledgements + + Many pioneers paved the way for the deployment of DNSSEC in the root + zone of the DNS, and the authors hereby acknowledge their substantial + collective contribution. + + This document incorporates suggestions made by Alfred Hoenes and Russ + Housley, whose contributions are appreciated. + +Authors' Addresses + + Joe Abley + Dyn, Inc. + 300-184 York Street + London, ON N6A 1B5 + Canada + + Phone: +1 519 670 9327 + Email: jabley@dyn.com + + + Jakob Schlyter + Kirei AB + + Email: jakob@kirei.se + + + Guillaume Bailey + Independent + + Email: GuillaumeBailey@outlook.com + + + Paul Hoffman + ICANN + + Email: paul.hoffman@icann.org + + + + + +Abley, et al. Informational [Page 14] + -- cgit v1.2.3