Diff: rfc9718.original

	rfc9718.original	rfc9718.txt


	Network Working Group J. Abley	Internet Engineering Task Force (IETF) J. Abley
	Internet-Draft Cloudflare	Request for Comments: 9718 Cloudflare
	Obsoletes: 7958 (if approved) J. Schlyter	Obsoletes: 7958 J. Schlyter
	Intended status: Informational Kirei AB	Category: Informational Kirei AB
	Expires: 8 March 2025 G. Bailey	ISSN: 2070-1721 G. Bailey
	Independent	Independent
	P. Hoffman	P. Hoffman
	ICANN	ICANN

	4 September 2024	January 2025

	DNSSEC Trust Anchor Publication for the Root Zone	DNSSEC Trust Anchor Publication for the Root Zone

	draft-ietf-dnsop-rfc7958bis-06

	Abstract	Abstract

	The root zone of the global Domain Name System (DNS) is	The root zone of the global Domain Name System (DNS) is
	cryptographically signed using DNS Security Extensions (DNSSEC).	cryptographically signed using DNS Security Extensions (DNSSEC).

	In order to obtain secure answers from the root zone of the DNS using	In order to obtain secure answers from the root zone of the DNS using
	DNSSEC, a client must configure a suitable trust anchor. This	DNSSEC, a client must configure a suitable trust anchor. This
	document describes the format and publication mechanisms IANA uses to	document describes the format and publication mechanisms IANA uses to
	distribute the DNSSEC trust anchors.	distribute the DNSSEC trust anchors.

	This document obsoletes RFC 7958.	This document obsoletes RFC 7958.


	About This Document

	This note is to be removed before publishing as an RFC.

	Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/.

	Source for this draft and an issue tracker can be found at
	https://github.com/paulehoffman/draft-bash-rfc7958bis.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.	published for informational purposes.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Not all documents
		approved by the IESG are candidates for any level of Internet
		Standard; see Section 2 of RFC 7841.


	This Internet-Draft will expire on 8 March 2025.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9718.

	Copyright Notice	Copyright Notice


	Copyright (c) 2024 IETF Trust and the persons identified as the	Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal

	Provisions Relating to IETF Documents (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3	1.1. Definitions
	2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics . . . 4	2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics
	2.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 4	2.1. XML Syntax
	2.2. XML Semantics . . . . . . . . . . . . . . . . . . . . . . 5	2.2. XML Semantics
	2.3. XML Example . . . . . . . . . . . . . . . . . . . . . . . 7	2.3. XML Example
	3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 8	3. Root Zone Trust Anchor Retrieval
	3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 8	3.1. Retrieving Trust Anchors with HTTPS and HTTP
	3.2. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . 9	3.2. Accepting DNSSEC Trust Anchors
	3.3. Changes in the Trust Model for Distribution . . . . . . . 9	3.3. Changes in the Trust Model for Distribution
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10	4. Security Considerations
	4.1. Security Considerations for Relying Parties . . . . . . . 10	4.1. Security Considerations for Relying Parties
	4.1.1. validUntil . . . . . . . . . . . . . . . . . . . . . 10	4.1.1. validUntil
	4.1.2. Comparison of Digest and a publickeyinfo . . . . . . 10	4.1.2. Comparison of Digest and publickeyinfo
	4.1.3. Different Outputs from Processing the Trust Anchor	4.1.3. Different Outputs from Processing the Trust Anchor File
	File . . . . . . . . . . . . . . . . . . . . . . . . 11	5. IANA Considerations
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11	6. References
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	6.1. Normative References
	6.1. Normative References . . . . . . . . . . . . . . . . . . 11	6.2. Informative References
	6.2. Informative References . . . . . . . . . . . . . . . . . 12	Appendix A. Changes from RFC 7958
	Appendix A. Changes from RFC 7958 . . . . . . . . . . . . . . . 13	Appendix B. Historical Note
	Appendix B. Historical Note . . . . . . . . . . . . . . . . . . 13	Acknowledgements
	Appendix C. Acknowledgemwents . . . . . . . . . . . . . . . . . 14	Authors' Addresses
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14

	1. Introduction	1. Introduction

	The global Domain Name System (DNS) is described in [RFC1034] and	The global Domain Name System (DNS) is described in [RFC1034] and
	[RFC1035]. DNS Security Extensions (DNSSEC) are described in	[RFC1035]. DNS Security Extensions (DNSSEC) are described in
	[RFC9364].	[RFC9364].

	In the DNSSEC protocol, Resource Record Sets (RRSets) are signed	In the DNSSEC protocol, Resource Record Sets (RRSets) are signed
	cryptographically. This means that a response to a query contains	cryptographically. This means that a response to a query contains
	signatures that allow the integrity and authenticity of the RRSet to	signatures that allow the integrity and authenticity of the RRSet to

	skipping to change at page 3, line 25 ¶	skipping to change at line 103 ¶
	signatures to a "trust anchor". The reason for trusting a trust	signatures to a "trust anchor". The reason for trusting a trust
	anchor is outside the DNSSEC protocol, but having one or more trust	anchor is outside the DNSSEC protocol, but having one or more trust
	anchors is required for the DNSSEC protocol to work.	anchors is required for the DNSSEC protocol to work.

	The publication of trust anchors for the root zone of the DNS is an	The publication of trust anchors for the root zone of the DNS is an
	IANA function performed by ICANN, through its affiliate Public	IANA function performed by ICANN, through its affiliate Public
	Technical Identifiers (PTI). A detailed description of corresponding	Technical Identifiers (PTI). A detailed description of corresponding
	key management practices can be found in [DPS].	key management practices can be found in [DPS].

	This document describes the formats and distribution methods of	This document describes the formats and distribution methods of

	DNSSEC trust anchors that is used by IANA for the root zone of the	DNSSEC trust anchors that are used by IANA for the root zone of the
	DNS. Other organizations might have different formats and mechanisms	DNS. Other organizations might have different formats and mechanisms
	for distributing DNSSEC trust anchors for the root zone; however,	for distributing DNSSEC trust anchors for the root zone; however,
	most operators and software vendors have chosen to rely on the IANA	most operators and software vendors have chosen to rely on the IANA
	trust anchors.	trust anchors.

	The formats and distribution methods described in this document are a	The formats and distribution methods described in this document are a
	complement to, not a substitute for, the automated DNSSEC trust	complement to, not a substitute for, the automated DNSSEC trust
	anchor update protocol described in [RFC5011]. That protocol allows	anchor update protocol described in [RFC5011]. That protocol allows
	for secure in-band succession of trust anchors when trust has already	for secure in-band succession of trust anchors when trust has already
	been established. This document describes one way to establish an	been established. This document describes one way to establish an

	skipping to change at page 4, line 6 ¶	skipping to change at line 133 ¶
	just for S/MIME messages.	just for S/MIME messages.

	In cryptographic systems with hierarchical structure, a trust anchor	In cryptographic systems with hierarchical structure, a trust anchor
	is an authoritative entity for which trust is assumed and not	is an authoritative entity for which trust is assumed and not
	derived. The format of the entity differs in different systems, but	derived. The format of the entity differs in different systems, but
	the basic idea, the decision to trust this entity is made outside of	the basic idea, the decision to trust this entity is made outside of
	the system that relies on it, is common to all the common uses of the	the system that relies on it, is common to all the common uses of the
	term "trust anchor".	term "trust anchor".

	The root zone trust anchor formats published by IANA are defined in	The root zone trust anchor formats published by IANA are defined in

	Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY	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	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];	do not match the definition of "trust anchor" from [RFC4033];
	however, a system that wants to convert the trusted material from	however, a system that wants to convert the trusted material from
	IANA into a Delegation Signer (DS) RR can do so.	IANA into a Delegation Signer (DS) RR can do so.

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics	2. IANA DNSSEC Root Zone Trust Anchor Format and Semantics

	IANA publishes trust anchors for the root zone as an XML document	IANA publishes trust anchors for the root zone as an XML document
	that contains the hashes of the DNSKEY records and optionally the	that contains the hashes of the DNSKEY records and optionally the
	keys from the DNSKEY records.	keys from the DNSKEY records.


	This format and the semantics associated are described in the rest of	This format and the associated semantics are described in the rest of
	this section.	this section.

	Note that the XML document can have XML comments. For example, IANA	Note that the XML document can have XML comments. For example, IANA
	might use these comments to add pointers to important information on	might use these comments to add pointers to important information on

	the IANA web site. XML comments are only used as human-readable	the IANA website. XML comments are only used as human-readable
	commentary, not extensions to the grammar.	commentary, not extensions to the grammar.

	The XML document contains a set of hashes for the DNSKEY records that	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	can be used to validate the root zone. The hashes are consistent
	with the defined presentation format of a DS resource.	with the defined presentation format of a DS resource.


	The XML document also can contain the keys and flags from the DNSKEY	The XML document can also contain the keys and flags from the DNSKEY
	records. The keys and flags are consistent with the defined	records. The keys and flags are consistent with the defined
	presentation format of a DNSKEY resource.	presentation format of a DNSKEY resource.

	Note that the hashes are mandatory in the syntax, but the keys are	Note that the hashes are mandatory in the syntax, but the keys are
	optional.	optional.

	2.1. XML Syntax	2.1. XML Syntax


	A RELAX NG Compact Schema [RELAX-NG] for the documents used to	Below is the RELAX NG Compact Schema [RELAX-NG] for the documents
	publish trust anchors is:	used to publish trust anchors:

	datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"	datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"

	start = element TrustAnchor {	start = element TrustAnchor {
	attribute id { xsd:string },	attribute id { xsd:string },
	attribute source { xsd:string },	attribute source { xsd:string },
	element Zone { xsd:string },	element Zone { xsd:string },
	keydigest+	keydigest+
	}	}


	skipping to change at page 6, line 44 ¶	skipping to change at line 258 ¶
	The DigestType element in the KeyDigest element contains the DNSSEC	The DigestType element in the KeyDigest element contains the DNSSEC
	digest algorithm identifier for the DNSKEY record represented in this	digest algorithm identifier for the DNSKEY record represented in this
	KeyDigest.	KeyDigest.

	The Digest element in the KeyDigest element contains the hexadecimal	The Digest element in the KeyDigest element contains the hexadecimal
	representation of the hash for the DNSKEY record represented in this	representation of the hash for the DNSKEY record represented in this
	KeyDigest.	KeyDigest.

	The publickeyinfo named pattern in the KeyDigest element contains two	The publickeyinfo named pattern in the KeyDigest element contains two
	mandatory elements: the base64 representation of the public key for	mandatory elements: the base64 representation of the public key for

	the DNSKEY record represented in this KeyDigest, and the flags of the	the DNSKEY record represented in this KeyDigest and the flags of the
	DNSKEY record represented in this KeyDigest. The publickeyinfo named	DNSKEY record represented in this KeyDigest. The publickeyinfo named

	pattern is optional and is new in this version of the specification.	pattern is optional and is new in this specification. It can be
	It can be useful when IANA has a trust anchor that has not yet been	useful when IANA has a trust anchor that has not yet been published
	published in the DNS root, and for calculating a comparison to the	in the DNS root and for calculating a comparison to the Digest
	Digest element.	element.

	2.3. XML Example	2.3. XML Example


	The following is an example of what the trust anchor file might look	The following is an example of what an XML [W3C.REC-xml11-20060816]
	like. The full public key is only given for the trust anchor that	document for a trust anchor might look like. The full public key is
	does not have a validFrom ttime in the past.	only given for a trust anchor that does not have a validFrom ttime in
		the past.

	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B"	<TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B"
	source="http://data.iana.org/root-anchors/root-anchors.xml">	source="http://data.iana.org/root-anchors/root-anchors.xml">
	<Zone>.</Zone>	<Zone>.</Zone>
	<KeyDigest id="Kjqmt7v"	<KeyDigest id="Kjqmt7v"
	validFrom="2010-07-15T00:00:00+00:00"	validFrom="2010-07-15T00:00:00+00:00"
	validUntil="2019-01-11T00:00:00+00:00"> <!-- This key	validUntil="2019-01-11T00:00:00+00:00"> <!-- This key
	is no longer valid, since validUntil is in the past -->	is no longer valid, since validUntil is in the past -->
	<KeyTag>19036</KeyTag>	<KeyTag>19036</KeyTag>

	skipping to change at page 8, line 4 ¶	skipping to change at line 314 ¶
	<!-- The following is called "KSK-2024" as a shorthand name -->	<!-- The following is called "KSK-2024" as a shorthand name -->
	<KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00">	<KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00">
	<KeyTag>38696</KeyTag>	<KeyTag>38696</KeyTag>
	<Algorithm>8</Algorithm>	<Algorithm>8</Algorithm>
	<DigestType>2</DigestType>	<DigestType>2</DigestType>
	<Digest>	<Digest>
	683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16	683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
	</Digest>	</Digest>
	</KeyDigest>	</KeyDigest>
	</TrustAnchor>	</TrustAnchor>

	The DS RRset derived from this example would be:
		The DS RRset derived from this example is:

	. IN DS 20326 8 2	. IN DS 20326 8 2
	E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D	E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
	. IN DS 38696 8 2	. IN DS 38696 8 2
	683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16	683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16


	Note that this DS record set only has two records. The potential	Note that this DS record set only has two records. A potential third
	third record, the one that would have included the key tag 19036, is	record, one that includes the key tag 19036, is already invalid based
	already invalid based on the validUntil attribute's value and is thus	on the validUntil attribute's value and is thus not part of the trust
	not part of the trust anchor set.	anchor set.


	The DNSKEY RRset derived from this example would be:	The DNSKEY RRset derived from this example is:

	. IN DNSKEY 257 3 8	. IN DNSKEY 257 3 8
	AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3	AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
	+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv	+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
	ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF	ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
	0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e	0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
	oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd	oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
	RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN	RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
	R1AkUTV74bU=	R1AkUTV74bU=


	Note that this DNSKEY record set only has one record. One potential	Note that this DNSKEY record set only has one record. A potential
	second record, the one that would have been based on the key tag	second record, one based on the key tag 19036, is already invalid
	19036, is already invalid based on the validUntil attribute's value	based on the validUntil attribute's value and is thus not part of the
	and is thus not part of the trust anchor set. The other potential	trust anchor set. Another potential second record, one based on the
	second record, the one that would have been based on the key tag	key tag 38696, does not contain the optional publickeyinfo named
	38696, does not contain the optional publickeyinfo named pattern and	pattern; therefore, the DNSKEY record for it cannot be calculated.
	therefore the DNSKEY record for it cannot be calculated.

	3. Root Zone Trust Anchor Retrieval	3. Root Zone Trust Anchor Retrieval

	3.1. Retrieving Trust Anchors with HTTPS and HTTP	3.1. Retrieving Trust Anchors with HTTPS and HTTP

	Trust anchors are available for retrieval using 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	In this section, all URLs are given using the "https:" scheme. If
	HTTPS cannot be used, replace the "https:" scheme with "http:".	HTTPS cannot be used, replace the "https:" scheme with "http:".


	skipping to change at page 9, line 21 ¶	skipping to change at line 373 ¶
	to an ICANN-controlled Certificate Authority (CA) over the trust	to an ICANN-controlled Certificate Authority (CA) over the trust
	anchor data.	anchor data.

	It is important to note that the ICANN CA is not a DNSSEC trust	It is important to note that the ICANN CA is not a DNSSEC trust
	anchor. Instead, it is an optional mechanism for verifying the	anchor. Instead, it is an optional mechanism for verifying the
	content and origin of the XML and certificate trust anchors.	content and origin of the XML and certificate trust anchors.

	The content and origin of the XML file can be verified using a	The content and origin of the XML file can be verified using a
	digital signature on the file. IANA provides a detached	digital signature on the file. IANA provides a detached
	Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to	Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to

	the ICANN CA with the XML file.	the ICANN CA with the XML file. This can be useful for validator
	This can be useful for validator operators who have received a copy	operators who have received a copy of the ICANN CA's public key in a
	of the ICANN CA's public key in a trusted out-of-band fashion. The	trusted out-of-band fashion. The URL for a detached CMS signature
	URL for a detached CMS signature for the XML file is	for the XML file is <https://data.iana.org/root-anchors/root-
	<https://data.iana.org/root-anchors/root-anchors.p7s>.	anchors.p7s>.

	Another method IANA uses to help validator operators verify the	Another method IANA uses to help validator operators verify the
	content and origin of trust anchors they receive is to use the	content and origin of trust anchors they receive is to use the
	Transport Layer Security (TLS) protocol for distributing the trust	Transport Layer Security (TLS) protocol for distributing the trust

	anchors. Currently, the CA used for data.iana.org is well known,	anchors. Currently, the CA used for "data.iana.org" is well known,
	that is, one that is a WebTrust-accredited CA. If a system	that is, one that is a WebTrust-accredited CA. If a system
	retrieving the trust anchors trusts the CA that IANA uses for the	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	"data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in
	order to have assurance of data origin.	order to have assurance of data origin.

	3.3. Changes in the Trust Model for Distribution	3.3. Changes in the Trust Model for Distribution


	IANA used to distribute the trust anchors as a self-signed PGP	IANA used to distribute trust anchors as a self-signed Pretty Good
	message and as a self-issued certificate signing request; this was	Privacy (PGP) message and as a self-issued certificate signing
	described in [RFC7958]. This document removes those methods because	request; this was described in [RFC7958]. This document removes
	they relied on a trust model that mixed out-of-band trust of	those methods because they rely on a trust model that mixes out-of-
	authentication keys with out-of-band trust of the DNSSEC root keys.	band trust of authentication keys with out-of-band trust of the
	Note, however, that cryptographic assurance for the contents of the	DNSSEC root keys. Note, however, that cryptographic assurance for
	trust anchor now comes from the web PKI or the ICANN CA as described	the contents of the trust anchor now comes from the Web PKI or the
	in Section 3.2. This cryptographic assurance is bolstered by	ICANN CA as described in Section 3.2. This cryptographic assurance
	informal comparisons made by users of the trust anchors, such as	is bolstered by informal comparisons made by users of the trust
	software vendors comparing the trust anchor files they are using.	anchors, such as software vendors comparing the trust anchor files
		they are using.

	4. Security Considerations	4. Security Considerations

	This document describes how DNSSEC trust anchors for the root zone of	This document describes how DNSSEC trust anchors for the root zone of
	the DNS are published. Many DNSSEC clients will only configure IANA-	the DNS are published. Many DNSSEC clients will only configure IANA-
	issued trust anchors for the DNS root to perform validation. As a	issued trust anchors for the DNS root to perform validation. As a
	consequence, reliable publication of trust anchors is important.	consequence, reliable publication of trust anchors is important.

	This document aims to specify carefully the means by which such trust	This document aims to specify carefully the means by which such trust
	anchors are published, with the goal of making it easier for those	anchors are published, with the goal of making it easier for those
	trust anchors to be integrated into user environments. Some of the	trust anchors to be integrated into user environments. Some of the

	methods described (such as accessing over the web with or without	methods described (such as accessing over the Web with or without
	verifying the signature on the file) have different security	verifying the signature on the file) have different security
	properties; users of the trust anchor file need to consider these	properties; users of the trust anchor file need to consider these
	when choosing whether to load the set of trust anchors.	when choosing whether to load the set of trust anchors.

	4.1. Security Considerations for Relying Parties	4.1. Security Considerations for Relying Parties

	The body of this document does not specify any particular behavior	The body of this document does not specify any particular behavior

	for relying parties. In specific, it does not say how a relying	for relying parties. Specifically, it does not say how a relying
	party should treat the trust anchor file as a whole. However, some	party should treat the trust anchor file as a whole. However, some
	of the contents of the trust anchor file require particular attention	of the contents of the trust anchor file require particular attention
	for relying parties.	for relying parties.

	4.1.1. validUntil	4.1.1. validUntil

	Note that the validUntil attribute of the KeyDigest element is	Note that the validUntil attribute of the KeyDigest element is
	optional. If the relying party is using a trust anchor that has a	optional. If the relying party is using a trust anchor that has a
	KeyDigest element that does not have a validUntil attribute, it can	KeyDigest element that does not have a validUntil attribute, it can
	change to a trust anchor with a KeyDigest element that does have a	change to a trust anchor with a KeyDigest element that does have a
	validUntil attribute, as long as that trust anchor's validUntil	validUntil attribute, as long as that trust anchor's validUntil
	attribute is in the future and the KeyTag, Algorithm, DigestType, and	attribute is in the future and the KeyTag, Algorithm, DigestType, and

	Digest elements of the KeyDigest are the same as the previous trust	Digest elements of the KeyDigest are the same as those in the
	anchor.	previous trust anchor.

	Relying parties SHOULD NOT use a KeyDigest outside of the time range	Relying parties SHOULD NOT use a KeyDigest outside of the time range
	given in the validFrom and validUntil attributes.	given in the validFrom and validUntil attributes.


	4.1.2. Comparison of Digest and a publickeyinfo	4.1.2. Comparison of Digest and publickeyinfo

	A KeyDigest element can contain both a Digest and a publickeyinfo	A KeyDigest element can contain both a Digest and a publickeyinfo
	named pattern. If the Digest element would not be a proper DS record	named pattern. If the Digest element would not be a proper DS record
	for a DNSKEY record represented by the publickeyinfo named pattern,	for a DNSKEY record represented by the publickeyinfo named pattern,
	relying parties MUST NOT use that KeyDigest as a trust anchor. A	relying parties MUST NOT use that KeyDigest as a trust anchor. A

	relying party that wants to make such a comparison needs to marshall	relying party that wants to make such a comparison needs to marshal
	the elements of the DNSKEY record that became the DS record using the	the elements of the DNSKEY record that became the DS record using the
	algorithm specified in Section 5.1.4 of [RFC4034].	algorithm specified in Section 5.1.4 of [RFC4034].

	Relying parties need to implement trust anchor matching carefully. A	Relying parties need to implement trust anchor matching carefully. A
	single trust anchor represented by a KeyDigest element can	single trust anchor represented by a KeyDigest element can
	potentially change its Digest and KeyTag values between two versions	potentially change its Digest and KeyTag values between two versions

	of the trust anchor file, for example when the key is revoked or the	of the trust anchor file, for example, when the key is revoked or the
	flag value changes for some other reason. Relying parties which fail	flag value changes for some other reason. Relying parties that fail
	to take this property into account are at risk of using an incorrect	to take this property into account are at risk of using an incorrect
	set of trust anchors.	set of trust anchors.

	4.1.3. Different Outputs from Processing the Trust Anchor File	4.1.3. Different Outputs from Processing the Trust Anchor File

	Relying parties that require the optional publickeyinfo named pattern	Relying parties that require the optional publickeyinfo named pattern

	to create trust anchors will store fewer trust anhcors than those	to create trust anchors will store fewer trust anchors than those
	that only require a Digest element. Thus, two systems processing the	that only require a Digest element. Thus, two systems processing the
	same trust anchor file can end up with a different set of trust	same trust anchor file can end up with a different set of trust
	anchors.	anchors.

	5. IANA Considerations	5. IANA Considerations

	Each time IANA produces a new trust anchor, it MUST publish that	Each time IANA produces a new trust anchor, it MUST publish that
	trust anchor using the format described in this document.	trust anchor using the format described in this document.

	IANA MAY delay the publication of a new trust anchor for operational	IANA MAY delay the publication of a new trust anchor for operational

	reasons, such as having a newly-created key in multiple facilities.	reasons, such as having a newly created key in multiple facilities.

	When a trust anchor that was previously published is no longer	When a trust anchor that was previously published is no longer
	suitable for use, IANA MUST update the trust anchor document	suitable for use, IANA MUST update the trust anchor document
	accordingly by setting a validUntil date for that trust anchor. The	accordingly by setting a validUntil date for that trust anchor. The
	validUntil attribute that is added MAY be a date in the past or in	validUntil attribute that is added MAY be a date in the past or in
	the future, depending on IANA's operational choices.	the future, depending on IANA's operational choices.

	More information about IANA's policies and procedures for how the	More information about IANA's policies and procedures for how the
	cryptographic keys for the DNS root zone are managed (also known as	cryptographic keys for the DNS root zone are managed (also known as
	"DNSSEC Practice Statements" or "DPSs") can be found at	"DNSSEC Practice Statements" or "DPSs") can be found at

	https://www.iana.org/dnssec/procedures (https://www.iana.org/dnssec/	<https://www.iana.org/dnssec/procedures>.
	procedures).

	[RFC7958] defined id-mod-dns-resource-record, value 70, which was	[RFC7958] defined id-mod-dns-resource-record, value 70, which was

	added to the the "SMI Security for PKIX Module Identifier" registry.	added to the "SMI Security for PKIX Module Identifier" registry.
	This document no longer uses that identifier.	This document does not use that identifier.

	6. References	6. References

	6.1. Normative References	6.1. Normative References

	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

	<https://www.rfc-editor.org/rfc/rfc1034>.	<https://www.rfc-editor.org/info/rfc1034>.

	[RFC1035] Mockapetris, P., "Domain names - implementation and	[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,

	November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.	November 1987, <https://www.rfc-editor.org/info/rfc1035>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,

	<https://www.rfc-editor.org/rfc/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",	Rose, "DNS Security Introduction and Requirements",
	RFC 4033, DOI 10.17487/RFC4033, March 2005,	RFC 4033, DOI 10.17487/RFC4033, March 2005,

	<https://www.rfc-editor.org/rfc/rfc4033>.	<https://www.rfc-editor.org/info/rfc4033>.

	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",	Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,	RFC 4034, DOI 10.17487/RFC4034, March 2005,

	<https://www.rfc-editor.org/rfc/rfc4034>.	<https://www.rfc-editor.org/info/rfc4034>.

	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)	[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
	Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,	Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,

	September 2007, <https://www.rfc-editor.org/rfc/rfc5011>.	September 2007, <https://www.rfc-editor.org/info/rfc5011>.

	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
	RFC 5652, DOI 10.17487/RFC5652, September 2009,	RFC 5652, DOI 10.17487/RFC5652, September 2009,

	<https://www.rfc-editor.org/rfc/rfc5652>.	<https://www.rfc-editor.org/info/rfc5652>.

	[RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,	[RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman,
	"DNSSEC Trust Anchor Publication for the Root Zone",	"DNSSEC Trust Anchor Publication for the Root Zone",
	RFC 7958, DOI 10.17487/RFC7958, August 2016,	RFC 7958, DOI 10.17487/RFC7958, August 2016,

	<https://www.rfc-editor.org/rfc/rfc7958>.	<https://www.rfc-editor.org/info/rfc7958>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC",	[RFC9157] Hoffman, P., "Revised IANA Considerations for DNSSEC",
	RFC 9157, DOI 10.17487/RFC9157, December 2021,	RFC 9157, DOI 10.17487/RFC9157, December 2021,

	<https://www.rfc-editor.org/rfc/rfc9157>.	<https://www.rfc-editor.org/info/rfc9157>.

	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
	RFC 9364, DOI 10.17487/RFC9364, February 2023,	RFC 9364, DOI 10.17487/RFC9364, February 2023,

	<https://www.rfc-editor.org/rfc/rfc9364>.	<https://www.rfc-editor.org/info/rfc9364>.

		[W3C.REC-xml11-20060816]
		Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
		Yergeau, F., and J. Cowan, "Extensible Markup Language
		(XML) 1.1 (Second Edition)", W3C Recommendation REC-
		xml11-20060816, 16 August 2006,
		<https://www.w3.org/TR/2006/REC-xml11-20060816>.

	6.2. Informative References	6.2. Informative References

	[DPS] Root Zone KSK Operator Policy Management Authority,	[DPS] Root Zone KSK Operator Policy Management Authority,
	"DNSSEC Practice Statement for the Root Zone KSK	"DNSSEC Practice Statement for the Root Zone KSK

	Operator", n.d., <https://www.iana.org/dnssec/procedures>.	Operator", <https://www.iana.org/dnssec/procedures>.


	[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", 2002,	[RELAX-NG] Clark, J., "RELAX NG Compact Syntax", OASIS Committee
	<https://www.oasis-open.org/committees/relax-ng/compact-	Specification, November 2002, <https://www.oasis-
	20021121.html>.	open.org/committees/relax-ng/compact-20021121.html>.

	Appendix A. Changes from RFC 7958	Appendix A. Changes from RFC 7958


	This version of the document includes the following changes:	This document includes the following changes:


	* There is a significant technical change from erratum 5932	* Made a significant technical change per Erratum ID 5932
	<https://www.rfc-editor.org/errata/eid5932>. This is in the	<https://www.rfc-editor.org/errata/eid5932>. This change is in
	seventh paragraph of Section 2.2.	the seventh paragraph of Section 2.2.

	* Added the optional publickeyinfo named pattern with two mandatory	* Added the optional publickeyinfo named pattern with two mandatory
	elements, PublicKey and Flags.	elements, PublicKey and Flags.

	* Removed the certificates and certificate signing mechanisms.	* Removed the certificates and certificate signing mechanisms.

	* Removed the detached OpenPGP signature mechanism.	* Removed the detached OpenPGP signature mechanism.


	* The reference to the DNSSEC Practice Statement [DPS] was updated.	* Updated the reference to the DNSSEC Practice Statement [DPS].


	* Say explicitly that the XML documents might have XML comments in	* Stated explicitly that the XML documents might have XML comments
	them.	in them.

	* Clarified the use of the detached CMS signature.	* Clarified the use of the detached CMS signature.

	* Updated the IANA Considerations section to indicate requirements	* Updated the IANA Considerations section to indicate requirements
	on IANA.	on IANA.

	* Simplified the description of using the validFrom and validUntil	* Simplified the description of using the validFrom and validUntil
	attributes.	attributes.

	* Added new security considerations.	* Added new security considerations.


	* There was a bit of editorial cleanup.	* Made some editorial changes.

	Appendix B. Historical Note	Appendix B. Historical Note


	The first KSK for use in the root zone of the DNS was generated at a	The first Key Signing Key (KSK) for use in the root zone of the DNS
	key ceremony at the ICANN Key Management Facility (KMF) in Culpeper,	was generated at a key ceremony at the ICANN Key Management Facility
	Virginia, USA on 2010-06-16. This key entered production during a	(KMF) in Culpeper, Virginia, USA on 2010-06-16. This key entered
	second key ceremony held at an ICANN KMF in El Segundo, California,	production during a second key ceremony held at an ICANN KMF in El
	USA on 2010-07-12. The resulting trust anchor was first published on	Segundo, California, USA on 2010-07-12. The resulting trust anchor
	2010-07-15.	was first published on 2010-07-15.

	The second KSK for use in the root zone of the DNS was generated at	The second KSK for use in the root zone of the DNS was generated at
	key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on	key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on
	2016-10-27. This key entered production during key ceremony #28 held	2016-10-27. This key entered production during key ceremony #28 held
	at the ICANN KMF in El Segundo, California, USA on 2017-02-02. The	at the ICANN KMF in El Segundo, California, USA on 2017-02-02. The
	resulting trust anchor was first published on 2018-11-11.	resulting trust anchor was first published on 2018-11-11.

	More information about the key ceremonies, including full records of	More information about the key ceremonies, including full records of
	previous ceremonies and plans for future ceremonies, can be found at	previous ceremonies and plans for future ceremonies, can be found at
	<https://www.iana.org/dnssec/ceremonies>.	<https://www.iana.org/dnssec/ceremonies>.


	Appendix C. Acknowledgemwents	Acknowledgements

	Many pioneers paved the way for the deployment of DNSSEC in the root	Many pioneers paved the way for the deployment of DNSSEC in the root
	zone of the DNS, and the authors hereby acknowledge their substantial	zone of the DNS, and the authors hereby acknowledge their substantial
	collective contribution.	collective contribution.

	RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ	RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ
	Housley, whose contributions are appreciated.	Housley, whose contributions are appreciated.

	Authors' Addresses	Authors' Addresses


End of changes. 56 change blocks.
	149 lines changed or deleted	145 lines changed or added
This html diff was produced by rfcdiff 1.48.