rfc9718.original.xml   rfc9718.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-dnsop-rfc7958bis-06" number="9718" category="info" consensus="true" submis
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft sionType="IETF" updates="" obsoletes="7958" tocInclude="true" sortRefs="true" sy
-ietf-dnsop-rfc7958bis-06" category="info" consensus="true" submissionType="IETF mRefs="true" version="3" xml:lang="en">
" obsoletes="7958" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.23.0 -->
<front> <front>
<title abbrev="Root Zone Trust Anchor Publication">DNSSEC Trust Anchor Publi cation for the Root Zone</title> <title abbrev="Root Zone Trust Anchor Publication">DNSSEC Trust Anchor Publi cation for the Root Zone</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-rfc7958bis-06"/> <seriesInfo name="RFC" value="9718"/>
<author initials="J." surname="Abley" fullname="Joe Abley"> <author initials="J." surname="Abley" fullname="Joe Abley">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<postal> <postal>
<city>Amsterdam</city> <city>Amsterdam</city>
<country>Netherlands</country> <country>Netherlands</country>
</postal> </postal>
<email>jabley@cloudflare.com</email> <email>jabley@cloudflare.com</email>
</address> </address>
</author> </author>
skipping to change at line 43 skipping to change at line 43
<address> <address>
<email>guillaumebailey@outlook.com</email> <email>guillaumebailey@outlook.com</email>
</address> </address>
</author> </author>
<author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<date year="2024" month="September" day="04"/> <date year="2025" month="January"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<abstract> <abstract>
<?line 70?>
<t>The root zone of the global Domain Name System (DNS) is <t>The root zone of the global Domain Name System (DNS) is
cryptographically signed using DNS Security Extensions (DNSSEC).</t> cryptographically signed using DNS Security Extensions (DNSSEC).</t>
<t>In order to obtain secure answers from the root zone of the DNS using <t>In order to obtain secure answers from the root zone of the DNS using
DNSSEC, a client must configure a suitable trust anchor. DNSSEC, a client must configure a suitable trust anchor.
This document describes the format and publication mechanisms IANA uses to distr ibute the DNSSEC trust anchors.</t> This document describes the format and publication mechanisms IANA uses to distr ibute the DNSSEC trust anchors.</t>
<t>This document obsoletes RFC 7958.</t> <t>This document obsoletes RFC 7958.</t>
</abstract> </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> </front>
<middle> <middle>
<?line 81?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The global Domain Name System (DNS) is described in <xref target="RFC10 34"/> and <xref target="RFC1035"/>. <t>The global Domain Name System (DNS) is described in <xref target="RFC10 34"/> and <xref target="RFC1035"/>.
DNS Security Extensions (DNSSEC) are described in <xref target="RFC9364"/>.</t> DNS Security Extensions (DNSSEC) are described in <xref target="RFC9364"/>.</t>
<t>In the DNSSEC protocol, Resource Record Sets (RRSets) are signed <t>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
be verified. DNSSEC signatures are validated by following a chain of be verified. DNSSEC signatures are validated by following a chain of
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.</t> 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 <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 Identif iers (PTI). A detailed description of IANA function performed by ICANN, through its affiliate Public Technical Identif iers (PTI). A detailed description of
corresponding key management practices can be found in <xref target="DPS"/>.</t> corresponding key management practices can be found in <xref target="DPS"/>.</t>
<t>This document describes the formats and distribution methods of <t>This document describes the formats and distribution methods of
DNSSEC trust anchors that is used by IANA for the root zone of DNSSEC trust anchors that are used by IANA for the root zone of
the DNS. Other organizations might have different formats the DNS. Other organizations might have different formats
and mechanisms for distributing DNSSEC trust anchors for the root and mechanisms for distributing DNSSEC trust anchors for the root
zone; however, most operators and software vendors have chosen to zone; however, most operators and software vendors have chosen to
rely on the IANA trust anchors.</t> rely on the IANA trust anchors.</t>
<t>The formats and distribution methods described in this document are a
<t>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 <xref target="RFC5011"/>. That protocol all ows anchor update protocol described in <xref target="RFC5011"/>. That protocol all ows
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 <xref target="RFC5011"/>.</t> initial trust anchor that can be used by the mechanism defined in <xref target=" RFC5011"/>.</t>
<t>This document obsoletes <xref target="RFC7958"/>.</t> <t>This document obsoletes <xref target="RFC7958"/>.</t>
<section anchor="definitions"> <section anchor="definitions">
<name>Definitions</name> <name>Definitions</name>
<t>The term "trust anchor" is used in many different contexts in the <t>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.</t> just for S/MIME messages.</t>
<t>In cryptographic systems with hierarchical structure, a trust anchor
is an authoritative entity for which trust is assumed and not <t>In cryptographic systems with hierarchical structure, a trust anchor is an
derived. The format of the entity differs in different systems, but authoritative entity for which trust is assumed and not derived. The format
the basic idea, the decision to trust this entity is made outside of the system of the entity differs in different systems, but all common uses of the term
that relies on it, "trust anchor" share the basic idea that the decision to trust this entity is
is common to made outside of the system that relies on it.
all the common uses of the term "trust anchor".</t> </t>
<t>The root zone trust anchor formats published by IANA are defined in <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 <xref target="ta_formats"/>. <xref target="RFC4033"/> defines a trust
"A configured DNSKEY anchor as a "configured DNSKEY RR or DS RR hash of a DNSKEY RR". Note
RR or DS RR hash of a DNSKEY RR". Note that the formats defined here that the formats defined here do not match the definition of "trust
do not match the definition of "trust anchor" from <xref target="RFC4033"/>; anchor" from <xref target="RFC4033"/>; however, a system that wants to
however, a system that wants to convert the trusted material from convert the trusted material from IANA into a Delegation Signer (DS)
IANA into a Delegation Signer (DS) RR can do so.</t> RR can do so.</t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i ",
nterpreted as "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here.</t> be
<?line -18?> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
</section> </section>
<section anchor="ta_formats"> <section anchor="ta_formats">
<name>IANA DNSSEC Root Zone Trust Anchor Format and Semantics</name> <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 <t>IANA publishes trust anchors for the root zone as an XML <xref target=" W3C.REC-xml11-20060816"/> document that contains the hashes of the DNSKEY record s
and optionally the keys from the DNSKEY records.</t> and optionally the keys from the DNSKEY records.</t>
<t>This format and the semantics associated are described in <t>This format and the associated semantics are described in
the rest of this section.</t> the rest of this section.</t>
<t>Note that the XML document can have XML comments. <t>Note that the XML document can have XML comments.
For example, IANA might use these comments to add pointers to important informat ion on the IANA web site. For example, IANA might use these comments to add pointers to important informat ion on the IANA website.
XML comments are only used as human-readable commentary, not extensions to the g rammar.</t> XML comments are only used as human-readable commentary, not extensions to the g rammar.</t>
<t>The XML document contains a set of hashes for the DNSKEY records that <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 can be used to validate the root zone. The hashes are consistent
with the defined presentation format of a DS resource.</t> with the defined presentation format of a DS resource.</t>
<t>The XML document also can contain the keys and flags from the DNSKEY re cords. <t>The XML document can also contain the keys and flags from the DNSKEY re cords.
The keys and flags are consistent with the defined presentation format of a DNSK EY resource.</t> The keys and flags are consistent with the defined presentation format of a DNSK EY resource.</t>
<t>Note that the hashes are mandatory in the syntax, but the keys are opti onal.</t> <t>Note that the hashes are mandatory in the syntax, but the keys are opti onal.</t>
<section anchor="xml_syntax"> <section anchor="xml_syntax">
<name>XML Syntax</name> <name>XML Syntax</name>
<t>A RELAX NG Compact Schema <xref target="RELAX-NG"/> for the documents <t>Below is the RELAX NG Compact Schema <xref target="RELAX-NG"/> for
used to the documents used to publish trust anchors:</t>
publish trust anchors is:</t> <sourcecode type="rnc"><![CDATA[
<artwork><![CDATA[
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+
} }
keydigest = element KeyDigest { keydigest = element KeyDigest {
skipping to change at line 168 skipping to change at line 171
element DigestType { element DigestType {
xsd:nonNegativeInteger { maxInclusive = "255" } }, xsd:nonNegativeInteger { maxInclusive = "255" } },
element Digest { xsd:hexBinary }, element Digest { xsd:hexBinary },
publickeyinfo? publickeyinfo?
} }
publickeyinfo = publickeyinfo =
element PublicKey { xsd:base64Binary }, element PublicKey { xsd:base64Binary },
element Flags { element Flags {
xsd:nonNegativeInteger { maxInclusive = "65535" } } xsd:nonNegativeInteger { maxInclusive = "65535" } }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="xml_semantics"> <section anchor="xml_semantics">
<name>XML Semantics</name> <name>XML Semantics</name>
<t>The <tt>TrustAnchor</tt> element is the container for all of the trus t anchors <t>The <tt>TrustAnchor</tt> element is the container for all of the trus t anchors
in the file.</t> in the file.</t>
<t>The <tt>id</tt> attribute in the TrustAnchor element is an opaque str ing that <t>The <tt>id</tt> attribute in the <tt>TrustAnchor</tt> element is an o paque 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 <tt>id</tt> element in the TrustAnchor element is semantics. Note that the <tt>id</tt> attribute in the <tt>TrustAnchor</tt> elem
different than the <tt>id</tt> element in the KeyDigest element, described ent is
different than the <tt>id</tt> attribute in the <tt>KeyDigest</tt> element descr
ibed
below.</t> below.</t>
<t>The <tt>source</tt> attribute in the TrustAnchor element gives inform <t>The <tt>source</tt> attribute in the <tt>TrustAnchor</tt> element giv
ation es information
about where to obtain the TrustAnchor container. It is likely to be about where to obtain the <tt>TrustAnchor</tt> container. It is likely to be
a URL and is advisory only.</t> a URL and is advisory only.</t>
<t>The Zone element in the TrustAnchor element states to which DNS zone
<t>The <tt>Zone</tt> element in the <tt>TrustAnchor</tt> element states to which
DNS zone
this container applies. this container applies.
The element is in presentation format as specified in <xref target="RFC1035"/>, including the trailing dot. The <tt>Zone</tt> element is in presentation format as specified in <xref target ="RFC1035"/>, including the trailing dot.
The root zone is indicated by a single The root zone is indicated by a single
period (.) character without any quotation marks.</t> period (.) character without any quotation marks.</t>
<t>The TrustAnchor element contains one or more KeyDigest elements.
Each KeyDigest element represents the digest of a past, current, or <t>The <tt>TrustAnchor</tt> element contains one or more <tt>KeyDigest</
potential future DNSKEY record of the zone defined in the Zone element. tt> elements.
The values for the elements in the KeyDigest element are defined in <xref target Each <tt>KeyDigest</tt> element represents the digest of a past, current, or
="RFC4034"/>. potential future DNSKEY record of the zone defined in the <tt>Zone</tt> element.
The IANA registries for these values are described in <xref target="RFC9157"/>.< The values for the elements in the <tt>KeyDigest</tt> element are defined in <xr
/t> ef target="RFC4034"/>.
<t>The <tt>id</tt> attribute in the KeyDigest element is an opaque strin The IANA registries for DNSSEC-related values are described in <xref target="RFC
g that 9157"/>.</t>
<t>The <tt>id</tt> attribute in the <tt>KeyDigest</tt> element is an opa
que string that
identifies the hash. identifies the hash.
Note that the <tt>id</tt> element in the KeyDigest element is different than Note that the <tt>id</tt> attribute in the <tt>KeyDigest</tt> element is differe
the <tt>id</tt> element in the TrustAnchor element described above.</t> nt than
<t>The <tt>validFrom</tt> and <tt>validUntil</tt> attributes in the KeyD the <tt>id</tt> attribute in the <tt>TrustAnchor</tt> element described above.</
igest element specify t>
the range of times that the KeyDigest element can be used as a trust anchor.</t> <t>The <tt>validFrom</tt> and <tt>validUntil</tt> attributes in the <tt>
<t>The KeyTag element in the KeyDigest element contains the key tag for KeyDigest</tt> element specify
the DNSKEY record represented in this KeyDigest.</t> the range of times that the <tt>KeyDigest</tt> element can be used as a trust an
<t>The Algorithm element in the KeyDigest element contains the DNSSEC si chor.</t>
gning <t>The <tt>KeyTag</tt> element in the <tt>KeyDigest</tt> element contain
s the key tag for
the DNSKEY record represented in this <tt>KeyDigest</tt>.</t>
<t>The <tt>Algorithm</tt> element in the <tt>KeyDigest</tt> element cont
ains the DNSSEC signing
algorithm identifier for the DNSKEY record represented in this algorithm identifier for the DNSKEY record represented in this
KeyDigest.</t> <tt>KeyDigest</tt>.</t>
<t>The DigestType element in the KeyDigest element contains the DNSSEC d <t>The <tt>DigestType</tt> element in the <tt>KeyDigest</tt> element con
igest tains the DNSSEC digest
algorithm identifier for the DNSKEY record represented in this algorithm identifier for the DNSKEY record represented in this
KeyDigest.</t> <tt>KeyDigest</tt>.</t>
<t>The Digest element in the KeyDigest element contains the hexadecimal <t>The <tt>Digest</tt> element in the <tt>KeyDigest</tt> element contain
s 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.</t> <tt>KeyDigest</tt>.</t>
<t>The publickeyinfo named pattern in the KeyDigest element contains two <t>The <tt>publickeyinfo</tt> named pattern in the <tt>KeyDigest</tt> el
mandatory elements: ement contains
the base64 representation of the public key for the DNSKEY record represented in two mandatory elements: the base64 representation of the public key
this KeyDigest, for the DNSKEY record represented in this <tt>KeyDigest</tt> and the fla
and the flags of the DNSKEY record represented in this KeyDigest. gs of
The publickeyinfo named pattern is optional and is new in this version of the sp the DNSKEY record represented in this <tt>KeyDigest</tt>. The <tt>publi
ecification. ckeyinfo</tt>
It can be useful when IANA has a trust anchor that has not yet been published named pattern is optional and is new in this
in the DNS root, and for calculating a comparison to the Digest element.</t> specification. It can be useful when IANA has a trust anchor that has
not yet been published in the DNS root and for calculating a
comparison to the <tt>Digest</tt> element.</t>
</section> </section>
<section anchor="xml-example"> <section anchor="xml-example">
<name>XML Example</name> <name>XML Example</name>
<t>The following is an example of what the trust anchor file might look
like. <t>The following is an example of what
The full public key is only given for the trust anchor that does not have the trust anchor file might look like. The full public key
a validFrom ttime in the past.</t> is only given for a trust anchor that does not have a <tt>validFrom</tt>
<sourcecode type="XML"><![CDATA[ time in the past.</t>
<sourcecode type="xml"><![CDATA[
<?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>
<Algorithm>8</Algorithm> <Algorithm>8</Algorithm>
skipping to change at line 265 skipping to change at line 274
<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>
]]></sourcecode> ]]></sourcecode>
<t>The DS RRset derived from this example would be:</t> <t>The DS RRset derived from this example is:</t>
<sourcecode type="Zone"><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
. IN DS 20326 8 2 . IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
. IN DS 38696 8 2 . IN DS 38696 8 2
683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
]]></sourcecode> ]]></sourcecode>
<t>Note that this DS record set only has two records.
The potential third record, the one that would have included the key tag 19036, <t>Note that this DS record set only has two records.
is already invalid based on the validUntil attribute's value and is thus not par A potential third record, one that includes the key tag 19036, is already invali
t of the trust anchor set.</t> d based on the <tt>validUntil</tt> attribute's value and is thus not part of the
<t>The DNSKEY RRset derived from this example would be:</t> trust anchor set.</t>
<sourcecode type="Zone"><![CDATA[ <t>The DNSKEY RRset derived from this example is:</t>
<sourcecode type="dns-rr"><![CDATA[
. 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=
]]></sourcecode> ]]></sourcecode>
<t>Note that this DNSKEY record set only has one record. <t>Note that this DNSKEY record set only has one record.
One potential second record, the one that would have been based on the key tag 1 A potential second record, one based on the key tag 19036, is already invalid ba
9036, is already invalid based on the validUntil attribute's value and is thus n sed on the <tt>validUntil</tt> attribute's value and is thus not part of the tru
ot part of the trust anchor set. st anchor set.
The other potential second record, the one that would have been based on the key Another potential second record, one based on the key tag 38696, does not contai
tag 38696, does not contain the optional publickeyinfo named pattern and theref n the optional <tt>publickeyinfo</tt> named pattern; therefore, the DNSKEY recor
ore the DNSKEY record for it cannot be calculated.</t> d for it cannot be calculated.</t>
</section> </section>
</section> </section>
<section anchor="retrieving"> <section anchor="retrieving">
<name>Root Zone Trust Anchor Retrieval</name> <name>Root Zone Trust Anchor Retrieval</name>
<section anchor="retrieving-trust-anchors-with-https-and-http"> <section anchor="retrieving-trust-anchors-with-https-and-http">
<name>Retrieving Trust Anchors with HTTPS and HTTP</name> <name>Retrieving Trust Anchors with HTTPS and HTTP</name>
<t>Trust anchors are available for retrieval using HTTPS and HTTP.</t>
<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 <t>In this section, all URLs are given using the "https:" scheme. If
HTTPS cannot be used, replace the "https:" scheme with "http:".</t> 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 <t>The URL for retrieving the set of hashes in the XML document describe
<xref target="ta_formats"/> is d in <xref target="ta_formats"/> is <eref target="https://data.iana.org/root-anc
&lt;https://data.iana.org/root-anchors/root-anchors.xml&gt;.</t> hors/root-anchors.xml" brackets="angle"/>.</t>
</section> </section>
<section anchor="trusting_anchors"> <section anchor="trusting_anchors">
<name>Accepting DNSSEC Trust Anchors</name> <name>Accepting DNSSEC Trust Anchors</name>
<t>A validator operator can choose whether or not to accept the trust <t>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.</t> anchor data.</t>
<t>It is important to note that the ICANN CA is not a DNSSEC trust <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 anchor. Instead, it is an optional mechanism for verifying the
content and origin of the XML and certificate trust anchors.</t> 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 <t>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) <xref target="RFC5652"/> signature that chain s to Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> signature that chain s to
the ICANN CA with the XML file.<br/> the ICANN CA with the XML document.
This can be useful for validator operators who have received a copy 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. of the ICANN CA's public key in a trusted out-of-band fashion.
The URL for a detached CMS signature The URL for a detached CMS signature
for the XML file is for the XML document is
&lt;https://data.iana.org/root-anchors/root-anchors.p7s&gt;.</t> <eref target="https://data.iana.org/root-anchors/root-anchors.p7s" brackets="ang
<t>Another method IANA uses to help validator operators verify the le"/>.</t>
<t>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 <bcp14>SHOULD</bcp14> be used instead of HTTP in "data.iana.org" web server, HTTPS <bcp14>SHOULD</bcp14> be used instead of HTTP in
order to have assurance of data origin.</t> order to have assurance of data origin.</t>
</section> </section>
<section anchor="changes-in-the-trust-model-for-distribution"> <section anchor="changes-in-the-trust-model-for-distribution">
<name>Changes in the Trust Model for Distribution</name> <name>Changes in the Trust Model for Distribution</name>
<t>IANA used to distribute the trust anchors as a self-signed PGP messag e <t>IANA used to distribute trust anchors as a self-signed Pretty Good Pr ivacy (PGP) message
and as a self-issued certificate signing request; this was described in <xref ta rget="RFC7958"/>. and as a self-issued certificate signing request; this was described in <xref ta rget="RFC7958"/>.
This document removes those methods because they relied on a trust model This document removes those methods because they rely on a trust model
that mixed out-of-band trust of authentication keys with out-of-band trust of th that mixes out-of-band trust of authentication keys with out-of-band trust of th
e DNSSEC root keys. e DNSSEC root keys.
Note, however, that cryptographic assurance for the contents of the trust anchor now Note, however, that cryptographic assurance for the contents of the trust anchor now
comes from the web PKI or the ICANN CA as described in <xref target="trusting_an chors"/>. comes from the Web PKI or the ICANN CA as described in <xref target="trusting_an chors"/>.
This cryptographic assurance is bolstered by informal comparisons made by users of the 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 ar e using.</t> trust anchors, such as software vendors comparing the trust anchor files they ar e using.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document describes how DNSSEC trust anchors for the root zone of <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 the DNS are published. Many DNSSEC clients will only configure IANA-issued
trust anchors for the DNS root to perform validation. As a trust anchors for the DNS root to perform validation. As a
consequence, reliable publication of trust anchors is important.</t> consequence, reliable publication of trust anchors is important.</t>
<t>This document aims to specify carefully the means by which such trust <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 anchors are published, with the goal of making it easier for those
trust anchors to be integrated into user environments. trust anchors to be integrated into user environments.
Some of the methods described (such as accessing over the web Some of the methods described (such as accessing over the Web
with or without verifying the signature on the file) have different security pro perties; with or without verifying the signature on the file) have different security pro perties;
users of the trust anchor file need to consider these when choosing whether to l oad the set of trust anchors.</t> users of the trust anchor file need to consider these when choosing whether to l oad the set of trust anchors.</t>
<section anchor="security-considerations-for-relying-parties"> <section anchor="security-considerations-for-relying-parties">
<name>Security Considerations for Relying Parties</name> <name>Security Considerations for Relying Parties</name>
<t>The body of this document does not specify any particular behavior fo r relying parties. <t>The body of this document does not specify any particular behavior fo r relying parties.
In specific, it does not say how a relying party should treat the trust anchor f ile as a whole. 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 attent ion for relying parties.</t> However, some of the contents of the trust anchor file require particular attent ion for relying parties.</t>
<section anchor="validuntil"> <section anchor="validuntil">
<name>validUntil</name> <name><tt>validUntil</tt></name>
<t>Note that the <tt>validUntil</tt> attribute of the KeyDigest elemen
t is optional. <t>Note that the <tt>validUntil</tt> attribute of the <tt>KeyDigest</tt
If the relying party is using a trust anchor that has a KeyDigest element > element is optional.
If the relying party is using a trust anchor that has a <tt>KeyDigest</tt> eleme
nt
that does not have a <tt>validUntil</tt> attribute, it can change to a trust anc hor that does not have a <tt>validUntil</tt> attribute, it can change to a trust anc hor
with a KeyDigest element that does have a <tt>validUntil</tt> attribute, with a <tt>KeyDigest</tt> element that does have a <tt>validUntil</tt> attribute ,
as long as that trust anchor's <tt>validUntil</tt> attribute is in the future an d the as long as that trust anchor's <tt>validUntil</tt> attribute is in the future an d the
KeyTag, Algorithm, DigestType, and Digest elements of the KeyDigest are the same <tt>KeyTag</tt>, <tt>Algorithm</tt>, <tt>DigestType</tt>, and <tt>Digest</tt> el
as the previous trust anchor.</t> ements of the <tt>KeyDigest</tt> are the same as those in the previous trust anc
<t>Relying parties <bcp14>SHOULD NOT</bcp14> use a KeyDigest outside o hor.</t>
f the time range given <t>Relying parties <bcp14>SHOULD NOT</bcp14> use a <tt>KeyDigest</tt>
outside of the time range given
in the <tt>validFrom</tt> and <tt>validUntil</tt> attributes.</t> in the <tt>validFrom</tt> and <tt>validUntil</tt> attributes.</t>
</section> </section>
<section anchor="comparison-of-digest-and-a-publickeyinfo"> <section anchor="comparison-of-digest-and-a-publickeyinfo">
<name>Comparison of Digest and a publickeyinfo</name> <name>Comparison of <tt>Digest</tt> and <tt>publickeyinfo</tt></name>
<t>A KeyDigest element can contain both a Digest and a publickeyinfo n <t>A <tt>KeyDigest</tt> element can contain both a <tt>Digest</tt> and
amed pattern. a <tt>publickeyinfo</tt> named pattern.
If the Digest element would not be a proper DS record for a DNSKEY record repres If the <tt>Digest</tt> element would not be a proper DS record for a DNSKEY reco
ented by the publickeyinfo named pattern, rd represented by the <tt>publickeyinfo</tt> named pattern,
relying parties <bcp14>MUST NOT</bcp14> use that KeyDigest as a trust anchor. relying parties <bcp14>MUST NOT</bcp14> use that <tt>KeyDigest</tt> as a trust a
A relying party that wants to make such a comparison needs to marshall the eleme nchor.
nts of the DNSKEY record that became the DS record using the algorithm specified A relying party that wants to make such a comparison needs to marshal the elemen
in Section 5.1.4 of <xref target="RFC4034"/>.</t> ts of the DNSKEY record that became the DS record using the algorithm specified
in <xref section="5.1.4" sectionFormat="of" target="RFC4034"/>.</t>
<t>Relying parties need to implement trust anchor matching carefully. <t>Relying parties need to implement trust anchor matching carefully.
A single trust anchor represented by a KeyDigest element can potentially change A single trust anchor represented by a <tt>KeyDigest</tt> element can potentiall
its Digest and KeyTag values between two versions of the trust anchor file, for y change its <tt>Digest</tt> and <tt>KeyTag</tt> values between two versions of
example when the key is revoked or the flag value changes for some other reason. the trust anchor file, for example, when the key is revoked or the flag value ch
Relying parties which fail to take this property into account are at risk of usi anges for some other reason.
ng an incorrect set of trust anchors.</t> Relying parties that fail to take this property into account are at risk of usin
g an incorrect set of trust anchors.</t>
</section> </section>
<section anchor="different-outputs-from-processing-the-trust-anchor-file "> <section anchor="different-outputs-from-processing-the-trust-anchor-file ">
<name>Different Outputs from Processing the Trust Anchor File</name> <name>Different Outputs from Processing the Trust Anchor File</name>
<t>Relying parties that require the optional publickeyinfo named patte rn to create trust anchors will store fewer trust anhcors than those that only r equire a Digest element. <t>Relying parties that require the optional <tt>publickeyinfo</tt> na med pattern to create trust anchors will store fewer trust anchors than those th at only require a <tt>Digest</tt> element.
Thus, two systems processing the same trust anchor file can end up with a differ ent set of trust anchors.</t> Thus, two systems processing the same trust anchor file can end up with a differ ent set of trust anchors.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>Each time IANA produces a new trust anchor, <t>Each time IANA produces a new trust anchor,
it <bcp14>MUST</bcp14> publish that trust anchor using the format described in t his document.</t> it <bcp14>MUST</bcp14> publish that trust anchor using the format described in t his document.</t>
<t>IANA <bcp14>MAY</bcp14> delay the publication of a new trust anchor for operational reasons, <t>IANA <bcp14>MAY</bcp14> delay the publication of a new trust anchor for operational reasons,
such as having a newly-created key in multiple facilities.</t> such as having a newly created key in multiple facilities.</t>
<t>When a trust anchor that was previously published is no longer suitable for use, <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. IANA <bcp14>MUST</bcp14> update the trust anchor file 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> 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 crypt ographic keys for the DNS root zone are managed <t>More information about IANA's policies and procedures for how the crypt ographic keys for the DNS root zone are managed
(also known as "DNSSEC Practice Statements" or "DPSs") (also known as "DNSSEC Practice Statements" or "DPSs")
can be found at <eref target="https://www.iana.org/dnssec/procedures">https://ww can be found at <eref target="https://www.iana.org/dnssec/procedures" brackets="
w.iana.org/dnssec/procedures</eref>.</t> angle"/>.</t>
<t><xref target="RFC7958"/> defined id-mod-dns-resource-record, value 70, <t><xref target="RFC7958"/> defined id-mod-dns-resource-record, value 70,
which was added to the the "SMI Security for PKIX Module Identifier" registry. which was added to the "SMI Security for PKIX Module Identifier" registry.
This document no longer uses that identifier.</t> This document does not use that identifier.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1034">
<front> <reference anchor='W3C.REC-xml11-20060816'
<title>Domain names - concepts and facilities</title> target='https://www.w3.org/TR/2006/REC-xml11-20060816'>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris <front>
"/> <title>Extensible Markup Language (XML) 1.1 (Second Edition)</title>
<date month="November" year="1987"/>
<abstract> <author initials='T.' surname='Bray' fullname='Tim Bray'>
<t>This RFC is the revised basic definition of The Domain Name Sys <organization />
tem. It obsoletes RFC-882. This memo describes the domain style names and their </author>
used for host address look up and electronic mail forwarding. It discusses the c
lients and servers in the domain name system and the protocol used between them. <author initials='J.' surname='Paoli' fullname='Jean Paoli'>
</t> <organization />
</abstract> </author>
</front>
<seriesInfo name="STD" value="13"/> <author initials='M.' surname='Sperberg-McQueen' fullname='Michael Sperberg-McQu
<seriesInfo name="RFC" value="1034"/> een'>
<seriesInfo name="DOI" value="10.17487/RFC1034"/> <organization />
</reference> </author>
<reference anchor="RFC1035">
<front> <author initials='E.' surname='Maler' fullname='Eve Maler'>
<title>Domain names - implementation and specification</title> <organization />
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris </author>
"/>
<date month="November" year="1987"/> <author initials='F.' surname='Yergeau' fullname='François Yergeau'>
<abstract> <organization />
<t>This RFC is the revised specification of the protocol and forma </author>
t used in the implementation of the Domain Name System. It obsoletes RFC-883. Th
is memo documents the details of the domain name client - server communication.< <author initials='J.' surname='Cowan' fullname='John Cowan'>
/t> <organization />
</abstract> </author>
</front>
<seriesInfo name="STD" value="13"/> <date month='August' day='16' year='2006' />
<seriesInfo name="RFC" value="1035"/> </front>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference> <seriesInfo name='W3C Recommendation' value='REC-xml11-20060816' />
<reference anchor="RFC4033"> <format type='HTML' target='https://www.w3.org/TR/2006/REC-xml11-20060816' />
<front> </reference>
<title>DNS Security Introduction and Requirements</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
<author fullname="R. Arends" initials="R." surname="Arends"/> 34.xml"/>
<author fullname="R. Austein" initials="R." surname="Austein"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
<author fullname="M. Larson" initials="M." surname="Larson"/> 35.xml"/>
<author fullname="D. Massey" initials="D." surname="Massey"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<author fullname="S. Rose" initials="S." surname="Rose"/> 33.xml"/>
<date month="March" year="2005"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<abstract> 34.xml"/>
<t>The Domain Name System Security Extensions (DNSSEC) add data or <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
igin authentication and data integrity to the Domain Name System. This document 11.xml"/>
introduces these extensions and describes their capabilities and limitations. Th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
is document also discusses the services that the DNS security extensions do and 52.xml"/>
do not provide. Last, this document describes the interrelationships between the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t> 58.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
</front> 57.xml"/>
<seriesInfo name="RFC" value="4033"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<seriesInfo name="DOI" value="10.17487/RFC4033"/> 64.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<reference anchor="RFC4034"> 19.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<title>Resource Records for the DNS Security Extensions</title> 74.xml"/>
<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>This document is part of a family of documents that describe th
e DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection
of resource records and protocol modifications that provide source authenticati
on for the DNS. This document defines the public key (DNSKEY), delegation signer
(DS), resource record digital signature (RRSIG), and authenticated denial of ex
istence (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>
</front>
<seriesInfo name="RFC" value="4034"/>
<seriesInfo name="DOI" value="10.17487/RFC4034"/>
</reference>
<reference anchor="RFC5011">
<front>
<title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</tit
le>
<author fullname="M. StJohns" initials="M." surname="StJohns"/>
<date month="September" year="2007"/>
<abstract>
<t>This document describes a means for automated, authenticated, a
nd authorized updating of DNSSEC "trust anchors". The method provides protection
against N-1 key compromises of N keys in the trust point key set. Based on the
trust established by the presence of a current anchor, other anchors may be adde
d at the same place in the hierarchy, and, ultimately, supplant the existing anc
hor(s).</t>
<t>This mechanism will require changes to resolver management beha
vior (but not resolver resolution behavior), and the addition of a single flag b
it 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 arbitra
ry 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 cryptogr
aphically 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 de
scribes the format and publication mechanisms IANA has used to distribute the DN
SSEC 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 DNS
SEC algorithms and resource records added to IANA registries. It updates RFC 601
4 to include hash algorithms for Delegation Signer (DS) records and NextSECure v
ersion 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It a
lso updates RFCs 5155 and 6014, which have requirements for DNSSEC algorithms, a
nd 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 algorithm
s 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 describes the DNS Security Extensions (commonly c
alled "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a ha
ndful of others. One purpose is to introduce all of the RFCs in one place so tha
t the reader can understand the many aspects of DNSSEC. This document does not u
pdate any of those RFCs. A second purpose is to state that using DNSSEC for orig
in authentication of DNS data is the best current practice. A third purpose is t
o 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 words for use in RFCs to Indicate Requirement Levels</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</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</ti
tle>
<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 protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined 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>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="DPS" target="https://www.iana.org/dnssec/procedures"> <reference anchor="DPS" target="https://www.iana.org/dnssec/procedures">
<front> <front>
<title>DNSSEC Practice Statement for the Root Zone KSK Operator</tit le> <title>DNSSEC Practice Statement for the Root Zone KSK Operator</tit le>
<author> <author>
<organization>Root Zone KSK Operator Policy Management Authority</ organization> <organization>Root Zone KSK Operator Policy Management Authority</ organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="RELAX-NG" target="https://www.oasis-open.org/committe es/relax-ng/compact-20021121.html"> <reference anchor="RELAX-NG" target="https://www.oasis-open.org/committe es/relax-ng/compact-20021121.html">
<front> <front>
<title>RELAX NG Compact Syntax</title> <title>RELAX NG Compact Syntax</title>
<author initials="J." surname="Clark" fullname="James Clark"> <author initials="J." surname="Clark" fullname="James Clark">
<organization/> <organization/>
</author> </author>
<date year="2002"/> <date month="November" year="2002"/>
</front> </front>
<refcontent>OASIS Committee Specification</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<?line 473?>
<section anchor="changes-from-rfc-7958"> <section anchor="changes-from-rfc-7958">
<name>Changes from RFC 7958</name> <name>Changes from RFC 7958</name>
<t>This version of the document includes the following changes:</t>
<t>This document includes the following changes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>There is a significant technical change from erratum 5932 &lt;https <t>Made a significant technical change per <eref target="https://www.r
://www.rfc-editor.org/errata/eid5932&gt;. fc-editor.org/errata/eid5932" brackets="angle">Erratum ID 5932</eref>.
This is in the seventh paragraph of <xref target="xml_semantics"/>.</t> This change is in the seventh paragraph of <xref target="xml_semantics"/>.</t>
</li> </li>
<li> <li>
<t>Added the optional publickeyinfo named pattern with two mandatory e lements, PublicKey and Flags.</t> <t>Added the optional <tt>publickeyinfo</tt> named pattern with two ma ndatory elements, <tt>PublicKey</tt> and <tt>Flags</tt>.</t>
</li> </li>
<li> <li>
<t>Removed the certificates and certificate signing mechanisms.</t> <t>Removed the certificates and certificate signing mechanisms.</t>
</li> </li>
<li> <li>
<t>Removed the detached OpenPGP signature mechanism.</t> <t>Removed the detached OpenPGP signature mechanism.</t>
</li> </li>
<li> <li>
<t>The reference to the DNSSEC Practice Statement <xref target="DPS"/> was updated.</t> <t>Updated the reference to the DNSSEC Practice Statement <xref target ="DPS"/>.</t>
</li> </li>
<li> <li>
<t>Say explicitly that the XML documents might have XML comments in th em.</t> <t>Stated explicitly that the XML documents might have XML comments in them.</t>
</li> </li>
<li> <li>
<t>Clarified the use of the detached CMS signature.</t> <t>Clarified the use of the detached CMS signature.</t>
</li> </li>
<li> <li>
<t>Updated the IANA Considerations section to indicate requirements on IANA.</t> <t>Updated the <xref target="iana-considerations" format="title"/> sec tion to indicate requirements on IANA.</t>
</li> </li>
<li> <li>
<t>Simplified the description of using the validFrom and validUntil at tributes.</t> <t>Simplified the description of using the <tt>validFrom</tt> and <tt> validUntil</tt> attributes.</t>
</li> </li>
<li> <li>
<t>Added new security considerations.</t> <t>Added new security considerations.</t>
</li> </li>
<li> <li>
<t>There was a bit of editorial cleanup.</t> <t>Made some editorial changes.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="historical-note"> <section anchor="historical-note">
<name>Historical Note</name> <name>Historical Note</name>
<t>The first KSK for use in the root zone of the DNS was <t>The first Key Signing Key (KSK) for use in the root zone of the DNS was
generated at a key ceremony at the ICANN Key Management Facility generated at a key ceremony at the ICANN Key Management Facility
(KMF) in Culpeper, Virginia, USA on 2010-06-16. This key (KMF) in Culpeper, Virginia, USA on 2010-06-16. This key
entered production during a second key ceremony held at an entered production during a second key ceremony held at an
ICANN KMF in El Segundo, California, USA on 2010-07-12. ICANN KMF in El Segundo, California, USA on 2010-07-12.
The resulting trust anchor was first published on 2010-07-15.</t> 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 <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 201 6-10-27. generated at key ceremony #27 at the ICANN KMF in Culpeper, Virginia, USA on 201 6-10-27.
This key entered production during key ceremony #28 held at This key entered production during key ceremony #28 held at
the ICANN KMF in El Segundo, California, USA on 2017-02-02. the ICANN KMF in El Segundo, California, USA on 2017-02-02.
The resulting trust anchor was first published on 2018-11-11.</t> The resulting trust anchor was first published on 2018-11-11.</t>
<t>More information about the key ceremonies, <t>More information about the key ceremonies,
including full records of previous ceremonies and plans for future ceremonies, including full records of previous ceremonies and plans for future ceremonies,
can be found at <https://www.iana.org/dnssec/ceremonies&gt;.</t> can be found at <eref target="https://www.iana.org/dnssec/ceremonies" brackets=" angle"/&gt;.</t>
</section> </section>
<section anchor="acknowledgemwents"> <section anchor="acknowledgemwents" numbered="false">
<name>Acknowledgemwents</name> <name>Acknowledgements</name>
<t>Many pioneers paved the way for the deployment of DNSSEC in the root <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 zone of the DNS, and the authors hereby acknowledge their substantial
collective contribution.</t> collective contribution.</t>
<t>RFC 7958 incorporated suggestions made by Alfred Hoenes and Russ <t>RFC 7958 incorporated suggestions made by <contact fullname="Alfred
Housley, whose contributions are appreciated.</t> Hoenes"/> and <contact fullname="Russ Housley"/>, whose contributions
are appreciated.</t>
</section> </section>
</back> </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==
</rfc> </rfc>
 End of changes. 74 change blocks. 
569 lines changed or deleted 270 lines changed or added

This html diff was produced by rfcdiff 1.48.