One document matched: draft-jabley-dnssec-trust-anchor-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY rfc1035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY rfc2616 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2818 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc2986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY rfc3339 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml">
<!ENTITY rfc4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4034 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc4509 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4509.xml">
<!ENTITY rfc4880 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5011 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY rfc5155 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5155.xml">
<!ENTITY rfc5702 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5702.xml">
<!ENTITY rfc5751 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY rfc6781 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-jabley-dnssec-trust-anchor-07"
ipr="trust200902">
<front>
<title abbrev="Root Zone Trust Anchor Publication">DNSSEC Trust
Anchor Publication for the Root Zone</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>ICANN</organization>
<address>
<postal>
<street>12025 Waterfront Drive, Suite 300</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90094-2536</code>
<country>US</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</email>
</address>
</author>
<author fullname="Jakob Schlyter" initials="J." surname="Schlyter">
<organization abbrev="Kirei">Kirei AB</organization>
<address>
<email>jakob@kirei.se</email>
</address>
</author>
<author fullname="Guy Bailey" initials="G." surname="Bailey">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<phone>+1 425 538 6153 x86153</phone>
<email>gubailey@microsoft.com</email>
</address>
</author>
<date month="June" year="2013"/>
<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 how such trust anchors are
published.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The Domain Name System (DNS) is described in <xref
target="RFC1034" /> and <xref target="RFC1035" />. Security
extensions to the DNS (DNSSEC) are described in <xref
target="RFC4033" />, <xref target="RFC4034" />, <xref
target="RFC4035" />, <xref target="RFC4509" />, <xref
target="RFC5155" /> and <xref target="RFC5702" />.</t>
<t>A discussion of operational practices relating to DNSSEC can be found
in <xref target="RFC6781" />.</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. Signatures are validated by following a chain of signatures to
a key called a "trust anchor". The reason for trusting such a key 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. A detailed description of corresponding
key management practices can be found in <xref target="DPS"/>, which can
be retrieved from the IANA Repository located at <eref
target="https://www.iana.org/dnssec/"/>.</t>
<t>This document describes the distribution of the DNSSEC trust anchors
from IANA. This document is concerned only with the distribution of trust
anchors for the root zone, although the data formats and the publication
and retrieval methods described here might can be adapted for other
uses.</t>
</section>
<section title="Root Zone Trust Anchor Publication">
<t>Trust anchors for the root zone are published in two formats,
each of which is described in this document:
<list style="symbols">
<t>as the hashes of the corresponding DNSKEY records, consistent
with the defined presentation format of Delegation Signer (DS)
resource records <xref target="RFC4034"/>, contained within an
XML document, as described in <xref target="xml"/>, and</t>
<t>as Certificate Signing Requests (CSRs) in PKCS#10 format <xref
target="RFC2986"/> for further processing by other entities such as
Certification Authorities and validation of proof of possession of
the corresponding private keys, as described in <xref
target="pkcs10"/>.</t>
</list>
</t>
<section title="XML" anchor="xml">
<t>Trust anchors are published in an XML document whose schema is
described in <xref target="schema" />. The document contains a complete
set of trust anchors for the root zone, including anchors suitable for
immediate use and also historical data. Each trust anchor optionally
includes one or more Certificate elements, with Uniform Resource
Locators (URLs) for retrieving corresponding X.509 certificates.</t>
<t>Examples of trust anchors packaged and signed for
publication can be found in <xref target="examples" />.</t>
</section>
<section title="Certificate Signing Request (PKCS#10)" anchor="pkcs10">
<t>To facilitate signing the trust anchor by a public key
infrastructure, trust anchors are also published as
Certificate Signing Requests (CSRs) in <xref
target="RFC2986">PKCS#10 format</xref>.</t>
<t>Each CSR will have a Subject with following attributes:
<list style="hanging">
<t hangText="O:">the string "ICANN".</t>
<t hangText="OU:">the string "IANA".</t>
<t hangText="CN:">the string "Root Zone KSK" followed
by the time and date of key generation in the format
specified in <xref target="RFC3339"/>,
e.g. "Root Zone KSK 2010-06-16T21:19:24+00:00".</t>
<t hangText="resourceRecord:">the hash of the public
key consistent with the presentation format of the
Delegation Signer (DS) <xref target="RFC4034"/>
resource record (see <xref
target="asn1-rr"/> for attribute definition).</t>
</list>
</t>
</section>
</section>
<section anchor="mechanisms" title="Root Zone Trust Anchor Retrieval">
<section title="HTTP" anchor="http">
<t>Trust anchors are available for retrieval using HTTP <xref
target="RFC2616" />.</t>
<t>The URL for retrieving the CSR is
<http://data.iana.org/root-anchors/key-label.csr>, with
"key-label" replaced by the key label of the corresponding KSK.</t>
<t>The URL for retrieving a signed X.509 certificate is
<http://data.iana.org/root-anchors/key-label.crt>,
with "key-label" again replaced as described above.</t>
<t>The URL for retrieving the complete trust anchor set is
<eref target="http://data.iana.org/root-anchors/root-anchors.xml"/>.</t>
<t>The URL for a detached S/MIME <xref target="RFC5751"/> signature
for the current trust anchor set, in XML format, is <eref
target="http://data.iana.org/root-anchors/root-anchors.p7s"/>.</t>
<t>The URL for a detached OpenPGP <xref target="RFC4880"/>
signature for the current trust anchor set, in XML format, is <eref
target="http://data.iana.org/root-anchors/root-anchors.asc"/>.</t>
</section>
<section title="HTTP Over TLS" anchor="HTTPOverTLS">
<t>Trust anchors are available for retrieval using HTTP over TLS
<xref target="RFC2818" />.</t>
<t>The URLs specified in <xref target="http"/> are also
available using HTTPS. That is:</t>
<t>The URL for retrieving the CSR is
<https://data.iana.org/root-anchors/key-label.csr>,
with "key-label" replaced by the key label of the
corresponding KSK.</t>
<t>The URL for retrieving a signed X.509 certificate is
<https://data.iana.org/root-anchors/key-label.crt>,
with "key-label" again replaced as described above.</t>
<t>The URL for retrieving the complete trust anchor set is <eref
target="https://data.iana.org/root-anchors/root-anchors.xml" />.</t>
<t>The URL for a detached S/MIME <xref target="RFC5751"/> signature
for the current trust anchor set is <eref
target="https://data.iana.org/root-anchors/root-anchors.p7s"
/>.</t>
<t>The URL for a detached OpenPGP <xref target="RFC4880"/>
signature for the current trust anchor set is <eref
target="https://data.iana.org/root-anchors/root-anchors.asc"
/>.</t>
<t>TLS sessions are authenticated with certificates presented from the
server. No client certificate verification is performed. The certificate
presented by the server is chosen such that it can be trusted using an
X.509 trust anchor that is believed to be well-known, e.g. one that
corresponds to a WebTrust-accredited Certificate Authority. Other TLS
authentication mechanisms may be considered in the future.</t>
</section>
<section title="Signature Verification" anchor="sigs">
<t>The OpenPGP <xref target="RFC4880"/> keys used to sign trust anchor
documents carry signatures from personal keys of staff who are able
to personally attest to their validity. Those staff members will
continue to make their personal keys freely available for
examination by third parties, e.g. by way of PGP key parties at
operator and IETF meetings. In this fashion a diverse set of paths
through the PGP web of trust will be maintained to the trust anchor
PGP keys.</t>
<t>An OpenPGP keyring containing public keys pertinent to
signature verification is published at <eref
target="http://data.iana.org/root-anchors/icann.pgp" />.
The public keys on that keyring will also be distributed
widely, e.g. to public PGP key servers.</t>
<t>Certificates used to create S/MIME <xref target="RFC5751"/>
signatures for the current trust anchor set, in XML format, are signed
by a Certificate Authority (CA) administered by ICANN as the IANA
functions operator and also optionally by well-known (e.g.
WebTrust-certified) CAs to facilitate signature validation with
widely-available X.509 trust anchors.</t>
</section>
</section>
<section title="Implementation Considerations">
<t>Note: This non-normative section gives suggestions for
implementing root zone trust anchor retrieval.</t>
<t>Root trust anchor retrieval by the HTTP or HTTP over TLS
transports has several implementation considerations to
ensure robustness, usability and secure operation.</t>
<section title="HTTP Over TLS Transport">
<t>The HTTP over TLS transport <xref target="RFC2818"/> is suggested
over the unencrypted HTTP transport <xref target="RFC2616"/> for
implementations using the XML-format root trust anchors, since the
latter transport does not provide authentication. It is not
suggested that implementations restrict certification path
validation of the HTTP over TLS transport session to the current or
historical certificate authorities used by the root trust anchor
server, since doing so would reduce robustness of the
implementation. It is suggested that the implementation configure
the HTTP over TLS transport library to validate the certification
path against certificate revocation lists <xref target="RFC5280"/>,
and reject self-signed certificates and certification paths that do
not terminate in a trusted certificate authority.</t>
<t>Implementations can allow configuration of the URL used
to retrieve the root trust anchor resources, but it is
suggested that the default configuration use the URLs
specified in <xref target="HTTPOverTLS"/>.</t>
</section>
<section title="XML Validation">
<t>Implementations may perform strict validation of the
retrieved XML document against the XML schema; however,
such an implementation would not be robust against future
changes in the XML schema. It is suggested that the
implementation perform "loose" validation, where unknown
attributes and elements are ignored. This suggestion
allows for future additions to the XML schema without
affecting existing implementations.</t>
</section>
<section title="Trust Anchor Validation">
<t>The implementation can ignore trust anchors for which
the Algorithm or DigestType elements refer to an unknown,
or unsupported algorithm. Additionally, trust anchors for
which the Algorithm or DigestType elements refer to a
deprecated algorithm can be ignored, provided that this
suggestion does not cause all trust anchors to be
ignored. Further, note that these suggestions may not
apply where an implementation shares trust anchors
between many DNS validating resolvers, since the set of
supported algorithms may vary between resolvers, and
could possibly be disjoint.</t>
<t>The implementation can also ignore a trust anchor when
the validUntil time, if present, is in the past. If the
implementation also supports automated updates of trust
anchors <xref target="RFC5011"/>, it can ignore trust
anchors where the current time subtracted from the
validFrom time, if present, is greater than the add-hold
down time <xref target="RFC5011"/> for the trust
point.</t>
<t>The implementation can reject any trust anchor for a
trust point other than the root zone.</t>
</section>
</section>
<section title="IANA Considerations">
<t>Key Signing Key (KSK) management for the root zone is an
IANA function. This document describes an initial set of
publication mechanisms for trust anchors related to that
management. In the future, additional publication schemes
may also be made available, in which case they will be
described in a new document that updates this one.</t>
<t>Existing mechanisms will not be deprecated without very
strong technical justification.</t>
<t>This document contains information about an existing
service, and has no IANA actions.</t>
</section>
<section title="Security Considerations">
<t>This document describes how DNSSEC trust anchors for the
root zone of the DNS are published. It is to be expected
that many DNSSEC clients will only configure a single trust
anchor to perform validation, and that the trust anchor
they use will be that of the root zone. 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, as an aid to the formats
and retrieval methods described here being integrated
usefully into user environments.</t>
</section>
<section title="Acknowledgements">
<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>This document incorporates suggestions made by Paul Hoffman
and Alfred Hoenes, whose contributions are appreciated.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1034;
&rfc1035;
&rfc2616;
&rfc2818;
&rfc2986;
&rfc3339;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4509;
&rfc4880;
&rfc5011;
&rfc5280;
&rfc5155;
&rfc5702;
&rfc5751;
&rfc6781;
</references>
<references title="Informative References">
<reference anchor="DPS">
<front>
<title abbrev="Root Zone KSK Operator DPS">DNSSEC Practice Statement for the Root Zone KSK Operator</title>
<author fullname="Fredrik Ljunggren" initials="F." surname="Ljunggren">
<organization>Kirei AB</organization>
</author>
<author fullname="Tomofumi Okubo" initials="T." surname="Okubo">
<organization>ICANN</organization>
</author>
<author fullname="Richard Lamb" initials="R." surname="Lamb">
<organization>ICANN</organization>
</author>
<author fullname="Jakob Schlyter" initials="J." surname="Schlyter">
<organization>Kirei AB</organization>
</author>
<date day="21" month="May" year="2010" />
</front>
<format type="TXT"
target="https://www.iana.org/dnssec/icann-dps.txt" />
</reference>
</references>
<section anchor="schema" title="Trust Anchor Publication Document Schema">
<t>A Relax NG Compact Schema for the documents used to publish
trust anchors can be found in <xref target="schemafig"/>.</t>
<figure anchor="schemafig">
<artwork>
<![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 },
element Certificate {
attribute source { xsd:string },
empty
}+
}
]]>
</artwork>
</figure>
</section>
<section anchor="examples" title="Example Signed Trust Anchor Set">
<t><xref target="eg1"/> describes two trust anchors for the
root zone such as might be retrieved using the URL <eref
target="https://data.iana.org/root-anchors/root-anchors.xml"/>.</t>
<figure anchor="eg1">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<TrustAnchor
id="AD42165F-B099-4778-8F42-D34A1D41FD93"
source="http://data.iana.org/root-anchors/root-anchors.xml">
<Zone>.</Zone>
<KeyDigest id="42"
validFrom="2010-07-01T00:00:00-00:00"
validUntil="2010-08-01T00:00:00-00:00">
<KeyTag>34291</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
</KeyDigest>
<KeyDigest id="53"
validFrom="2010-08-01T00:00:00-00:00">
<KeyTag>12345</KeyTag>
<Algorithm>5</Algorithm>
<DigestType>1</DigestType>
<Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
<Certificate
source="http://data.iana.org/root-anchors/Kexample1.crt"/>
<Certificate
source="http://data.iana.org/root-anchors/Kexample2.crt"/>
</KeyDigest>
</TrustAnchor>
]]>
</artwork>
</figure>
</section>
<section anchor="asn1-rr" title="ASN.1 Module for DNS Resource Record">
<figure>
<artwork>
<![CDATA[
ResourceRecord
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
caseIgnoreMatch FROM SelectedAttributeTypes
{ joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }
;
iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) private(4) enterprise(1) 1000 }
iana-dns OBJECT IDENTIFIER ::= { iana 53 }
resourceRecord ATTRIBUTE ::= {
WITH SYNTAX IA5String
EQUALITY MATCHING RULE caseIgnoreIA5Match
ID iana-dns
}
END
]]>
</artwork>
</figure>
</section>
<section title="Historical Note">
<t>The first KSK for use in the root zone of the DNS was
generated at a key ceremony at an ICANN Key Management Facility
(KMF) in Culpeper, Virginia, USA on 2010-06-16. This key
entered production during a second key ceremony held at an
ICANN KMF in El Segundo, California, USA on 2010-07-12.
The resulting trust anchor was first published on 2010-07-15.</t>
</section>
<section title="About this Document">
<t>[RFC Editor: please remove this section, including all
subsections, prior to publication.]</t>
<section title="Discussion">
<t>This document is not the product of any IETF working
group. However, communities interested in similar technical
work can be found at the IETF in the DNSOP and DNSEXT
working groups.</t>
<t>The team responsible for deployment of DNSSEC in the
root zone can be reached at rootsign@icann.org.</t>
<t>The authors also welcome feedback sent to them directly.</t>
</section>
<section title="Document History">
<section title="draft-jabley-dnssec-trust-anchor-00">
<t>This document is based on earlier documentation used
within and published by the team responsible for DNSSEC
deployment in the root zone. This is the first revision
circulated with the intention of publication in the RFC
series.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-01">
<t>Incorporated initial community suggestions. Editorial
improvements. Allocate OID and clean up syntax of ASN.1
module.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-02">
<t>Draft expired.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-04">
<t>Added the optional <Certificate> element to the XML
schema to provide a mechanism for locating external
X.509 certificates relating to a particular key.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-05">
<t>Update author address.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-06">
<t>Update references.</t>
</section>
<section title="draft-jabley-dnssec-trust-anchor-07">
<t>Minor changes based on review by Paul Hoffman.</t>
</section>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 03:37:54 |