rfc9718v1.txt		rfc9718.txt
	skipping to change at line 114 ¶		skipping to change at line 114 ¶
	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
	initial trust anchor that can be used by [RFC5011].		initial trust anchor that can be used by the mechanism defined in
			[RFC5011].
	This document obsoletes [RFC7958].		This document obsoletes [RFC7958].
	1.1. Definitions		1.1. Definitions
	The term "trust anchor" is used in many different contexts in the		The term "trust anchor" is used in many different contexts in the
	security community. Many of the common definitions conflict because		security community. Many of the common definitions conflict because
	they are specific to a specific system, such as just for DNSSEC or		they are specific to a specific system, such as just for DNSSEC or
	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		all common uses of the term "trust anchor" share the basic idea that
	the system that relies on it, is common to all the common uses of the		the decision to trust this entity is made outside of the system that
	term "trust anchor".		relies on it.
	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
	that contains the hashes of the DNSKEY records and optionally the		[W3C.REC-xml11-20060816] document that contains the hashes of the
	keys from the DNSKEY records.		DNSKEY records and optionally the keys from the DNSKEY records.
	This format and the associated semantics 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 website. 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
	skipping to change at line 211 ¶		skipping to change at line 212 ¶
	element Flags {		element Flags {
	xsd:nonNegativeInteger { maxInclusive = "65535" } }		xsd:nonNegativeInteger { maxInclusive = "65535" } }
	2.2. XML Semantics		2.2. XML Semantics
	The TrustAnchor element is the container for all of the trust anchors		The TrustAnchor element is the container for all of the trust anchors
	in the file.		in the file.
	The id attribute in the TrustAnchor element is an opaque string that		The id attribute in the TrustAnchor element is an opaque string that
	identifies the set of trust anchors. Its value has no particular		identifies the set of trust anchors. Its value has no particular
	semantics. Note that the id element in the TrustAnchor element is		semantics. Note that the id attribute in the TrustAnchor element is
	different than the id element in the KeyDigest element, described		different than the id attribute in the KeyDigest element described
	below.		below.
	The source attribute in the TrustAnchor element gives information		The source attribute in the TrustAnchor element gives information
	about where to obtain the TrustAnchor container. It is likely to be		about where to obtain the TrustAnchor container. It is likely to be
	a URL and is advisory only.		a URL and is advisory only.
	The Zone element in the TrustAnchor element states to which DNS zone		The Zone element in the TrustAnchor element states to which DNS zone
	this container applies. The element is in presentation format as		this container applies. The Zone element is in presentation format
	specified in [RFC1035], including the trailing dot. The root zone is		as specified in [RFC1035], including the trailing dot. The root zone
	indicated by a single period (.) character without any quotation		is indicated by a single period (.) character without any quotation
	marks.		marks.
	The TrustAnchor element contains one or more KeyDigest elements.		The TrustAnchor element contains one or more KeyDigest elements.
	Each KeyDigest element represents the digest of a past, current, or		Each KeyDigest element represents the digest of a past, current, or
	potential future DNSKEY record of the zone defined in the Zone		potential future DNSKEY record of the zone defined in the Zone
	element. The values for the elements in the KeyDigest element are		element. The values for the elements in the KeyDigest element are
	defined in [RFC4034]. The IANA registries for these values are		defined in [RFC4034]. The IANA registries for DNSSEC-related values
	described in [RFC9157].		are described in [RFC9157].
	The id attribute in the KeyDigest element is an opaque string that		The id attribute in the KeyDigest element is an opaque string that
	identifies the hash. Note that the id element in the KeyDigest		identifies the hash. Note that the id attribute in the KeyDigest
	element is different than the id element in the TrustAnchor element		element is different than the id attribute in the TrustAnchor element
	described above.		described above.
	The validFrom and validUntil attributes in the KeyDigest element		The validFrom and validUntil attributes in the KeyDigest element
	specify the range of times that the KeyDigest element can be used as		specify the range of times that the KeyDigest element can be used as
	a trust anchor.		a trust anchor.
	The KeyTag element in the KeyDigest element contains the key tag for		The KeyTag element in the KeyDigest element contains the key tag for
	the DNSKEY record represented in this KeyDigest.		the DNSKEY record represented in this KeyDigest.
	The Algorithm element in the KeyDigest element contains the DNSSEC		The Algorithm element in the KeyDigest element contains the DNSSEC
	skipping to change at line 267 ¶		skipping to change at line 268 ¶
	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 specification. It can be		pattern is optional and is new in this specification. It can be
	useful when IANA has a trust anchor that has not yet been published		useful when IANA has a trust anchor that has not yet been published
	in the DNS root and for calculating a comparison to the Digest		in the DNS root and for calculating a comparison to the Digest
	element.		element.
	2.3. XML Example		2.3. XML Example
	The following is an example of what an XML [W3C.REC-xml11-20060816]		The following is an example of what the trust anchor file might look
	document for a trust anchor might look like. The full public key is		like. The full public key is only given for a trust anchor that does
	only given for a trust anchor that does not have a validFrom ttime in		not have a validFrom time in the past.
	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 line 354 ¶		skipping to change at line 354 ¶
	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:".
	The URL for retrieving the set of hashes in the XML file described in		The URL for retrieving the set of hashes in the XML document
	Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>.		described in Section 2 is <https://data.iana.org/root-anchors/root-
			anchors.xml>.
	3.2. Accepting DNSSEC Trust Anchors		3.2. Accepting DNSSEC Trust Anchors
	A validator operator can choose whether or not to accept the trust		A validator operator can choose whether or not to accept the trust
	anchors described in this document using whatever policy they want.		anchors described in this document using whatever policy they want.
	In order to help validator operators verify the content and origin of		In order to help validator operators verify the content and origin of
	trust anchors they receive, IANA uses digital signatures that chain		trust anchors they receive, IANA uses digital signatures that chain
	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 document 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. This can be useful for validator		the ICANN CA with the XML document. This can be useful for validator
	operators who have received a copy of the ICANN CA's public key in a		operators who have received a copy of the ICANN CA's public key in a
	trusted out-of-band fashion. The URL for a detached CMS signature		trusted out-of-band fashion. The URL for a detached CMS signature
	for the XML file is <https://data.iana.org/root-anchors/root-		for the XML document is <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.
	skipping to change at line 474 ¶		skipping to change at line 475 ¶
	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 file accordingly
	accordingly by setting a validUntil date for that trust anchor. The		by setting a validUntil date for that trust anchor. The validUntil
	validUntil attribute that is added MAY be a date in the past or in		attribute that is added MAY be a date in the past or in the future,
	the future, depending on IANA's operational choices.		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/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 "SMI Security for PKIX Module Identifier" registry.		added to the "SMI Security for PKIX Module Identifier" registry.
	This document does not use that identifier.		This document does not use that identifier.
End of changes. 13 change blocks.
	29 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48.