TOC |
|
ICANN, as IANA Functions Operator, is responsible for the publication of trust anchors for the root zone of the Domain Name System.
This document outlines the strategy by which those trust anchors are published, and specifies initial mechanisms to be implemented in conjunction with the initial signing of the root zone.
Copyright (c) 2010 Internet Corporation For Assigned Names and Numbers.
1.
Introduction
2.
Trust Anchor Publication Strategy
3.
Trust Anchor Set Format
3.1.
XML
3.2.
Certificate Signing Request (PKCS#10)
4.
Initial Publication Mechanisms
4.1.
HTTP
4.2.
HTTP Over TLS
5.
Signature Verification
6.
References
Appendix A.
Trust Anchor Publication Document Schema
Appendix B.
Example Signed Trust Anchor Set
Appendix C.
ASN.1 for Delegation Signer Extension
§
Authors' Addresses
TOC |
The Domain Name System (DNS) is described in [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) and [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). Security extensions to the DNS (DNSSEC) are described in [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) and [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.).
A discussion of operational practices relating to DNSSEC can be found in [RFC4641] (Kolkman, O. and R. Gieben, “DNSSEC Operational Practices,” September 2006.).
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.
ICANN, as IANA Functions Operator, is responsible for the publication of trust anchors for the root zone of the Domain Name System.
This document outlines the strategy by which those trust anchors are published, and specifies initial mechanisms to be implemented in conjunction with the initial signing of the root zone.
TOC |
Each trust anchor will be published in two formats:
Operational procedures for KSK generation will include the generation of a trust anchor and providing proof of possession of the corresponding private key. Those operational procedures, including the specification of the signing mechanism are documented in [ICANNDPS] (Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, “DNSSEC Practice Statement for the Root Zone KSK Operator (DRAFT),” May 2010.). The execution of those procedures are be subject to third-party audit.
Paper-copy representations of trust anchors will be distributed to Key Generation Ceremony participants when the corresponding keys are generated. These participants may attest to the generated key in any way they find suitable.
Trust anchor sets and short-hand representations thereof will be distributed among the Key Generation Ceremony participants. These participants may attest to the generated key in any way they find suitable.
In addition, the Trust Anchor set will be transported to the ICANN Trust Anchor signing infrastructure (separate from the DNSSEC signing infrastructure) in a secure manner, to preclude substitution attacks. These signed Trust Anchor sets will then be published with these signatures along with the original Certificate Signing Request.
This document specifies an initial set of publication mechanisms in Section 4 (Initial Publication Mechanisms). It is anticipated that additional mechanisms may be added in the future.
TOC |
TOC |
Trust anchors are published in XML documents whose schema is described in Appendix A (Trust Anchor Publication Document Schema). Each document contains a complete set of trust anchors for the root zone, including anchors suitable for immediate use and also historical data.
Examples of trust anchors packaged and signed for publication can be found in Appendix B (Example Signed Trust Anchor Set).
TOC |
To facilitate signing the trust anchor by a public key infrastructure, the trust anchor is also published as a Certificate Signing Request (CSR) in PKCS#10 format (Nystrom, M. and B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7,” November 2000.) [RFC2986].
The CSR will have a Subject with following attributes:
- O:
- the string "ICANN".
- OU:
- the string "IANA".
- CN:
- the string "Root Zone KSK" combined with the timestamp (in ISO 8601 format) when the key was generated, e.g. "Root Zone KSK 2009-10-10T01:08:42Z".
- resourceRecord:
- the delegation signer (DS) resource record of the public key (see Appendix C (ASN.1 for Delegation Signer Extension) for attribute definition).
TOC |
TOC |
Signed key sets will be made available by HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.).
The URL for retrieving the CSR is http://data.iana.org/root-anchors/<key-label>.csr.
The URL for retrieving the ICANN signed Certificate is http://data.iana.org/root-anchors/<key-label>.crt.
The URL for retrieving the complete trust anchor set is http://data.iana.org/root-anchors/root-anchors.xml.
The URL for a detached S/MIME signature for the current trust anchor set is http://data.iana.org/root-anchors/root-anchors.p7s.
The URL for a detached OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) signature for the current trust anchor set is http://data.iana.org/root-anchors/root-anchors.asc.
TOC |
Signed key sets will be made available by HTTP over TLS [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.).
The URLs specified in Section 4.1 (HTTP) are also available using HTTPS. That is:
The URL for retrieving the CSR is https://data.iana.org/root-anchors/<key-label>.csr.
The URL for retrieving the ICANN signed Certificate is https://data.iana.org/root-anchors/<key-label>.crt.
The URL for retrieving the complete trust anchor set is https://data.iana.org/root-anchors/root-anchors.xml.
The URL for a detached S/MIME signature for the complete trust anchor set is https://data.iana.org/root-anchors/root-anchors.p7s.
The URL for a detached OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) signature for the current trust anchor set is https://data.iana.org/root-anchors/root-anchors.asc.
TOC |
The OpenPGP [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) keys used to sign trust anchor documents will themselves carry signatures from personal keys of ICANN operations staff who are able to personally attest to their validity. Those staff members will endeavour 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 will be published at 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.
Certificates used to create S/MIME signatures will be signed by ICANN and well-known (WebTrust-certified) Certificate Authorities at their discretion, to facilitate signature validation with widely-available X.509 trust anchors.
TOC |
[I-D.ietf-dnsop-dnssec-trust-anchor] | Larson, M. and O. Gudmundsson, “DNSSEC Trust Anchor Configuration and Maintenance,” draft-ietf-dnsop-dnssec-trust-anchor-03 (work in progress), March 2009 (TXT). |
[ICANNDPS] | Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, “DNSSEC Practice Statement for the Root Zone KSK Operator (DRAFT),” May 2010. |
[RFC1034] | Mockapetris, P., “Domain names - concepts and facilities,” STD 13, RFC 1034, November 1987 (TXT). |
[RFC1035] | Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987 (TXT). |
[RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML). |
[RFC2818] | Rescorla, E., “HTTP Over TLS,” RFC 2818, May 2000 (TXT). |
[RFC2986] | Nystrom, M. and B. Kaliski, “PKCS #10: Certification Request Syntax Specification Version 1.7,” RFC 2986, November 2000 (TXT). |
[RFC4033] | Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT). |
[RFC4034] | Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT). |
[RFC4035] | Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005 (TXT). |
[RFC4641] | Kolkman, O. and R. Gieben, “DNSSEC Operational Practices,” RFC 4641, September 2006 (TXT). |
[RFC4880] | Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” RFC 4880, November 2007 (TXT). |
TOC |
A Relax NG Compact Schema for the documents used to publish trust anchors can be found in Figure 1.
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 } }
Figure 1 |
TOC |
Figure 2 describes two trust anchors for the root zone such as might be retrieved using the URL https://data.iana.org/root-anchors/root-anchors.xml.
<?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="2011-07-01T00:00:00-00:00"> <KeyTag>34291</KeyTag> <Algorithm>5</Algorithm> <DigestType>1</DigestType> <Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest> </KeyDigest> </TrustAnchor>
Figure 2 |
TOC |
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 }
TOC |
Joe Abley | |
ICANN | |
4676 Admiralty Way, Suite 330 | |
Marina del Rey, CA 90292 | |
US | |
Phone: | +1 519 670 9327 |
Email: | joe.abley@icann.org |
Jakob Schlyter | |
Kirei AB | |
P.O. Box 53204 | |
Goteborg SE-400 16 | |
Sweden | |
Email: | jakob@kirei.se |