]> Cloudflare

Amsterdam Netherlands jabley@cloudflare.com

Kirei AB

jakob@kirei.se

Independent

guillaumebailey@outlook.com

ICANN

paul.hoffman@icann.org

Internet-Draft 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.

Introduction The Domain Name System (DNS) is described in and . DNS Security Extensions (DNSSEC) are described in . 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 , which can be retrieved from the IANA Repository at <https://www.iana.org/dnssec/>. 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. 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 . 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 RFC 5011.

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 . 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 ; 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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Changes from RFC 7958 This version of the document includes the following changes: There is a signficant technical change from erratum 5932 <https://www.rfc-editor.org/errata/eid5932>. This is in the seventh paragraph of . The reference to the DNSSEC Practice Statement was updated.

IANA DNSSEC Root Zone Trust Anchor Formats and Semantics IANA publishes trust anchors for the root zone in three formats: an XML document that contains the hashes of the DNSKEY records certificates in PKIX format that contain DS records and the full public key of DNSKEY records Certificate Signing Requests (CSRs) in PKCS #10 format 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.

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 .

XML Syntax A RELAX NG Compact Schema for the documents used to publish trust anchors is given in Figure 1.

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. 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 . 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 <https://data.iana.org/root-anchors/Kjqmt7v.csr>. 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 validUntil attribute of the KeyDigest element is optional. If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the DNSKEY elements of the KeyDigest are the same as the previous trust anchor. 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.

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:

XML Example Figure 2 describes two fictitious trust anchors for the root zone.

. 34291 5 1 c8cb3d7fe518835490af8029c23efbce6b6ef3e2 12345 5 1 a3cf809dbdbc835716ba22bdc370d2efa50f21c7 Figure 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 . 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 resource record for the DNSSEC public key.

The "resourceRecord" attribute in the Subject is defined as follows:

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 above).

Root Zone Trust Anchor Retrieval

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:". The URL for retrieving the set of hashes described in is <https://data.iana.org/root-anchors/root-anchors.xml>. The URL for retrieving the PKIX certificate described in is <https://data.iana.org/root-anchors/KEYDIGEST-ID.crt>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in . The URL for retrieving the CSR described in is <https://data.iana.org/root-anchors/KEYDIGEST-ID.csr>, with the string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest element from the XML file, as described in .

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) signature that chains to the ICANN CA with the XML file. The URL for a detached CMS signature for the XML file is <https://data.iana.org/root-anchors/root-anchors.p7s>. [ Need to check with IANA on the paragraph below ] (IANA also provided a detached OpenPGP 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.

IANA Considerations This document defines id-mod-dns-resource-record, value 70 (see ), in the "SMI Security for PKIX Module Identifier" registry.

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.

This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK] Root Zone KSK Operator Policy Management Authority

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. The second KSK for use in the root zone of the DNS was [ MORE GOES HERE ].

Acknowledgemwents 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.