idnits 2.17.1
draft-jabley-dnssec-trust-anchor-14.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 23, 2016) is 2887 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Abley
3 Internet-Draft Dyn, Inc.
4 Intended status: Informational J. Schlyter
5 Expires: November 24, 2016 Kirei AB
6 G. Bailey
7 Independent
8 P. Hoffman
9 ICANN
10 May 23, 2016
12 DNSSEC Trust Anchor Publication for the Root Zone
13 draft-jabley-dnssec-trust-anchor-14
15 Abstract
17 The root zone of the Domain Name System (DNS) has been
18 cryptographically signed using DNS Security Extensions (DNSSEC).
20 In order to obtain secure answers from the root zone of the DNS using
21 DNSSEC, a client must configure a suitable trust anchor. This
22 document describes the format and publication mechanisms IANA has
23 used to distribute the DNSSEC trust anchors.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on November 24, 2016.
42 Copyright Notice
44 Copyright (c) 2016 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4
62 2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4
63 2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 4
64 2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5
65 2.1.3. Converting from XML to DS Records . . . . . . . . . . 6
66 2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 7
67 2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8
68 2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9
69 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9
70 3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9
71 4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10
72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
76 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
77 8.2. Informative References . . . . . . . . . . . . . . . . . 13
78 Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 13
79 Appendix B. About this Document . . . . . . . . . . . . . . . . 13
80 B.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
83 1. Introduction
85 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
86 Security extensions to the DNS (DNSSEC) are described in [RFC4033],
87 [RFC4034], [RFC4035], [RFC4509], [RFC5155] and [RFC5702].
89 A discussion of operational practices relating to DNSSEC can be found
90 in [RFC6781].
92 In the DNSSEC protocol, resource record sets (RRSets) are signed
93 cryptographically. This means that a response to a query contains
94 signatures that allow the integrity and authenticity of the RRSet to
95 be verified. DNSSEC signatures are validated by following a chain of
96 signatures to a "trust anchor". The reason for trusting a trust
97 anchor is outside the DNSSEC protocol, but having one or more trust
98 anchors is required for the DNSSEC protocol to work.
100 The publication of trust anchors for the root zone of the DNS is an
101 IANA function performed by ICANN. A detailed description of
102 corresponding key management practices can be found in [DPS], which
103 can be retrieved from the IANA Repository at .
106 This document describes the formats and distribution methods of
107 DNSSEC trust anchors that have been used by IANA for the root zone of
108 the DNS since 2010. Other organizations might have different formats
109 and mechansims for distributing DNSSEC trust anchors for the root
110 zone; however, most operators and software vendors have chosen to
111 rely on the IANA trust anchors.
113 IMPORTANT NOTE: at the time of this writing, IANA intends to change
114 the formats and distribution methods in the future. If such a change
115 happens, IANA will publish the changes on its web site at
116 .
118 The formats and distribution methods described in this document are a
119 complement to, not a substitute for, the automated DNSSEC trust
120 anchor update protocol described in [RFC5011]. That protocol allows
121 for secure in-band succession of trust anchors when trust has already
122 been established. This document describes one way to establish an
123 initial trust anchor that can be used by [RFC5011].
125 1.1. Definitions
127 The term "trust anchor" is used in many different contexts in the
128 security community. Many of the common definitions conflict because
129 they are specific to a specific system, such as just for DNSSEC or
130 just for S/MIME messages.
132 In cryptographic systems with hierarchical structure, a trust anchor
133 is an authoritative entity for which trust is assumed and not
134 derived. The format of the entity differs in different systems, but
135 the basic idea, that trust is assumed and not derived, is common to
136 all the common uses of the term "trust anchor".
138 The root zone trust anchor formats published by IANA are defined in
139 Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY
140 RR or DS RR hash of a DNSKEY RR". Note that the formats defined here
141 do not match the definition of "trust anchor" from [RFC4033];
142 however, a system that wants to convert the trusted material from
143 IANA into a DS RR can do so.
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in [RFC2119].
149 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics
151 IANA publishes trust anchors for the root zone in three formats:
153 o an XML document that contains the hashes of the DNSKEY records
155 o certificates in PKIX format [RFC5280] that contain DS records and
156 the full public key of DNSKEY records
158 o certificate signing requests (CSRs) in PKCS#10 format [RFC2986]
159 that contain DS records and the full public key of DNSKEY records
161 These formats and the semantics associated with each are described in
162 the rest of this section.
164 2.1. Hashes in XML
166 The XML document contains a set of hashes for the DNSKEY records that
167 can be used to validate the root zone. The hashes are consistent
168 with the defined presentation format of Delegation Signer (DS)
169 resource records from [RFC4034].
171 2.1.1. XML Syntax
173 A Relax NG Compact Schema for the documents used to publish trust
174 anchors is given in Figure 1.
176 datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
178 start = element TrustAnchor {
179 attribute id { xsd:string },
180 attribute source { xsd:string },
181 element Zone { xsd:string },
183 keydigest+
184 }
186 keydigest = element KeyDigest {
187 attribute id { xsd:string },
188 attribute validFrom { xsd:dateTime },
189 attribute validUntil { xsd:dateTime }?,
191 element KeyTag {
192 xsd:nonNegativeInteger { maxInclusive = "65535" } },
193 element Algorithm {
194 xsd:nonNegativeInteger { maxInclusive = "255" } },
195 element DigestType {
196 xsd:nonNegativeInteger { maxInclusive = "255" } },
197 element Digest { xsd:hexBinary }
198 }
200 Figure 1
202 2.1.2. XML Semantics
204 The TrustAnchor element is the container for all of the trust anchors
205 in the file.
207 The id attribute in the TrustAnchor element is an opaque string that
208 identifies the set of trust anchors. Its value has no particular
209 semantics. Note that the id element in the TrustAnchor element is
210 different than the id element in the KeyDigest element, described
211 below.
213 The source attribute in the TrustAnchor element gives information
214 about where to obtain the TrustAnchor container. It is likely to be
215 a URL, and is advisory only.
217 The Zone element in the TrustAnchor element states to which DNS zone
218 this container applies. The root zone is indicated by a single
219 period (.) character, without any quotation marks.
221 The TrustAnchor element contains one or more KeyDigest elements.
222 Each KeyDigest element represents the digest of a DNSKEY record in
223 the zone defined in the Zone element.
225 The id attribute in the KeyDigest element is an opaque string that
226 identifies the hash. Its value is used in the file names and URI of
227 the other trust anchor formats. This is described in Section 3.1.
228 For example, if the value of the id attribute in the KeyDigest
229 element is "Kjqmt7v", the URI for the CSR that is associated with
230 this hash will be .
231 Note that the id element in the KeyDigest element is different than
232 the id element in the TrustAnchor element, described above.
234 The validFrom and validUntil attributes in the KeyDigest element
235 specify the range of times that the KeyDigest element can be used as
236 a trust anchor. Note that the KeyDigest element is optional; if it
237 is not given, the trust anchor can be used until a KeyDigest element
238 covering the same DNSKEY record but having a validUntil attribute is
239 trusted by the relying party. Relying parties SHOULD NOT use a
240 KeyDigest outside of the time range given in the validFrom and
241 validUntil attributes.
243 The KeyTag element in the KeyDigest element contains the key tag for
244 the DNSKEY record represented in this KeyDigest.
246 The Algorithm element in the KeyDigest element contains the signing
247 algorithm identifier for the DNSKEY record represented in this
248 KeyDigest.
250 The DigestType element in the KeyDigest element contains the digest
251 algorithm identifier for the DNSKEY record represented in this
252 KeyDigest.
254 The Digest element in the KeyDigest element contains the hexadecimal
255 representation of the hash for the DNSKEY record represented in this
256 KeyDigest.
258 2.1.3. Converting from XML to DS Records
260 The display format for the DS record that is the equivalent of a
261 KeyDigest element can be constructed by marshaling the KeyTag,
262 Algorithm, DigestType, and Digest elements. For example, assume that
263 the TrustAnchor element contains:
265
266
269 .
270
271 19036
272 8
273 2
274
275 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
276
277
278
280 The DS record would be:
282 . IN DS 19036 8 2
283 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
285 2.1.4. XML Example
287 Figure 2 describes two fictitious trust anchors for the root zone.
289
291
294 .
295
298 34291
299 5
300 1
301 c8cb3d7fe518835490af8029c23efbce6b6ef3e2
302
303
305 12345
306 5
307 1
308 a3cf809dbdbc835716ba22bdc370d2efa50f21c7
309
310
312 Figure 2
314 2.2. Certificates
316 Each public key that can be used as a trust anchor is represented as
317 a certificate in PKIX format. Each certificate is signed by the
318 ICANN certificate authority. The SubjectPublicKeyInfo in the
319 certificate represents the public key of the KSK. The Subject field
320 has the following attributes:
322 O: the string "ICANN".
324 OU: the string "IANA".
326 CN: the string "Root Zone KSK" followed by the time and date of key
327 generation in the format specified in [RFC3339]. For example, a
328 CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00".
330 resourceRecord: a string in the presentation format of the
331 Delegation Signer (DS) [RFC4034] resource record for the DNSSEC
332 public key.
334 The "resourceRecord" attribute in the Subject is defined as follows:
336 ResourceRecord
337 { iso(1) identified-organization(3) dod(6) internet(1) security(5)
338 mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }
340 DEFINITIONS IMPLICIT TAGS ::=
342 BEGIN
344 -- EXPORTS ALL --
346 IMPORTS
348 caseIgnoreMatch FROM SelectedAttributeTypes
349 { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }
351 ;
353 iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
354 dod(6) internet(1) private(4) enterprise(1) 1000 }
356 iana-dns OBJECT IDENTIFIER ::= { iana 53 }
358 resourceRecord ATTRIBUTE ::= {
359 WITH SYNTAX IA5String
360 EQUALITY MATCHING RULE caseIgnoreIA5Match
361 ID iana-dns
362 }
364 END
366 2.3. Certificate Signing Requests
368 Each public key that can be used as a trust anchor is represented as
369 a certificate signing request (CSR) in PKCS#10 format. The
370 SubjectPublicKeyInfo and Subject field are the same as for
371 certificates (see Section 2.2 above).
373 3. Root Zone Trust Anchor Retrieval
375 3.1. Retrieving Trust Anchors with HTTPS and HTTP
377 Trust anchors are available for retrieval using HTTPS and HTTP.
379 In this section, all URLs are given using the "https:" scheme. If
380 HTTPS cannot be used, replace the "https:" scheme with "http:".
382 The URL for retrieving the set of hashes described in Section 2.1 is
383 .
385 The URL for retrieving the PKIX certificate described in Section 2.2
386 is , with the
387 string "KEYDIGEST-ID" replaced the "id" attribute from the KeyDigest
388 element from the XML file, as described in Section 2.1.2.
390 The URL for retrieving the CSR described in Section 2.3 is
391 , with the
392 string "KEYDIGEST-ID" replaced the "id" attribute from the KeyDigest
393 element from the XML file, as described in Section 2.1.2.
395 4. Accepting DNSSEC Trust Anchors
397 A validator operator can choose whether or not to accept the trust
398 anchors described in this document using whatever policy they want.
399 In order to help validator operators verify the content and origin of
400 trust anchors they receive, IANA uses digital signatures that chain
401 to an ICANN-controlled CA over the trust anchor data.
403 It is important to note that the ICANN CA is not a DNSSEC trust
404 anchor. Instead, it is an optional mechanism for verifying the
405 content and origin of the XML and certificate trust anchors. It is
406 also important to note that the ICANN CA cannot be used to verify the
407 origin of the trust anchor in the CSR format.
409 The content and origin of the XML file can be verified using a
410 digital signature on the file. IANA provides a detached CMS
411 [RFC5652] that chains to the ICANN CA with the XML file. The URL for
412 a detached CMS signature for the XML file is .
415 Another method IANA uses to help validator operators verify the
416 content and origin of trust anchors they receive is to use the TLS
417 protocol for distributing the trust anchors. Currently, the CA used
418 for data.iana.org is well-known, that is, one that is a WebTrust-
419 accredited Certificate Authority. If a system retrieving the trust
420 anchors trusts the CA that IANA uses for the "data.iana.org" web
421 server, HTTPS SHOULD be used instead of HTTP in order to have
422 assurance of data origin.
424 5. IANA Considerations
426 Key Signing Key (KSK) management for the root zone is an IANA
427 function. This document describes an initial set of publication
428 mechanisms for trust anchors related to that management. In the
429 future, additional publication schemes may also be made available, in
430 which case they will be described in a new document that updates this
431 one.
433 Section 2.2 serves as the reference for id-mod-dns-resource-record,
434 value 70, in the SMI Security for PKIX Module Identifier registry.
436 6. Security Considerations
438 This document describes how DNSSEC trust anchors for the root zone of
439 the DNS are published. Many DNSSEC clients will only configure IANA-
440 issued trust anchors for the DNS root to perform validation. As a
441 consequence, reliable publication of trust anchors is important.
443 This document aims to specify carefully the means by which such trust
444 anchors are published, as an aid to the formats and retrieval methods
445 described here being integrated usefully into user environments.
447 7. Acknowledgements
449 Many pioneers paved the way for the deployment of DNSSEC in the root
450 zone of the DNS, and the authors hereby acknowledge their substantial
451 collective contribution.
453 This document incorporates suggestions made by Alfred Hoenes, whose
454 contributions are appreciated.
456 8. References
458 8.1. Normative References
460 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
461 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
462 .
464 [RFC1035] Mockapetris, P., "Domain names - implementation and
465 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
466 November 1987, .
468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
469 Requirement Levels", BCP 14, RFC 2119,
470 DOI 10.17487/RFC2119, March 1997,
471 .
473 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
474 Request Syntax Specification Version 1.7", RFC 2986,
475 DOI 10.17487/RFC2986, November 2000,
476 .
478 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
479 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
480 .
482 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
483 Rose, "DNS Security Introduction and Requirements",
484 RFC 4033, DOI 10.17487/RFC4033, March 2005,
485 .
487 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
488 Rose, "Resource Records for the DNS Security Extensions",
489 RFC 4034, DOI 10.17487/RFC4034, March 2005,
490 .
492 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
493 Rose, "Protocol Modifications for the DNS Security
494 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
495 .
497 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
498 (DS) Resource Records (RRs)", RFC 4509,
499 DOI 10.17487/RFC4509, May 2006,
500 .
502 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
503 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
504 September 2007, .
506 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
507 Security (DNSSEC) Hashed Authenticated Denial of
508 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
509 .
511 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
512 Housley, R., and W. Polk, "Internet X.509 Public Key
513 Infrastructure Certificate and Certificate Revocation List
514 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
515 .
517 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
518 RFC 5652, DOI 10.17487/RFC5652, September 2009,
519 .
521 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
522 and RRSIG Resource Records for DNSSEC", RFC 5702,
523 DOI 10.17487/RFC5702, October 2009,
524 .
526 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
527 Operational Practices, Version 2", RFC 6781,
528 DOI 10.17487/RFC6781, December 2012,
529 .
531 8.2. Informative References
533 [DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter,
534 "DNSSEC Practice Statement for the Root Zone KSK
535 Operator", October 2010, .
538 Appendix A. Historical Note
540 The first KSK for use in the root zone of the DNS was generated at a
541 key ceremony at an ICANN Key Management Facility (KMF) in Culpeper,
542 Virginia, USA on 2010-06-16. This key entered production during a
543 second key ceremony held at an ICANN KMF in El Segundo, California,
544 USA on 2010-07-12. The resulting trust anchor was first published on
545 2010-07-15.
547 Appendix B. About this Document
549 [RFC Editor: please remove this section, including all subsections,
550 prior to publication.]
552 B.1. Discussion
554 This document is not the product of any IETF working group. However,
555 communities interested in similar technical work can be found at the
556 IETF in the DNSOP and DNSEXT working groups.
558 The team responsible for deployment of DNSSEC in the root zone can be
559 reached at rootsign@icann.org.
561 The authors also welcome feedback sent to them directly.
563 Authors' Addresses
565 Joe Abley
566 Dyn, Inc.
567 470 Moore Street
568 London, ON N6C 2C2
569 Canada
571 Phone: +1 519 670 9327
572 Email: jabley@dyn.com
573 Jakob Schlyter
574 Kirei AB
576 Email: jakob@kirei.se
578 Guillaume Bailey
579 Independent
581 Email: GuillaumeBailey@outlook.com
583 Paul Hoffman
584 ICANN
586 Email: paul.hoffman@icann.org