One document matched: draft-jabley-dnssec-trust-anchor-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-icann-dnssec-trust-anchor.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2010-09-29T12:21:33Z -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- $Id: draft-icann-dnssec-trust-anchor.xml 1484 2010-09-16 16:58:13Z jabley $ -->
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!-- xml2rfc-processed-entity rfc1034 -->
<!-- xml2rfc-processed-entity rfc1035 -->
<!-- xml2rfc-processed-entity rfc2616 -->
<!-- xml2rfc-processed-entity rfc2818 -->
<!-- xml2rfc-processed-entity rfc2986 -->
<!-- xml2rfc-processed-entity rfc3339 -->
<!-- xml2rfc-processed-entity rfc4033 -->
<!-- xml2rfc-processed-entity rfc4034 -->
<!-- xml2rfc-processed-entity rfc4035 -->
<!-- xml2rfc-processed-entity rfc4641 -->
<!-- xml2rfc-processed-entity rfc4880 -->
<!-- xml2rfc-processed-entity ICANNDPS -->
<!-- xml2rfc-processed-entity FRONT -->
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="info" docName="draft-jabley-dnssec-trust-anchor-00"
ipr="trust200902">
<?rfc linefile="1:draft-icann-dnssec-trust-anchor.front"?><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>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</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>
<postal>
<street>P.O. Box 53204</street>
<city>Goteborg</city>
<code>SE-400 16</code>
<country>Sweden</country>
</postal>
<email>jakob@kirei.se</email>
</address>
</author>
<date day="29" month="September" year="2010"/>
<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>
<?rfc linefile="29:draft-icann-dnssec-trust-anchor.xml"?>
<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" /> and <xref
target="RFC4035" />.</t>
<t>A discussion of operational practices relating to DNSSEC
can be found in <xref target="RFC4641" />.</t>
<t>In DNSSEC a secure response to a query is one which is
cryptographically signed and validated. An individual
signature is validated by following a chain of signatures
to a key which is trusted for some extra-protocol reason.</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 DNSSEC trust
anchors. Whilst the data formats and the publication and
retrieval methods described in this document might well be
adapted for other uses, this document's focus is more
specific and is concerned only with the distribution of
trust anchors for the root zone.</t>
</section>
<section title="Root Zone Trust Anchor Publication">
<t>Trust anchors for the root zone are published in two formats:
<list style="symbols">
<t>as the hash of the corresponding DNSKEYs 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 Certification Authorities
and validation of proof of possession of the corresponding
private keys, as described in <xref target="pkcs10"/>.</t>
</list>
Both formats are described in this document.</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.</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 the IANA-signed 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 signature for the current
trust anchor set 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 is <eref
target="http://data.iana.org/root-anchors/root-anchors.asc"
/>.</t>
</section>
<section title="HTTP Over TLS">
<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 the IANA-signed 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 signature for the complete
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>
</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 signatures will be
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="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 be also be made available, in which case they will be
described in a new document which 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>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"?>
<reference anchor='RFC1034'>
<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>
<?rfc linefile="242:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"?>
<reference anchor='RFC1035'>
<front>
<title abbrev='Domain Implementation and Specification'>Domain names - implementation and specification</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1035' />
<format type='TXT' octets='125626' target='http://www.rfc-editor.org/rfc/rfc1035.txt' />
</reference>
<?rfc linefile="243:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<?rfc linefile="244:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<reference anchor='RFC2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2000' month='May' />
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2818' />
<format type='TXT' octets='15170' target='http://www.rfc-editor.org/rfc/rfc2818.txt' />
</reference>
<?rfc linefile="245:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml"?>
<reference anchor='RFC2986'>
<front>
<title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'>
<organization /></author>
<author initials='B.' surname='Kaliski' fullname='B. Kaliski'>
<organization /></author>
<date year='2000' month='November' />
<abstract>
<t>This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2986' />
<format type='TXT' octets='27794' target='http://www.rfc-editor.org/rfc/rfc2986.txt' />
</reference>
<?rfc linefile="246:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml"?>
<reference anchor='RFC3339'>
<front>
<title>Date and Time on the Internet: Timestamps</title>
<author initials='G.' surname='Klyne' fullname='Graham Klyne' role='editor'>
<organization>Clearswift Corporation</organization>
<address>
<postal>
<street>1310 Waterside</street>
<street>Arlington Business Park</street>
<city>Theale</city>
<region>Reading</region>
<code>RG7 4SA</code>
<country>UK</country></postal>
<phone>+44 11 8903 8903</phone>
<facsimile>+44 11 8903 9000</facsimile>
<email>GK@ACM.ORG</email></address></author>
<author initials='C.' surname='Newman' fullname='Chris Newman'>
<organization>Sun Microsystems</organization>
<address>
<postal>
<street>1050 Lakes Drive, Suite 250</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>USA</country></postal>
<email>chris.newman@sun.com</email></address></author>
<date year='2002' month='July' />
<abstract>
<t>
This document defines a date and time format for use in Internet
protocols that is a profile of the ISO 8601 standard for
representation of dates and times using the Gregorian calendar.
</t></abstract></front>
<seriesInfo name='RFC' value='3339' />
<format type='TXT' octets='35064' target='http://www.rfc-editor.org/rfc/rfc3339.txt' />
<format type='HTML' octets='61277' target='http://xml.resource.org/public/rfc/html/rfc3339.html' />
<format type='XML' octets='37259' target='http://xml.resource.org/public/rfc/xml/rfc3339.xml' />
</reference>
<?rfc linefile="247:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"?>
<reference anchor='RFC4033'>
<front>
<title>DNS Security Introduction and Requirements</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<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' />
<format type='TXT' octets='52445' target='http://www.rfc-editor.org/rfc/rfc4033.txt' />
</reference>
<?rfc linefile="248:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml"?>
<reference anchor='RFC4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<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></front>
<seriesInfo name='RFC' value='4034' />
<format type='TXT' octets='63879' target='http://www.rfc-editor.org/rfc/rfc4034.txt' />
</reference>
<?rfc linefile="249:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml"?>
<reference anchor='RFC4035'>
<front>
<title>Protocol Modifications for the DNS Security Extensions</title>
<author initials='R.' surname='Arends' fullname='R. Arends'>
<organization /></author>
<author initials='R.' surname='Austein' fullname='R. Austein'>
<organization /></author>
<author initials='M.' surname='Larson' fullname='M. Larson'>
<organization /></author>
<author initials='D.' surname='Massey' fullname='D. Massey'>
<organization /></author>
<author initials='S.' surname='Rose' fullname='S. Rose'>
<organization /></author>
<date year='2005' month='March' />
<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 new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</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='4035' />
<format type='TXT' octets='130589' target='http://www.rfc-editor.org/rfc/rfc4035.txt' />
</reference>
<?rfc linefile="250:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4641.xml"?>
<reference anchor='RFC4641'>
<front>
<title>DNSSEC Operational Practices</title>
<author initials='O.' surname='Kolkman' fullname='O. Kolkman'>
<organization /></author>
<author initials='R.' surname='Gieben' fullname='R. Gieben'>
<organization /></author>
<date year='2006' month='September' />
<abstract>
<t>This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.</t><t> The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.</t><t> This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4641' />
<format type='TXT' octets='79894' target='http://www.rfc-editor.org/rfc/rfc4641.txt' />
</reference>
<?rfc linefile="251:draft-icann-dnssec-trust-anchor.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.xml"?>
<reference anchor='RFC4880'>
<front>
<title>OpenPGP Message Format</title>
<author initials='J.' surname='Callas' fullname='J. Callas'>
<organization /></author>
<author initials='L.' surname='Donnerhacke' fullname='L. Donnerhacke'>
<organization /></author>
<author initials='H.' surname='Finney' fullname='H. Finney'>
<organization /></author>
<author initials='D.' surname='Shaw' fullname='D. Shaw'>
<organization /></author>
<author initials='R.' surname='Thayer' fullname='R. Thayer'>
<organization /></author>
<date year='2007' month='November' />
<abstract>
<t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t><t> OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4880' />
<format type='TXT' octets='203706' target='http://www.rfc-editor.org/rfc/rfc4880.txt' />
</reference>
<?rfc linefile="252:draft-icann-dnssec-trust-anchor.xml"?>
</references>
<references title="Informative References">
<reference anchor="DPS">
<?rfc linefile="1:../dps/icann-dps.front"?><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 abbrev="Kirei">Kirei AB</organization>
<address>
<postal>
<street>P.O. Box 53204</street>
<city>Goteborg</city>
<code>SE-400 16</code>
<country>Sweden</country>
</postal>
<email>fredrik@kirei.se</email>
</address>
</author>
<author fullname="Tomofumi Okubo" initials="T." surname="Okubo">
<organization abbrev="VeriSign">VeriSign Inc.</organization>
<address>
<postal>
<street>21345 Ridgetop Circle</street>
<city>Dulles</city>
<region>VA</region>
<code>20166-6503</code>
<country>USA</country>
</postal>
<email>tookubo@verisign.com</email>
</address>
</author>
<author fullname="Richard Lamb" initials="R." surname="Lamb">
<organization abbrev="ICANN">Internet Corporation For Assigned Names and
Numbers</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Ray</city>
<region>CA</region>
<code>90292</code>
<country>USA</country>
</postal>
<email>richard.lamb@icann.org</email>
</address>
</author>
<author fullname="Jakob Schlyter" initials="J." surname="Schlyter">
<organization abbrev="Kirei">Kirei AB</organization>
<address>
<postal>
<street>P.O. Box 53204</street>
<city>Goteborg</city>
<code>SE-400 16</code>
<country>Sweden</country>
</postal>
<email>jakob@kirei.se</email>
</address>
</author>
<date day="21" month="May" year="2010" />
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<abstract>
<t>This document is the DNSSEC Practice Statement (DPS) for the Root
Zone Key Signing Key (KSK) Operator. It states the practices and
provisions that are used to provide Root Zone Key Signing and Key
Distribution services. These include, but are not limited to: issuing,
managing, changing and distributing DNS keys in accordance with the
specific requirements of the U.S. Department of Commerce.</t>
</abstract>
<note title="Copyright Notice">
<t>Copyright 2009 by VeriSign, Inc., and by Internet Corporation For
Assigned Names and Numbers. This work is based on the Certification
Practice Statement, Copyright 1996-2004 by VeriSign, Inc. Used by
Permission. All Rights Reserved.</t>
</note>
<note title="Trademark Notices">
<t>ICANN is a registered trademark of The Internet Corporation for
Assigned Names and Numbers.</t>
<t>VERISIGN is a registered trademark of VeriSign, Inc.</t>
</note>
</front>
<?rfc linefile="257:draft-icann-dnssec-trust-anchor.xml"?>
<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>
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 }
}
</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>
<?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>
</KeyDigest>
</TrustAnchor>
</artwork>
</figure>
</section>
<section anchor="asn1-rr" title="ASN.1 for Delegation Signer Extension">
<figure>
<artwork>
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
}
</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>
<t>This document, once published in the RFC series, is
intended to provide a stable reference for DNS implementors
and future document authors, and a clear specification that
will aid effective and secure dissemination of DNSSEC trust
anchors to the operators of DNSSEC validators.</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>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:36:08 |