]> ICANN

4676 Admiralty Way, Suite 330 Marina del Rey CA 90292 US +1 519 670 9327 joe.abley@icann.org

Kirei AB

P.O. Box 53204 Goteborg SE-400 16 Sweden jakob@kirei.se

The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). 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.

The Domain Name System (DNS) is described in and . Security extensions to the DNS (DNSSEC) are described in , , , , and . A discussion of operational practices relating to DNSSEC can be found in . In DNSSEC resource record sets (RRSets) are cryptographically-signed, such that a response to a query contains signatures which allow its integrity and authenticity to be verified. An individual signature is validated by following a chain of signatures to a key which is trusted for some extra-protocol reason. 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 , which can be retrieved from the IANA Repository located at . 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.

Trust anchors for the root zone are published in two formats, each of which is described in this document: as the hashes of the corresponding DNSKEY records, consistent with the defined presentation format of Delegation Signer (DS) resource records , contained within an XML document, as described in , and as Certificate Signing Requests (CSRs) in PKCS#10 format for further processing by Certification Authorities and validation of proof of possession of the corresponding private keys, as described in .

Trust anchors are published in an XML document whose schema is described in . 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 Uniform Resource Locators (URLs) for retrieving corresponding X.509 certificates. Examples of trust anchors packaged and signed for publication can be found in .

To facilitate signing the trust anchor by a public key infrastructure, trust anchors are also published as Certificate Signing Requests (CSRs) in PKCS#10 format. Each CSR will have a Subject with following attributes: the string "ICANN". the string "IANA". the string "Root Zone KSK" followed by the time and date of key generation in the format specified in , e.g. "Root Zone KSK 2010-06-16T21:19:24+00:00". the hash of the public key consistent with the presentation format of the Delegation Signer (DS) resource record (see for attribute definition).

Trust anchors are available for retrieval using HTTP . 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. 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. The URL for retrieving the complete trust anchor set is . The URL for a detached S/MIME signature for the current trust anchor set is . The URL for a detached OpenPGP signature for the current trust anchor set is .

Trust anchors are available for retrieval using HTTP over TLS . The URLs specified in are also available using HTTPS. That is: 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. 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. The URL for retrieving the complete trust anchor set is . The URL for a detached S/MIME signature for the current trust anchor set is . The URL for a detached OpenPGP signature for the current trust anchor set is . 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.

The OpenPGP 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. An OpenPGP keyring containing public keys pertinent to signature verification is published at . The public keys on that keyring will also be distributed widely, e.g. to public PGP key servers. 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.

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 that updates this one. Existing mechanisms will not be deprecated without very strong technical justification. This document contains information about an existing service, and has no IANA actions.

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. 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.

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. This document incorporates suggestions made by Paul Hoffman and Alfred Hoenes, whose contributions are appreciated.

Information Sciences Institute (ISI) USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Department of Information and Computer Science

University of California, Irvine Irvine CA 92697-3425 +1(949)824-1715 fielding@ics.uci.edu

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 jg@w3.org

Compaq Computer Corporation

Western Research Laboratory 250 University Avenue Palo Alto CA 94305 mogul@wrl.dec.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 frystyk@w3.org

Xerox Corporation

MIT Laboratory for Computer Science, NE43-356 3333 Coyote Hill Road Palo Alto CA 94034 masinter@parc.xerox.com

Microsoft Corporation

1 Microsoft Way Redmond WA 98052 paulle@microsoft.com

World Wide Web Consortium

MIT Laboratory for Computer Science, NE43-356 545 Technology Square Cambridge MA 02139 +1(617)258-8682 timbl@w3.org

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. 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 . 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. 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. Clearswift Corporation

1310 Waterside Arlington Business Park Theale Reading RG7 4SA UK +44 11 8903 8903 +44 11 8903 9000 GK@ACM.ORG

Sun Microsystems

1050 Lakes Drive, Suite 250 West Covina CA 91790 USA chris.newman@sun.com

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. 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] 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] 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] This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK] 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. 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] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK] This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK] Kirei AB

P.O. Box 53204 Goteborg SE-400 16 Sweden fredrik@kirei.se

VeriSign Inc.

21345 Ridgetop Circle Dulles VA 20166-6503 USA tookubo@verisign.com

Internet Corporation For Assigned Names and Numbers

4676 Admiralty Way, Suite 330 Marina del Ray CA 90292 USA richard.lamb@icann.org

Kirei AB

P.O. Box 53204 Goteborg SE-400 16 Sweden jakob@kirei.se

DNS DNSSEC 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. 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. ICANN is a registered trademark of The Internet Corporation for Assigned Names and Numbers. VERISIGN is a registered trademark of VeriSign, Inc.

A Relax NG Compact Schema for the documents used to publish trust anchors can be found in .

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 }+ }

describes two trust anchors for the root zone such as might be retrieved using the URL .

<?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>

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

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.

[RFC Editor: please remove this section, including all subsections, prior to publication.]

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. The team responsible for deployment of DNSSEC in the root zone can be reached at rootsign@icann.org. The authors also welcome feedback sent to them directly.

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.

Incorporated initial community suggestions. Editorial improvements. Allocate OID and clean up syntax of ASN.1 module.

Draft expired.

Added the optional <Certificate> element to the XML schema to provide a mechanism for locating external X.509 certificates relating to a particular key.