<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-rfc7958bis-06" number="9718" category="info" consensus="true" submissionType="IETF" updates="" obsoletes="7958" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.23.0 -->version="3" xml:lang="en"> <front> <title abbrev="Root Zone Trust Anchor Publication">DNSSEC Trust Anchor Publication for the Root Zone</title> <seriesInfoname="Internet-Draft" value="draft-ietf-dnsop-rfc7958bis-06"/>name="RFC" value="9718"/> <author initials="J." surname="Abley" fullname="Joe Abley"> <organization>Cloudflare</organization> <address> <postal> <city>Amsterdam</city> <country>Netherlands</country> </postal> <email>jabley@cloudflare.com</email> </address> </author> <author initials="J." surname="Schlyter" fullname="Jakob Schlyter"> <organization>Kirei AB</organization> <address> <email>jakob@kirei.se</email> </address> </author> <author initials="G." surname="Bailey" fullname="Guillaume Bailey"> <organization>Independent</organization> <address> <email>guillaumebailey@outlook.com</email> </address> </author> <author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <organization>ICANN</organization> <address> <email>paul.hoffman@icann.org</email> </address> </author> <dateyear="2024" month="September" day="04"/>year="2025" month="January"/> <area>OPS</area> <workgroup>dnsop</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 70?><t>The root zone of the global Domain Name System (DNS) is cryptographically signed using DNS Security Extensions (DNSSEC).</t> <t>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 uses to distribute the DNSSEC trust anchors.</t> <t>This document obsoletes RFC 7958.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/paulehoffman/draft-bash-rfc7958bis"/>.</t> </note></front> <middle><?line 81?><section anchor="introduction"> <name>Introduction</name> <t>The global Domain Name System (DNS) is described in <xref target="RFC1034"/> and <xref target="RFC1035"/>. DNS Security Extensions (DNSSEC) are described in <xref target="RFC9364"/>.</t> <t>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.</t> <t>The publication of trust anchors for the root zone of the DNS is an IANA function performed by ICANN, through its affiliate Public Technical Identifiers (PTI). A detailed description of corresponding key management practices can be found in <xref target="DPS"/>.</t> <t>This document describes the formats and distribution methods of DNSSEC trust anchors thatisare used by IANA for the root zone of the DNS. 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.</t> <!-- [rfced] The following sentence appeared in RFC 7958, but we question if "can be used by [RFC5011]" could be improved. Please review. Original: This document describes one way to establish an initial trust anchor that can be used by [RFC5011]. Perhaps: This document describes one way to establish an initial trust anchor that can be used by the mechanism defined in [RFC5011]. --> <t>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 <xref target="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 <xref target="RFC5011"/>.</t> <t>This document obsoletes <xref target="RFC7958"/>.</t> <section anchor="definitions"> <name>Definitions</name> <t>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.</t> <!-- [rfced] How may we update the text starting with "but the basic idea.." to improve clarity? Original: The format of the entity differs in different systems, but 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 term "trust anchor". Perhaps: The format of the entity differs in different systems, but the basic idea that the decision to trust this entity is made outside of the system that relies on it is shared by all the common uses of the term "trust anchor". Or: The format of the entity differs in different systems, but all common uses of the term "trust anchor" share the basic idea that the decision to trust this entity is made outside of the system that relies on it. --> <t>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, 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 term "trust anchor".</t> <t>The root zone trust anchor formats published by IANA are defined in <xref target="ta_formats"/>. <xref target="RFC4033"/> defines a trust anchor as"A configureda "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 <xref target="RFC4033"/>; however, a system that wants to convert the trusted material from IANA into a Delegation Signer (DS) RR can do so.</t><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> </section> <section anchor="ta_formats"> <name>IANA DNSSEC Root Zone Trust Anchor Format and Semantics</name> <t>IANA publishes trust anchors for the root zone as an XML document that contains the hashes of the DNSKEY records and optionally the keys from the DNSKEY records.</t> <t>This format and thesemanticsassociated semantics are described in the rest of this section.</t> <t>Note that the XML document can have XML comments. For example, IANA might use these comments to add pointers to important information on the IANAweb site.website. XML comments are only used as human-readable commentary, not extensions to the grammar.</t> <t>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 a DS resource.</t> <t>The XML documentalsocan also contain the keys and flags from the DNSKEY records. The keys and flags are consistent with the defined presentation format of a DNSKEY resource.</t> <t>Note that the hashes are mandatory in the syntax, but the keys are optional.</t> <section anchor="xml_syntax"> <name>XML Syntax</name><t>A<t>Below is the RELAX NG Compact Schema <xref target="RELAX-NG"/> for the documents used to publish trustanchors is:</t> <artwork><![CDATA[anchors:</t> <sourcecode type="rnc"><![CDATA[ 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 }, publickeyinfo? } publickeyinfo = element PublicKey { xsd:base64Binary }, element Flags { xsd:nonNegativeInteger { maxInclusive = "65535" } }]]></artwork>]]></sourcecode> </section> <section anchor="xml_semantics"> <name>XML Semantics</name> <t>The <tt>TrustAnchor</tt> element is the container for all of the trust anchors in the file.</t> <t>The <tt>id</tt> 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 <tt>id</tt> element in the TrustAnchor element is different than the <tt>id</tt> element in the KeyDigest element, described below.</t> <t>The <tt>source</tt> 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.</t> <!-- [rfced] In the second sentence below, would it be helpful to specify which element is in presentation format? The first sentence mentions two elements (Zone and TrustAnchor). Original: The Zone element in the TrustAnchor element states to which DNS zone this container applies. The element is in presentation format as specified in [RFC1035], including the trailing dot. The root zone is indicated by a single period (.) character without any quotation marks. --> <t>The Zone element in the TrustAnchor element states to which DNS zone this container applies. The element is in presentation format as specified in <xref target="RFC1035"/>, including the trailing dot. The root zone is indicated by a single period (.) character without any quotation marks.</t> <!-- [rfced] We have a couple of questions about this text: Original: Each KeyDigest element represents the digest of a past, current, or potential future DNSKEY record of the zone defined in the Zone element. The values for the elements in the KeyDigest element are defined in [RFC4034]. The IANA registries for these values are described in [RFC9157]. a) Second sentence above - RFC 4034 mentions "DNSKEY", and we see a number of values mentioned throughout that document; however, we do not see "KeyDigest". Will readers know which values/elements in the KeyDigest element are defined in RFC 4034? Would it be helpful to specify these or point to a specific section in RFC 4034? b) Last sentence above - We see several registries mentioned in RFC 9157 (see notes below). Would it be helpful to specify which registries this sentence refers to? We see references to RFC 4034 in some of these registries but not all. These registry groups are mentioned in Section 4 of RFC 9157: - "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters" (https://www.iana.org/assignments/dnssec-nsec3-parameters) - "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" (https://www.iana.org/assignments/ds-rr-types/) These registries within the above registry groups are also mentioned: - DNSSEC NSEC3 Flags - DNSSEC NSEC3 Hash Algorithms - DNSSEC NSEC3PARAM Flags - Digest Algorithms We also see that Section 3 of RFC 9157 includes a citation to the following registry in the OLD/NEW text, but we had to look at RFC 8624 to see the name of the registry: [DNSKEY-IANA] - "Domain Name System Security (DNSSEC) Algorithm Numbers" (http://www.iana.org/assignments/dns-sec-alg-numbers) --> <t>The TrustAnchor element contains one or more KeyDigest elements. Each KeyDigest element represents the digest of a past, current, or potential future DNSKEY record of the zone defined in the Zone element. The values for the elements in the KeyDigest element are defined in <xref target="RFC4034"/>. The IANA registries for these values are described in <xref target="RFC9157"/>.</t> <t>The <tt>id</tt> attribute in the KeyDigest element is an opaque string that identifies the hash. Note that the <tt>id</tt> element in the KeyDigest element is different than the <tt>id</tt> element in the TrustAnchor element described above.</t> <t>The <tt>validFrom</tt> and <tt>validUntil</tt> attributes in the KeyDigest element specify the range of times that the KeyDigest element can be used as a trust anchor.</t> <t>The KeyTag element in the KeyDigest element contains the key tag for the DNSKEY record represented in this KeyDigest.</t> <t>The Algorithm element in the KeyDigest element contains the DNSSEC signing algorithm identifier for the DNSKEY record represented in this KeyDigest.</t> <t>The DigestType element in the KeyDigest element contains the DNSSEC digest algorithm identifier for the DNSKEY record represented in this KeyDigest.</t> <t>The Digest element in the KeyDigest element contains the hexadecimal representation of the hash for the DNSKEY record represented in this KeyDigest.</t> <t>The publickeyinfo named pattern in the KeyDigest element contains two mandatory elements: the base64 representation of the public key for the DNSKEY record represented in thisKeyDigest,KeyDigest and the flags of the DNSKEY record represented in this KeyDigest. The publickeyinfo named pattern is optional and is new in thisversion of thespecification. It can be useful when IANA has a trust anchor that has not yet been published in the DNSroot,root and for calculating a comparison to the Digest element.</t> </section> <section anchor="xml-example"> <name>XML Example</name><t>The<!-- [rfced] FYI - A normative reference to the XML specification has been added because this document contains XML. We placed the citation in the following sentence in Section 2.3. Please review and let us know if you prefer a different phrasing or placement. Original: The following is an example of what the trust anchor file might look like. Updated: The following is an example of what an XML [W3C.REC-xml11-20060816] document for a trust anchor might look like. Note: For more information, please see the IESG statement on "Guidelines for the Use of Formal Languages in IETF Specifications" (https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/), specifically, the following: "The use of a language requires a reference to the specification for that language. This reference is normative, and needs to fulfil the usual requirements for normative references (Section 7 of RFC 2026)." --> <!-- [rfced] Please confirm that "ttime" (rather than "time") is correct here. Original: The full public key is only given for the trust anchor that does not have a validFrom ttime in the past. --> <t>The following is an example of what an XML <xref target="W3C.REC-xml11-20060816"/> document for a trust anchor might look like. The full public key is only given for a trust anchor that does not have a validFrom ttime in the past.</t> <sourcecodetype="XML"><![CDATA[type="xml"><![CDATA[ <?xml version="1.0" encoding="UTF-8"?> <TrustAnchor id="E9724F53-1851-4F86-85E5-F1392102940B" source="http://data.iana.org/root-anchors/root-anchors.xml"> <Zone>.</Zone> <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> <!-- This key is no longer valid, since validUntil is in the past --> <KeyTag>19036</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 </Digest> </KeyDigest> <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> <KeyTag>20326</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D </Digest> <PublicKey> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4Rg WOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQ uCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj /EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Ap xz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXG Xws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= </PublicKey> <Flags>257</Flags> </KeyDigest> <!-- The following is called "KSK-2024" as a shorthand name --> <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> <KeyTag>38696</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest> 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 </Digest> </KeyDigest> </TrustAnchor> ]]></sourcecode> <t>The DS RRset derived from this examplewould be:</t>is:</t> <sourcecode type="Zone"><![CDATA[ . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 ]]></sourcecode> <!-- [rfced] FYI - We updated "the one that would have" as follows in these sentences. Let us know any concerns. Original: The potential third record, the one that would have included the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. ... One potential second record, the one that would have been based on the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. ... The other potential second record, the one that would have been based on the key tag 38696, does not contain the optional publickeyinfo named pattern and therefore the DNSKEY record for it cannot be calculated. Updated: A potential third record, one that includes the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. ... A potential second record, one based on the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set. ... Another potential second record, one based on the key tag 38696, does not contain the optional publickeyinfo named pattern; therefore, the DNSKEY record for it cannot be calculated. --> <t>Note that this DS record set only has two records.TheA potential third record,theone thatwould have includedincludes the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set.</t> <t>The DNSKEY RRset derived from this examplewould be:</t>is:</t> <sourcecode type="Zone"><![CDATA[ . IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU= ]]></sourcecode> <t>Note that this DNSKEY record set only has one record.OneA potential second record,theonethat would have beenbased on the key tag 19036, is already invalid based on the validUntil attribute's value and is thus not part of the trust anchor set.The otherAnother potential second record,theonethat would have beenbased on the key tag 38696, does not contain the optional publickeyinfo namedpattern and thereforepattern; therefore, the DNSKEY record for it cannot be calculated.</t> </section> </section> <section anchor="retrieving"> <name>Root Zone Trust Anchor Retrieval</name> <section anchor="retrieving-trust-anchors-with-https-and-http"> <name>Retrieving Trust Anchors with HTTPS and HTTP</name> <!-- [rfced] FYI - We added <eref> to the URLs in the following sentences, which means that they are now hyperlinked in the html and pdf outputs. Please let us know any concerns. Original: The URL for retrieving the set of hashes in the XML file described in Section 2 is <https://data.iana.org/root-anchors/root-anchors.xml>. ... The URL for a detached CMS signature for the XML file is <https://data.iana.org/root-anchors/root-anchors.p7s>. --> <t>Trust anchors are available for retrieval using HTTPS and HTTP.</t> <t>In this section, all URLs are given using the "https:" scheme. If HTTPS cannot be used, replace the "https:" scheme with "http:".</t> <t>The URL for retrieving the set of hashes in the XML file described in <xref target="ta_formats"/> is<https://data.iana.org/root-anchors/root-anchors.xml>.</t><eref target="https://data.iana.org/root-anchors/root-anchors.xml" brackets="angle"/>.</t> </section> <section anchor="trusting_anchors"> <name>Accepting DNSSEC Trust Anchors</name> <t>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.</t> <t>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.</t> <t>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) <xref target="RFC5652"/> signature that chains to the ICANN CA with the XMLfile.<br/>file. This can be useful for validator 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 for the XML file is<https://data.iana.org/root-anchors/root-anchors.p7s>.</t><eref target="https://data.iana.org/root-anchors/root-anchors.p7s" brackets="angle"/>.</t> <!-- [rfced] In these sentences, "data.iana.org" appears both with and without quotation marks. We updated to use quotation marks for both instances. Also, should "data.iana.org" be a hyperlink (i.e., use <eref>)? We see that it resolves to https://www.iana.org/. Original: 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. Updated: 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. --> <t>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 fordata.iana.org"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 <bcp14>SHOULD</bcp14> be used instead of HTTP in order to have assurance of data origin.</t> </section> <section anchor="changes-in-the-trust-model-for-distribution"> <name>Changes in the Trust Model for Distribution</name> <t>IANA used to distributethetrust anchors as a self-signedPGPPretty Good Privacy (PGP) message and as a self-issued certificate signing request; this was described in <xref target="RFC7958"/>. This document removes those methods because theyreliedrely on a trust model thatmixedmixes out-of-band trust of authentication keys with out-of-band trust of the DNSSEC root keys. Note, however, that cryptographic assurance for the contents of the trust anchor now comes from thewebWeb PKI or the ICANN CA as described in <xref target="trusting_anchors"/>. This cryptographic assurance is bolstered by informal comparisons made by users of the trust anchors, such as software vendors comparing the trust anchor files they are using.</t> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>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.</t> <t>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. Some of the methods described (such as accessing over thewebWeb with or without verifying the signature on the file) have different security properties; users of the trust anchor file need to consider these when choosing whether to load the set of trust anchors.</t> <section anchor="security-considerations-for-relying-parties"> <name>Security Considerations for Relying Parties</name> <t>The body of this document does not specify any particular behavior for relying parties.In specific,Specifically, it does not say how a relying party should treat the trust anchor file as a whole. However, some of the contents of the trust anchor file require particular attention for relying parties.</t> <section anchor="validuntil"> <name>validUntil</name> <t>Note that the <tt>validUntil</tt> 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 <tt>validUntil</tt> attribute, it can change to a trust anchor with a KeyDigest element that does have a <tt>validUntil</tt> attribute, as long as that trust anchor's <tt>validUntil</tt> attribute is in the future and the KeyTag, Algorithm, DigestType, and Digest elements of the KeyDigest are the same as those in the previous trust anchor.</t> <t>Relying parties <bcp14>SHOULD NOT</bcp14> use a KeyDigest outside of the time range given in the <tt>validFrom</tt> and <tt>validUntil</tt> attributes.</t> </section> <section anchor="comparison-of-digest-and-a-publickeyinfo"> <name>Comparison of Digest andapublickeyinfo</name> <t>A KeyDigest element can contain both a Digest and a publickeyinfo named pattern. If the Digest element would not be a proper DS record for a DNSKEY record represented by the publickeyinfo named pattern, relying parties <bcp14>MUST NOT</bcp14> use that KeyDigest as a trust anchor. A relying party that wants to make such a comparison needs tomarshallmarshal the elements of the DNSKEY record that became the DS record using the algorithm specified inSection 5.1.4 of<xref section="5.1.4" sectionFormat="of" target="RFC4034"/>.</t> <t>Relying parties need to implement trust anchor matching carefully. A single trust anchor represented by a KeyDigest element can potentially change its Digest and KeyTag values between two versions of the trust anchor file, forexampleexample, when the key is revoked or the flag value changes for some other reason. Relying partieswhichthat fail to take this property into account are at risk of using an incorrect set of trust anchors.</t> </section> <section anchor="different-outputs-from-processing-the-trust-anchor-file"> <name>Different Outputs from Processing the Trust Anchor File</name> <t>Relying parties that require the optional publickeyinfo named pattern to create trust anchors will store fewer trustanhcorsanchors than those that only require a Digest element. Thus, two systems processing the same trust anchor file can end up with a different set of trust anchors.</t> </section> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <!-- [rfced] Please verify that no IANA actions are needed. For example, confirm that no action is needed per the following text (e.g., listing this document as an additional reference for id-mod-dns-resource-record or marking the registration as obsolete). Original: [RFC7958] defined id-mod-dns-resource-record, value 70, which was added to the the "SMI Security for PKIX Module Identifier" registry. This document no longer uses that identifier. --> <t>Each time IANA produces a new trust anchor, it <bcp14>MUST</bcp14> publish that trust anchor using the format described in this document.</t> <t>IANA <bcp14>MAY</bcp14> delay the publication of a new trust anchor for operational reasons, such as having anewly-creatednewly created key in multiple facilities.</t> <t>When a trust anchor that was previously published is no longer suitable for use, IANA <bcp14>MUST</bcp14> update the trust anchor document accordingly by setting a <tt>validUntil</tt> date for that trust anchor. The <tt>validUntil</tt> attribute that is added <bcp14>MAY</bcp14> be a date in the past or in the future, depending on IANA's operational choices.</t> <t>More information about IANA's policies and procedures for how the cryptographic keys for the DNS root zone are managed (also known as "DNSSEC Practice Statements" or "DPSs") can be found at <ereftarget="https://www.iana.org/dnssec/procedures">https://www.iana.org/dnssec/procedures</eref>.</t>target="https://www.iana.org/dnssec/procedures" brackets="angle"/>.</t> <t><xref target="RFC7958"/> defined id-mod-dns-resource-record, value 70, which was added to thethe"SMI Security for PKIX Module Identifier" registry. This documentno longer usesdoes not use that identifier.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <referenceanchor="RFC1034"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1034"/> <seriesInfo name="DOI" value="10.17487/RFC1034"/> </reference> <reference anchor="RFC1035">anchor='W3C.REC-xml11-20060816' target='https://www.w3.org/TR/2006/REC-xml11-20060816'> <front><title>Domain names - implementation and specification</title><title>Extensible Markup Language (XML) 1.1 (Second Edition)</title> <authorfullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>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.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="RFC4033"> <front> <title>DNS Security Introduction and Requirements</title> <author fullname="R. Arends" initials="R." surname="Arends"/> <author fullname="R. Austein" initials="R." surname="Austein"/> <author fullname="M. Larson" initials="M." surname="Larson"/> <author fullname="D. Massey" initials="D." surname="Massey"/> <author fullname="S. Rose" initials="S." surname="Rose"/> <date month="March" year="2005"/> <abstract> <t>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]</t> </abstract> </front> <seriesInfo name="RFC" value="4033"/> <seriesInfo name="DOI" value="10.17487/RFC4033"/> </reference> <reference anchor="RFC4034"> <front> <title>Resource Records for the DNS Security Extensions</title>initials='T.' surname='Bray' fullname='Tim Bray'> <organization /> </author> <authorfullname="R. Arends" initials="R." surname="Arends"/>initials='J.' surname='Paoli' fullname='Jean Paoli'> <organization /> </author> <authorfullname="R. Austein" initials="R." surname="Austein"/>initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg-McQueen'> <organization /> </author> <authorfullname="M. Larson" initials="M." surname="Larson"/>initials='E.' surname='Maler' fullname='Eve Maler'> <organization /> </author> <authorfullname="D. Massey" initials="D." surname="Massey"/>initials='F.' surname='Yergeau' fullname='François Yergeau'> <organization /> </author> <authorfullname="S. Rose" initials="S." surname="Rose"/>initials='J.' surname='Cowan' fullname='John Cowan'> <organization /> </author> <datemonth="March" year="2005"/> <abstract> <t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t> <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t> </abstract>month='August' day='16' year='2006' /> </front> <seriesInfoname="RFC" value="4034"/> <seriesInfo name="DOI" value="10.17487/RFC4034"/>name='W3C Recommendation' value='REC-xml11-20060816' /> <format type='HTML' target='https://www.w3.org/TR/2006/REC-xml11-20060816' /> </reference><reference anchor="RFC5011"> <front> <title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title> <author fullname="M. StJohns" initials="M." surname="StJohns"/> <date month="September" year="2007"/> <abstract> <t>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<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5011.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7958.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9157.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <!-- [rfced] For thepresence of a current anchor, other anchors mayfollowing reference entry, would it beadded at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t> <t>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]</t> </abstract> </front> <seriesInfo name="STD" value="74"/> <seriesInfo name="RFC" value="5011"/> <seriesInfo name="DOI" value="10.17487/RFC5011"/> </reference> <reference anchor="RFC5652"> <front> <title>Cryptographic Message Syntax (CMS)</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="September" year="2009"/> <abstract> <t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="70"/> <seriesInfo name="RFC" value="5652"/> <seriesInfo name="DOI" value="10.17487/RFC5652"/> </reference> <reference anchor="RFC7958"> <front> <title>DNSSEC Trust Anchor Publication for the Root Zone</title> <author fullname="J. Abley" initials="J." surname="Abley"/> <author fullname="J. Schlyter" initials="J." surname="Schlyter"/> <author fullname="G. Bailey" initials="G." surname="Bailey"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="August" year="2016"/> <abstract> <t>The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).</t> <t>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.</t> </abstract> </front> <seriesInfo name="RFC" value="7958"/> <seriesInfo name="DOI" value="10.17487/RFC7958"/> </reference> <reference anchor="RFC9157"> <front> <title>Revised IANA Considerations for DNSSEC</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="December" year="2021"/> <abstract> <t>This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updates RFC 6014helpful to includehash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track. The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms.</t> </abstract> </front> <seriesInfo name="RFC" value="9157"/> <seriesInfo name="DOI" value="10.17487/RFC9157"/> </reference> <reference anchor="RFC9364"> <front> <title>DNS Security Extensions (DNSSEC)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="February" year="2023"/> <abstract> <t>This document describestheDNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034,direct URL and4035, 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.</t> </abstract> </front> <seriesInfo name="BCP" value="237"/> <seriesInfo name="RFC" value="9364"/> <seriesInfo name="DOI" value="10.17487/RFC9364"/> </reference> <reference anchor="RFC2119"> <front> <title>Key wordsdate foruse in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signifytherequirements 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 Practicespractice statement? Original: [DPS] Root Zone KSK Operator Policy Management Authority, "DNSSEC Practice Statement for theInternet Community, and requests discussion and suggestionsRoot Zone KSK Operator", n.d., <https://www.iana.org/dnssec/procedures>. Perhaps: [DPS] Root Zone KSK Operator Policy Management Authority, "DNSSEC Practice Statement forimprovements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>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 havethedefined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> </references> <references anchor="sec-informative-references"> <name>Informative References</name>Root Zone KSK Operator", March 2024, <https://www.iana.org/dnssec/procedures/ksk-operator/ksk- dps-20240315.html>. --> <reference anchor="DPS" target="https://www.iana.org/dnssec/procedures"> <front> <title>DNSSEC Practice Statement for the Root Zone KSK Operator</title> <author> <organization>Root Zone KSK Operator Policy Management Authority</organization> </author><date>n.d.</date></front> </reference> <reference anchor="RELAX-NG" target="https://www.oasis-open.org/committees/relax-ng/compact-20021121.html"> <front> <title>RELAX NG Compact Syntax</title> <author initials="J." surname="Clark" fullname="James Clark"> <organization/> </author> <date month="November" year="2002"/> </front> <refcontent>OASIS Committee Specification</refcontent> </reference> </references> </references><?line 473?><section anchor="changes-from-rfc-7958"> <name>Changes from RFC 7958</name><t>This version of<!-- [rfced] FYI - We made a few changes to the list in Appendix A ("Changes from RFC 7958") to create parallel structure. Let us know any concerns. --> <t>This document includes the following changes:</t> <ul spacing="normal"> <li><t>There is<t>Made a significant technical changefrom erratum 5932 <https://www.rfc-editor.org/errata/eid5932>.per <eref target="https://www.rfc-editor.org/errata/eid5932" brackets="angle">Erratum ID 5932</eref>. This change is in the seventh paragraph of <xref target="xml_semantics"/>.</t> </li> <li> <t>Added the optional publickeyinfo named pattern with two mandatory elements, PublicKey and Flags.</t> </li> <li> <t>Removed the certificates and certificate signing mechanisms.</t> </li> <li> <t>Removed the detached OpenPGP signature mechanism.</t> </li> <li><t>The<t>Updated the reference to the DNSSEC Practice Statement <xreftarget="DPS"/> was updated.</t>target="DPS"/>.</t> </li> <li><t>Say<t>Stated explicitly that the XML documents might have XML comments in them.</t> </li> <li> <t>Clarified the use of the detached CMS signature.</t> </li> <li> <t>Updated theIANA Considerations<xref target="iana-considerations" format="title"/> section to indicate requirements on IANA.</t> </li> <li> <t>Simplified the description of using the validFrom and validUntil attributes.</t> </li> <li> <t>Added new security considerations.</t> </li> <li><t>There was a bit of<t>Made some editorialcleanup.</t>changes.</t> </li> </ul> </section> <section anchor="historical-note"> <name>Historical Note</name> <t>The firstKSKKey Signing Key (KSK) for use in the root zone of the DNS was generated at a key ceremony at the 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.</t> <t>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 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 resulting trust anchor was first published on 2018-11-11.</t> <t>More information about the key ceremonies, including full records of previous ceremonies and plans for future ceremonies, can be found at<https://www.iana.org/dnssec/ceremonies>.</t><eref target="https://www.iana.org/dnssec/ceremonies" brackets="angle"/>.</t> </section> <sectionanchor="acknowledgemwents"> <name>Acknowledgemwents</name>anchor="acknowledgemwents" numbered="false"> <name>Acknowledgements</name> <t>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.</t> <t>RFC 7958 incorporated suggestions made byAlfred Hoenes and Russ Housley,<contact fullname="Alfred Hoenes"/> and <contact fullname="Russ Housley"/>, whose contributions are appreciated.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA8U87XLbOJL/+RRYpWo32UiyJEuW7HE8I0t27PHnWnaS2aur GYiEJMYUqRCkZSWVeZZ7lnuy624AJCjR+drduqmpWKKARqO/u9FgrVZzEj8J xB4bXo5GRwN2G6cyYf3QnUUxu07Hge/yxI9CNoHvyUywmyhK2D+jUDh8PI7F w17+5MnJjhe5IZ/DKl7MJ0nNF8mk5oUyWtTiidvd7fTGvqw1dhxHJjz0fucB QNtjSZwKJxrLKBCJkHsMB8KQdDz3pQSwyWoBo06Pbo+dMJ2PRbznuFEoRShT qWcDetuOv4jpq0xajcZuo+UAVnvMDyeR4zyIMBV7DmPTOEoXe6wCdLi6Zm9f V/CZn8zSMTxc8DQQs2gymfNwS+1hzOXMwr7iODxNYN97Tg1mAnRA4dc6648D scIHav+/RiJ/FMXTPTYIotSbBDwW+EjMuR/ssfccx/ziZr/V3WiOv7t+stpj /blMROxx9ShKwySGp5cC+BMHQEBZxGHkzoIVTLDQ4PfRuPCccDnzY+Gz/mEB Exj5yz3+UJfCgvu6zg5hhL2516kfBDydC+sXgnsaemIh4J8wsUBPzfAxjf4l SpMgiu5pq/k613V2ogifL3QN7LCfqkUG/ctLCzzyrK559gsIYhjWYZzjhFE8 B6l8IK7fHA+aje12/rGjP7Yb29v5RzOg02g2zcedTkt/RBHQH3ebna75uL0D 0xwUM2vB4fUI/zBWVLvrmLuJ7wo2Sngi5kCoTYVjZ6MzdrUQMU8i4hkzEoef a4oK5aPZdQS6uGIXPORTBb5Pc0GcFDY8ngpQilmSLOTe1tZyuaz7MBhJtgWa KoW7tYgjV3hpLCRu8Oi8/652+bqwGXrILl+zQTRfwIbYaBUm/HETV/o3F8a5 kKAHPL7Xz43g5s/K8Iu4BKsRgWARliA2cz9JhJBbsQj4Yy2kZ4hHDfS+1Wy2 mvVZMg8IoAdk3mP43HFqtRrjY5kgDxznFmgeIxU/IhWjCTFhGkRjHrBhBLIV skvAGPYGSjhnz4GDL5gvHTdeLZJoGvPFDKQtCFZM+tNQeCyVfjhFRrORcFMk OTt6TMBKgQmTNB8k4EXdcU5D4KEngO0Ri8YJriRxhmA8lEsRSzaJoznhs4Eg gqeFHAWvyjhzAx85PUejDIZx4k8JFpOpn6CBUTYRgKO9rjPYuS8ZmOqUBMQT 0o39MbAG4SshhrEeW1heYS7cGQ99OZfstH/ZBxRwfMQ8H8jpj9NEGOxQyu31 ZN1ZWzCz9Kg9ZOzrijdz3/MC4TjPwJAkceSlLjkV4tTXGZNtxAO5Yp8+aZX/ /Jk2Y753Pn+uO1/jEQNLXAIONR2nIwOt3YK+JJEbBVV2I2SUxqDdN8IFDsMa CQC9ucG/CqgSlU0ZqjNGRJoLEAEAjixgoIEL9HNIaM4+pCJeIX9RYKSDkHiC WqqHB0G0JLT8MBFT2hpuHPURqO6jRzFCRBgBVGcs2IOI/YkvPMBA78eCjCg/ 8MBHLfLYeAXigcugnIPYzZAV0aSACmJasflfoa2BJAsuTXiBPysY9NFRI5GH 4Buk74ly8oKYsRl/wJmkETGbR7EowJAIJBYfUnBkXmZa1yAhlssovq8r0bLl HAlkC28GolQRYS1wTKQQkzQkaWVgiVGHFLnIV1VhPAQd0xnzQRz4ZOIHPtBT B07sFlQrRClgp+g4kRmw7vPr29MXEFaAGCboNj0tjwuNJkRAsZIPD+lxL1Zs nhv9hXYzkoE/ZGNU6zTUggyeiYT461ZAkgBlKq7sAFh3TyICZbquRBHggn1Q BCDalNDQ0TQE6bjCcAa9GhiYj8QG0AN/OiNmgx76k4mItadErBzEyjJICD5H UpngTcxsJBxE4ic2i5YCxL8KYgQDI+1D1a5lNEmWJP4Qz+BDwgVAQdiJmgOu B9RJ2QHa5KbN+wYyFmxMUmAIrs0ddGyB4mkSVVkYJWTXwYn5CRpdWKFKOICa g2lELbV3bzQrXaAG5wqwadsw4gGxQF3lST6QrIp0kHjaRfkhhMRIoNQF+ZKl SrOcIZHo0YzD9gNQfm8F1gYeC4k+yZczMjlPCSEKyZKvUFOzCahrfugnPqiK vZ4SOi3oRvDsTT3tgGgUeiAa9ewZG4oJLQEyqFgIYfN8zaBl8g20A51bWRKK 1lk8AseJncKRxslg0JICYDT0FzhHWxF8DhT08mXJg4NdSGA3Lod1UFNWynks hAvmwVVWNvsmyQ9WkSNAI8neI67IMS0JEERmj0ZbF6cXRyB/UoKtkMqXFbyR BgdMhKSIzcAY8dglL8VAgMElgxBUjeXWJHHIEOrQD2IODIIZ2rJkRasuYf5M z8ChUqZoIFGMQKIdCIVggqcdhY5ANIE0FEViomtObY0pOQayJ5CrwQbAf3Cl FB5QiCQUCKZWJx3TMNHdcvA1xufoFRVUJVSg5T5JI5juKu5S8wsMAGiGzUEK iDSEEpmpr8ebBQE2doI8EWpGZjpVIALCQeLmfPqU8N/1aNJWEmDMYSDMUePk Gm9QIir9PC4kA3F29Jtzc4MedDiCaAC1dIbYc/0jPEO/fRlRXMeTglMw+IDV FpDxk1GCH5DDM2GJMgJc0xyKay2cf3IyG8wLhF/yMKFoAvCGnxUCBAsWRjsX oxVAcMr9QsyDOjEUgZgqTz7CSCuGkA6CQ9ghmgfAVUaaE+gwIQYAG1y5uBvd VqrqL7u8os83R/+4O705GuLn0Un//Dz74OgRo5Oru/Nh/imfObi6uDi6HKrJ 8JQVHjmVi/5v8AsKf+UKvPzVZf+8Um7/YU9jFc/Fi1jg1rl0Crb7cHD9v//T bANN/wJEhdxnFwRBfek1uxj8oi1Wq0UhuCz1FU2KwxcLwWOEgrLs8gVobgDa BAIjgS0hMRjI9ff/Qsr89x7bH7uLZvtAP8ANFx4amhUeEs02n2xMVkQseVSy TEbNwvM1Shfx7f9W+G7obj3c/zkAqWa1Zu/nA4dyEJQrbUKfKH0d58nSSIAr gJALfMozS0cdJZ5GseVXo0tOlvTdxXkuCcq96bifhqO65uZGq2xMOYeKjiIK Eyk5TZSwWzllcbzxjlbiR1Yw2w9Y68j1KbRYT4vI6EIUqq01QAGHhysD0KLt KGwIdZHCKXyK9hMeAh5ATSYeOQY8VUV9FQWmkvIBKbKx5AA9yFAj0g367s8X UZwAziyrxKAJsiK0pRhDbpOASNvr0qZINcinA/1nKWy9hiELJc96II9XKv4S eb6IbgVz05jP5zzWlqW4VcM2MG+CyKR5Z6UmFjOIYI4dysASJgErSor2lhoc bgJrohBkYvGNfHdmjQEMmA+JmzAlXu1hOdr/WGetZfiDQYiIX3ojuTihoEwC Pv2CYN1uji3iyb4DTwM7w7UoYBYdgHseBvIrHYWBY8HqlMofc/yR7VpNVOyH G1eFLNDhx3nwu5oHOtwvqXi5M9AQ9GW6QAam1vDUUE8aFjpa/9e035d7jvPn n386gC7HIrdkj9Jjr1gFy1+6+rXcpqpXq9FobgGGat1aNqNCtXRwkK+Y0IkC mShtoT45jPHElGh8j33CJfYwFYFE6XO18LMuXmwOMZDJAm7+DPT0fIgmk5cO ECv7ZqF0JlZD9ey7ECLJP6aYgUahFtz6c1E67g7MVbAx8OeqY20A8LjlU0IC /8OhYRReUszwIE6xcAIxwycQocfT0A1SiYEs8GOn09nuVNjnIjn6wRTD3dn8 +wG2OpvgFIVugav/TniaIjPxeOiHYMRgDGMwSlU9gFloLn9GxhWesFcWJFWp AOJpYBBni512Bs8aeUxartH/AfKSOmTKaPlU0kfz/bOyVH9Ykv5HhoIvdVxO BktQdE0RjonObR10tImY+IGxf3/43h+2iKoBtlJZK4FljBb8QyqYlmAy4L4p 5EjtS5ONHBnM9ykYCJDclIwXuBa2AD323TTgsZNtdSMKJ/QyDL6EnJNnSjA7 fHJ2rpz6h2ru5CFnD6KloYwyEN9InSkwV9rO2OFjSLUwAlWhrS59r8/PGEck QiIH/j1WWygadji7uzknj4Lk9x58iZYeHbjGkozUNxBI4gkM+XCVnmJBDx2r Q4FMLj4QJmMSqNyZxXoAXeatMHpWmXmxEN35DIrno9R7Sk5QErkf4BcvSupr +SEt4GFZUmWDED/AyEA4C0h9Io89r7/AAizW+QBH9KNIW6wsfEgjjRHEJPem FFVGgSw4saupG9IAEI440GfjB3DGmgBKzLXVJ3e94BLEyE3jmOQpip1FhB6f srYUawjFaMEoJ+09T3jpmc1QRSbSmjyGMog+KdBraXSWgVI1/9bEh7GYUo0u hyyzpZ44EGh2urq+9JTd2MTlW60GRjR15+vKX7pCUfWd7zEc+TZBXx8yq5j5 4j9I+f7Ifa616y+wQCnFSqUMPJyqeos/N+cX5bPsUJivlzY0atqpf5UshRQK 8/8EZgGnTSnaksZMsq3KbAZQL5t7/+9b2TplwWM8noHJ+B+XZwdlWDnrWFlB xA+hpZT4P4PVd2IEIQvHCt6cB062SH5Mo1XkX8CqGPDgITUkICDLIg6/BcVl ZKUaxgbtmUIkBEisHGu1LEngN+OeI1J1TIquMqqyIsDX5Perm5dZamQ8bSiW GaQHSLmt/ZhCNFeZ/6mttZM0UKcBZGFnGyqsdF/FPwlbCax6w+isEGriM3TO 6BxVJQvJ5vIAQyV9jkgNALEvda13Q+TyDO9IVRjMAY05zlRWWZcfcGdLY5SK lVqIE3VZAntYKDRR9ISdBjZrkYZYVcAwKO+q2ty7Fwm1eayIQHST5zwJWkcj iOhQ65Qtwiac/Z8hHjZ8eFVp1hsVJkI3wtDiVeXu9rjWq/x84Ozb9t33XlWO drut9nFnu9bsdZq19nFvp9brHHVqx83t3Vaz0dptNw6xIUoFeq9MHorZZt4m gnyo6TC28KUOSFUOYPo+uuyD+v4W/cUHuR4hGmfvP8yT7kNFZznZll9VWo1m o9bo1pqd20Zjj/5/Sf8WxpLbocG7tUaz1myuDz6AJf9Sq6njpXvVoYT9JhRm B1GIaQhBqmJY5RYySF/aNGe12gHN3ldu5qC529je2d/S39RPmSs46O1v5V/U j7lFPmjtb1nf7J8PnPZuvz9oNofdw53jnXZ7p9toHXXa/eZOo7vdxX/7zX4b 2NZpNRrHw9bgqDkYDo+2W8et9lHv+LCjoG0ZcPg5I3oZCwL+Xqw+VtaI3601 WvD/Bj0LJGg1tlv/CRIcNXaG7fZhr3HYO24Ot3f7u51B47Ax7A52OsNGr93p HfV6jXZj9/BwsNPbbne6zUa7td0ddI97R4PecIME8C1LXQ+0DPSXR/0+/7iV 9Oe91W3YvpiIWUesTnd33o7eiMfbw/7D/cX014/3Z7dX/tvmw/3p+OOjON5+ udW+mWoYb68+dE/ixxv/8SQ4Do4er877v8YdMT9/uOyO3r6bhuez9svDzuM/ gss3H3tX0979Qz++SC5vrh7f/EPDSAd8FJ4OvWHn/Gz1dnzjtcLdt69F66Z3 /XE6mMfbR9M35/H71eHjW/HxuPH+/GT55rInJqPtePBew9g6ejt9OH07He8m PF68uRuebY07vSF/KT98COS2uBynD91F/FJE/3z9chQPz3bCt+J829056fQX psTwsXv+/o3bTG9PPXn67jG9Ov+t397yg8P56M3px3T4duLd3E1mJ95vOy/d sHdyfDN/2Zpd9Prhu9caxrul3O10Omfx3WHngz9bBa95T6bjd63LcOdueXnT 7N/f3b7ptsd3rzSP1tiyT3WDg1anu7+lPpYIsFLoNaON3TPguSpno7Naq9Fq V1SYKMEeYeTrkWfTSryuAvPVw877aE0FWm2yP70vq8B2b2f3P6ECINbD1rDR Hxz2BruH3War39xt9w5b3eNuu9lq7rZ2e/Bru9MY7jRbg3Zvu3/cbrf77UHj +LB12Nz5shXY37IcwoGqtVB4hoeAWKXQJ7GmpItnpdojLqM0gERUqIol9QXX 2eklTiVzwHqshYv/yzpsoBKFDdR/mSy0VTuXgq1R6ZvCJSrQoLPGQATjukIJ O89cYRoFV/ijOmGmo1w6sCT60KmGSvKFV8gzyG1UKcxQ3RAwjOSOYkXPHFRY fihLqv5mykQ6FEtmqYoYsF5UVtXC/ZjA2xzn/iB31XTQS7bNes6PW0+YSgb0 BywnrpoZz++zmjB1zXB+s8WEqWVG81usJXbNPmUwv2IpcaptLEvFthDpF0QX pVE9rztXoS25Ep6GXxddCr4LAvn/J78ovlGCrWH/xm2QVanmQbd9rJWlPF9K jXTyFYsJtR5uZF4Y6PuUASF4SIJMniI8zEGeOkm+EVh4AjKxT89i9Rkc3GfK Wm6y74U5ukPn5Pb2ekRo4SfQ+sIRE3WRPXA/oKNMRC7OVlL9ysX5prk1P8qt Uu387uZcAVPpjJqKu6+oTu0Kk3gwhaeSpxNHwcxpgOWbKialAXdF2TS1FZVu mF4ZLPNaCJsFi8eomnWY2FFqtlajs7tlsCL+1yD5ybSWf0dS89dp8pPKIPuu KxZ2k2GRI5+emd7W3/V0Oj3UJ7iwGdNkqM5UZ1EkBebHieqAJJHEs21aJdeL rLn1C/2CiiWYtWI/DegMXQTARg9qpqkXus5nIliUYCVVN/AqO0Ch2in2E8T+ VPX6rrd7AniQfAFSUbU6wz0YnqC+rjUpU8uwgzsMVW9sDVeJI4rhBiJOVB1B 5LcW2PNB/wWLcEvr5GDEQcdRhwT5+X9CLUlW1ZRWYoO+yv8SdZq83iOJkhvK BExbFRXYVGm1ScjaTUkkFZW0RDqlhMrEEp+61s7K+kS/DIEEW5dUTLe2Zjd3 NihtLB6daDHFk0UcPfgetYZhO7GLhZVBoenvQjUEmvPv54OL0QvdQ7nTaYHy 5PBzRuLhiVMgcHaeb/AGDFR7SbEkREQsEb/lLFIWXMuUR6WdxcrR5DAL/U0W Si2hqSqhwU+TWjRRPaoTMBJUk7LtSU4DBrvMN+aYGk1G8x80GIuu1AajHyoH ptp9izcnvkEFn5KsJ1WQvGtkGmbAFfBQolawc74CNLIrD89vz4G9WZPvRgP1 huEBNg7UWU6wUm530FdF+YnRQ0MYxGEpwGXch9EyrDq6I7yaO2pULfZWjMl0 1sDWxcLzkXWDPrmPrBXQWTP9axvHb9IgQ5BzAmteOpUCbhXVAyRi6jhUXkp3 mZlDBl/ZAKQz/o5NTrnVRMnE5lWgq0tFQoSuOaP8w2CGRxuycL7CLiJPKCoP rSZw3RpmunzWbtIU96pyWhFMavqu0fXra9PES/XgfIAP+ImiydFHDXQvAvLA n5TnWPKyKzOmGbrYMR2LefRARhwdlule1w3KRgQDX8VbpsI7x20r/s/9xzXV VEPwrNDcT1E1curNITNSOto6qaCzUhyuDsmqeTu/slAF+5ZzzWi51i1ZGoCC 6GLrvbCam1Byrs9OmZ6embxNKm6EAIacT6EEP42jAK96qrNefWYeWFVt3ao8 pi612CBd9MZ5B/jG5QUNqESPyNJpK4IzyK9QpJpZiwH2a3lonkxbfHnPPtD/ 61cv1u9/0KJZud90x2sw6mIbygO2b2CWk19vQ+XRwu6UL2fODFC79K0cY3DR KUBaKemGRShRL4ARVRJiipS/eCfIjjY2Lhdwf05GWJ93guOL0eXpTkx1v2u8 0j0HxLBiiFegRzX3qNOIUwvLnN9T6Sthgsv8VC6SYj02y5qHQeLUQZDyDTET 4YMfR6E+3R+BoBst2LyY8twIFVf3PfDylYnGQCdUq2GUtyAUYqPysOTF+sWe 7JoEuKQFGi4hf3JsQS85hAmFspuulk59Xk+HTRRYq3BYhdYJVv256Wwt6cYh 4/2ExBOFb0RAm7rmhJ6K28aRt8paX3ONMMmlEQGU6Ly3B7iCl9hU2z9KHMFd KLgUppsDNQpEc2h8RSrGC3NWWOrExDeBrPypAyvyDhBbYY/TibGS0mL7F40h gdB36ux9YEYcZu8M2NgIUPSZVQ9Yb9gsbyAwCJQ2NeTtmqdqVJEQdC3Hula4 ccTIN8E6m2dwMKwct6pO7DH4xf4FunFQuAZDulCyinXS9+UVHMASj6eQY4pS FngIep8gWn5kpXtrdJXCUfXpat6rULUaBNRZ6lqzzyYDuK5zSCykcxVwLWKI yqJUrrdj3BSFgOUt/BSU2qRZu3VDZ52qL4RKDObg9xv7TrS4DfJjYIBrNoDx UbGog0l5ebOJKQiNI2Ll0yCKdaFMJNdAqqKULoNwbd+syrNKSJ4+vB+vrJaB 0pWrzprmMXM5Q+cB3G6/Lemh6a+pUfH+DbgboeMK+5Adra/+PZYzcxdqXYiK +yLAGDPOdeEso0JeTsr7TgpNdCNVi2KderPeRuiFDq4NsTO+wc8vT9oGgS4r 4fjMNyMVVH9dceQaK8pUG4UmK1BihKKMA171tYRH9yjpbrKxSJZYosSjBn2I /7TprZKQZJV6ulqpK5p01/khusfYOs56QnS11dWpCN3dJFtPrlDdw65v0EwF JBPu0/XoBNlObk275JW+YuXSa0hUXRHyAl/eI+La7mLbDN1LdpOn3ewzoItx /FdpsgA7oKLsa3zvhMxEoXjTxseWjXWc9R095Zm+uYSLQQM6y/Uki6JMmWBd dyKWIs5+nrn6anOoEyBal+JRszjf6De5naUQkSOHzYXKRXF/ZE83HS3KE0Tt LF0w7U7sOKmcpirxXY/TqWuT7KopAnmpS0UgbOaxgVQd8GxkNrKLCuvOx9JR 3ej6dC2yrlPbi/5vMCrgtg3LQupNLEhSVR1EMVGJqqw6JgTVl/9parCqKS56 pgY0T4PERx2ZcNcPfB2FvEWFKYsIMP81fgw4md+9LHSJZO/QmBANwEWrrSGx 9K3qDa3NcwEXzRvalRWaD2CfblcqeDECMjFoFY3z7dORUlZL8fCsEWlNLoag 2Q0sUVwMDrC7G1/So16jQLLxN1mgOyyN7w4A4l1EdOM7v0+lWrj1HKoxox7S 20Kyt8bQXmb6ZRTFnFddRFvPz9TFN3Vzh08hn3tO146ogETXV598eY6s4PYq w+uRrLxwCu86AOLsf9tbbg5go1btI28U9mrzyMP3V9XMtaOaOXlSJrbbqGq7 icKkGKHbz+iQY3RxmicVuO3rs9N3WA5KQaDytz1UTOvxar3uksuhKhsSy7N5 +rUpY+7eoxEwtScypubVKjo9XWvZyxbQZ9XmrQ+msUL7jj1YAFsuYqGKdlRI wqISetTstRXa49GyIgYpSuess7vdYnbxFFkQT9walvpAsJERNJZvCd/D0apk Ssjm4ayEVCUEIwgGn5MMKd9fvAyCEUCN9T1z5P5NTkDl1aUtnFXrvgtKNjWk 0Bo3VAZTq1gFNrlR5DcVt/wtFRvzsyL0FSgjlvPyVDmbVdf0B/kgD+CKrLvx yddJ6Rd8kEQqA+URmBGYYfG4QI1NglWeh9nX/Qrv3ShcklT8UAjh25pUZIbz Mcg0UlVaV6c5dwoTVTrbdFbmsJGCNn3twfhWHVEqS6W2gnFdjkHxxSiWo8pb KZE/ZUfT0hIddEfW+xps9Oq5HpCis7FPjlgJMx5Mu4HgYbogZ3ziYxBBqoEp r+409WOwxfiuLu1IjIiXvlgGVnGmIhSqcEMvA0InByIGEhSuWOFgC+XUeuHX sfJ+K+f52cXxC1xmkAYLMPmQ87/x46kf+rzK7kZ9pKnqt9ypNXfMyziwWxID 3phuY5qXMDGwlMp16SP4AjozESgsQ0ejdHGMCx8FYP6mYI2jKhsA+WHrm4t3 a82Wvv0iJLpw5J7tTpHkiny5j7Znd/Qpmsbsh2lc2NKzVneNympLX6YlELJR a3W1HUOAT5NybbmeoaKzsebXyajbNn+QjL1aE5ton/b3Jt/Q6ILLh4gxu8pE nc/mAjMQOCsO5MNVhBBwXUzTVQob3LrvXvcd6+47n2sO51nfxYghEB4owhKN BuyHSm+wEYG1xAU3xhdfLZPd1hWLIFqpF8NMjGG1BMdZE5xqdkdeve9E0nsS MDvM18ef/Vi9qIdTZui4eMjt0ptR6MxbnwJh9qpdtUqeFpESSJlOMaHw7dp/ P5igLJ1EItQ0vUmldE4wghUrjEUiWQSvO0AWwBN1hx/W+z+e3mETDVQAAA==[rfced] Sourcecode a) We see that type="Zone" is used for some sourcecode elements. This type does not appear on the current list of preferred values for the type attribute: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types Would you like to remove type="Zone"? It is acceptable to leave the "type" attribute not set. Alternately, would you like to suggest type="Zone" be considered as as addition to the list? If so, we can submit it for review by the RPC team. b) For the RELAX NG schema in Section 2.1, we updated <artwork> to <sourcecode> with type="rnc". Note that this was used for the RELAX NG schema in RFC 9457. Let us know any concerns. --> <!-- [rfced] The following terms are enclosed in <tt> in this document. id source TrustAnchor validFrom validUntil Some of these appear both with and without <tt>. For example, we see both "TrustAnchor element" (no <tt>) and "<tt>TrustAnchor</tt> element" (with <tt>). Also, some elements are enclosed in <tt> (e.g., "<tt>id</tt> element"), but other elements are not (e.g., "KeyDigest element" and "Zone element"). Please review to ensure the usage of <tt> is correct and consistent. Let us know if any updates are needed. --> <!-- [rfced] The following forms used in the document. Would you like to update to one form, or is the current okay? trust anchor document vs. trust anchor file XML document vs. XML file --> <!-- [rfced] FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Pretty Good Privacy (PGP) Key Signing Key (KSK) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>