1 Independent Submission J. Abley
2 Request for Comments: 7958 Dyn, Inc.
3 Category: Informational J. Schlyter
4 ISSN: 2070-1721 Kirei AB
5 G. Bailey
6 Independent
7 P. Hoffman
8 ICANN
9 August 2016
10
11
12 DNSSEC Trust Anchor Publication for the Root Zone
13
14 Abstract
15
16 The root zone of the Domain Name System (DNS) has been
17 cryptographically signed using DNS Security Extensions (DNSSEC).
18
19 In order to obtain secure answers from the root zone of the DNS using
20 DNSSEC, a client must configure a suitable trust anchor. This
21 document describes the format and publication mechanisms IANA has
22 used to distribute the DNSSEC trust anchors.
23
24 Status of This Memo
25
26 This document is not an Internet Standards Track specification; it is
27 published for informational purposes.
28
29 This is a contribution to the RFC Series, independently of any other
30 RFC stream. The RFC Editor has chosen to publish this document at
31 its discretion and makes no statement about its value for
32 implementation or deployment. Documents approved for publication by
33 the RFC Editor are not a candidate for any level of Internet
34 Standard; see Section 2 of RFC 7841.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc7958.
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Abley, et al. Informational [Page 1]
53 RFC 7958 Root Zone Trust Anchor Publication August 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document.
67
68 Table of Contents
69
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
71 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
72 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics . . 4
73 2.1. Hashes in XML . . . . . . . . . . . . . . . . . . . . . . 4
74 2.1.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . 5
75 2.1.2. XML Semantics . . . . . . . . . . . . . . . . . . . . 5
76 2.1.3. Converting from XML to DS Records . . . . . . . . . . 7
77 2.1.4. XML Example . . . . . . . . . . . . . . . . . . . . . 8
78 2.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 8
79 2.3. Certificate Signing Requests . . . . . . . . . . . . . . 9
80 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 9
81 3.1. Retrieving Trust Anchors with HTTPS and HTTP . . . . . . 9
82 4. Accepting DNSSEC Trust Anchors . . . . . . . . . . . . . . . 10
83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
86 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
87 7.2. Informative References . . . . . . . . . . . . . . . . . 13
88 Appendix A. Historical Note . . . . . . . . . . . . . . . . . . 14
89 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Abley, et al. Informational [Page 2]
108 RFC 7958 Root Zone Trust Anchor Publication August 2016
109
110
111 1. Introduction
112
113 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
114 DNS Security Extensions (DNSSEC) are described in [RFC4033],
115 [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702].
116
117 A discussion of operational practices relating to DNSSEC can be found
118 in [RFC6781].
119
120 In the DNSSEC protocol, Resource Record Sets (RRSets) are signed
121 cryptographically. This means that a response to a query contains
122 signatures that allow the integrity and authenticity of the RRSet to
123 be verified. DNSSEC signatures are validated by following a chain of
124 signatures to a "trust anchor". The reason for trusting a trust
125 anchor is outside the DNSSEC protocol, but having one or more trust
126 anchors is required for the DNSSEC protocol to work.
127
128 The publication of trust anchors for the root zone of the DNS is an
129 IANA function performed by ICANN. A detailed description of
130 corresponding key management practices can be found in [DPS], which
131 can be retrieved from the IANA Repository at
132 <https://www.iana.org/dnssec/>.
133
134 This document describes the formats and distribution methods of
135 DNSSEC trust anchors that have been used by IANA for the root zone of
136 the DNS since 2010. Other organizations might have different formats
137 and mechanisms for distributing DNSSEC trust anchors for the root
138 zone; however, most operators and software vendors have chosen to
139 rely on the IANA trust anchors.
140
141 It is important to note that at the time of this writing, IANA
142 intends to change the formats and distribution methods in the future.
143 If such a change happens, IANA will publish the changes on its web
144 site at <https://www.iana.org/dnssec/files>.
145
146 The formats and distribution methods described in this document are a
147 complement to, not a substitute for, the automated DNSSEC trust
148 anchor update protocol described in [RFC5011]. That protocol allows
149 for secure in-band succession of trust anchors when trust has already
150 been established. This document describes one way to establish an
151 initial trust anchor that can be used by [RFC5011].
152
153
154
155
156
157
158
159
160
161
162 Abley, et al. Informational [Page 3]
163 RFC 7958 Root Zone Trust Anchor Publication August 2016
164
165
166 1.1. Definitions
167
168 The term "trust anchor" is used in many different contexts in the
169 security community. Many of the common definitions conflict because
170 they are specific to a specific system, such as just for DNSSEC or
171 just for S/MIME messages.
172
173 In cryptographic systems with hierarchical structure, a trust anchor
174 is an authoritative entity for which trust is assumed and not
175 derived. The format of the entity differs in different systems, but
176 the basic idea, that trust is assumed and not derived, is common to
177 all the common uses of the term "trust anchor".
178
179 The root zone trust anchor formats published by IANA are defined in
180 Section 2. [RFC4033] defines a trust anchor as "A configured DNSKEY
181 RR or DS RR hash of a DNSKEY RR". Note that the formats defined here
182 do not match the definition of "trust anchor" from [RFC4033];
183 however, a system that wants to convert the trusted material from
184 IANA into a Delegation Signer (DS) RR can do so.
185
186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
188 document are to be interpreted as described in [RFC2119].
189
190 2. IANA DNSSEC Root Zone Trust Anchor Formats and Semantics
191
192 IANA publishes trust anchors for the root zone in three formats:
193
194 o an XML document that contains the hashes of the DNSKEY records
195
196 o certificates in PKIX format [RFC5280] that contain DS records and
197 the full public key of DNSKEY records
198
199 o Certificate Signing Requests (CSRs) in PKCS #10 format [RFC2986]
200 that contain DS records and the full public key of DNSKEY records
201
202 These formats and the semantics associated with each are described in
203 the rest of this section.
204
205 2.1. Hashes in XML
206
207 The XML document contains a set of hashes for the DNSKEY records that
208 can be used to validate the root zone. The hashes are consistent
209 with the defined presentation format of DS resource records from
210 [RFC4034].
211
212
213
214
215
216
217 Abley, et al. Informational [Page 4]
218 RFC 7958 Root Zone Trust Anchor Publication August 2016
219
220
221 2.1.1. XML Syntax
222
223 A RELAX NG Compact Schema [RELAX-NG] for the documents used to
224 publish trust anchors is given in Figure 1.
225
226 datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"
227
228 start = element TrustAnchor {
229 attribute id { xsd:string },
230 attribute source { xsd:string },
231 element Zone { xsd:string },
232
233 keydigest+
234 }
235
236 keydigest = element KeyDigest {
237 attribute id { xsd:string },
238 attribute validFrom { xsd:dateTime },
239 attribute validUntil { xsd:dateTime }?,
240
241 element KeyTag {
242 xsd:nonNegativeInteger { maxInclusive = "65535" } },
243 element Algorithm {
244 xsd:nonNegativeInteger { maxInclusive = "255" } },
245 element DigestType {
246 xsd:nonNegativeInteger { maxInclusive = "255" } },
247 element Digest { xsd:hexBinary }
248 }
249
250 Figure 1
251
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
252 2.1.2. XML Semantics
253
254 The TrustAnchor element is the container for all of the trust anchors
255 in the file.
256
257 The id attribute in the TrustAnchor element is an opaque string that
258 identifies the set of trust anchors. Its value has no particular
259 semantics. Note that the id element in the TrustAnchor element is
260 different than the id element in the KeyDigest element, described
261 below.
262
263 The source attribute in the TrustAnchor element gives information
264 about where to obtain the TrustAnchor container. It is likely to be
265 a URL and is advisory only.
266
267
268
269
270
271
272 Abley, et al. Informational [Page 5]
273 RFC 7958 Root Zone Trust Anchor Publication August 2016
274
275
276 The Zone element in the TrustAnchor element states to which DNS zone
277 this container applies. The root zone is indicated by a single
278 period (.) character without any quotation marks.
279
280 The TrustAnchor element contains one or more KeyDigest elements.
281 Each KeyDigest element represents the digest of a DNSKEY record in
282 the zone defined in the Zone element.
283
284 The id attribute in the KeyDigest element is an opaque string that
285 identifies the hash. Its value is used in the file names and URI of
286 the other trust anchor formats. This is described in Section 3.1.
287 For example, if the value of the id attribute in the KeyDigest
288 element is "Kjqmt7v", the URI for the CSR that is associated with
289 this hash will be <https://data.iana.org/root-anchors/Kjqmt7v.csr>.
290 Note that the id element in the KeyDigest element is different than
291 the id element in the TrustAnchor element described above.
292
293 The validFrom and validUntil attributes in the KeyDigest element
294 specify the range of times that the KeyDigest element can be used as
The validFrom and validUntil attributes in the KeyDigest element specify the range of times that the KeyDigest element can be used as a trust anchor. Note that the KeyDigest element is optional; if it is not given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party. Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.
The validFrom and validUntil attributes in the KeyDigest element specify the range of times that the KeyDigest element can be used as a trust anchor. Note that the validUntil element is optional; if it is not given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party. Relying parties SHOULD NOT use a KeyDigest outside of the time range given in the validFrom and validUntil attributes.
The text after the ';' is difficult to read. I am not sure what is should say. --VERIFIER NOTES-- The text does take a little effort to parse, but is correct as written. It says validUntil is optional: IF validUntil not given DO FOREVER use trust anchor IF ( (NewKeyDigest covers same DNSKEY record) && (NewKeyDigest has a validUntil) && (NewKeyDigest is trusted by relying party) ) exit ENDIF ENDDO
295 a trust anchor. Note that the KeyDigest element is optional; if it
296 is not given, the trust anchor can be used until a KeyDigest element
297 covering the same DNSKEY record, but having a validUntil attribute,
298 is trusted by the relying party. Relying parties SHOULD NOT use a
299 KeyDigest outside of the time range given in the validFrom and
300 validUntil attributes.
301
302 The KeyTag element in the KeyDigest element contains the key tag for
303 the DNSKEY record represented in this KeyDigest.
304
305 The Algorithm element in the KeyDigest element contains the signing
306 algorithm identifier for the DNSKEY record represented in this
307 KeyDigest.
308
309 The DigestType element in the KeyDigest element contains the digest
310 algorithm identifier for the DNSKEY record represented in this
311 KeyDigest.
312
313 The Digest element in the KeyDigest element contains the hexadecimal
314 representation of the hash for the DNSKEY record represented in this
315 KeyDigest.
316
317
318
319
320
321
322
323
324
325
326
327 Abley, et al. Informational [Page 6]
328 RFC 7958 Root Zone Trust Anchor Publication August 2016
329
330
331 2.1.3. Converting from XML to DS Records
332
333 The display format for the DS record that is the equivalent of a
334 KeyDigest element can be constructed by marshaling the KeyTag,
335 Algorithm, DigestType, and Digest elements. For example, assume that
336 the TrustAnchor element contains:
337
338 <?xml version="1.0" encoding="UTF-8"?>
339 <TrustAnchor
340 id="AD42165F-3B1A-4778-8F42-D34A1D41FD93"
341 source="http://data.iana.org/root-anchors/root-anchors.xml">
342 <Zone>.</Zone>
343 <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00">
344 <KeyTag>19036</KeyTag>
345 <Algorithm>8</Algorithm>
346 <DigestType>2</DigestType>
347 <Digest>
348 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
349 </Digest>
350 </KeyDigest>
351 </TrustAnchor>
352
353 The DS record would be:
354
355 . IN DS 19036 8 2
356 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Abley, et al. Informational [Page 7]
383 RFC 7958 Root Zone Trust Anchor Publication August 2016
384
385
386 2.1.4. XML Example
387
388 Figure 2 describes two fictitious trust anchors for the root zone.
389
390 <?xml version="1.0" encoding="UTF-8"?>
391
392 <TrustAnchor
393 id="AD42165F-B099-4778-8F42-D34A1D41FD93"
394 source="http://data.iana.org/root-anchors/root-anchors.xml">
395 <Zone>.</Zone>
396 <KeyDigest id="42"
397 validFrom="2010-07-01T00:00:00-00:00"
398 validUntil="2010-08-01T00:00:00-00:00">
399 <KeyTag>34291</KeyTag>
400 <Algorithm>5</Algorithm>
401 <DigestType>1</DigestType>
402 <Digest>c8cb3d7fe518835490af8029c23efbce6b6ef3e2</Digest>
403 </KeyDigest>
404 <KeyDigest id="53"
405 validFrom="2010-08-01T00:00:00-00:00">
406 <KeyTag>12345</KeyTag>
407 <Algorithm>5</Algorithm>
408 <DigestType>1</DigestType>
409 <Digest>a3cf809dbdbc835716ba22bdc370d2efa50f21c7</Digest>
410 </KeyDigest>
411 </TrustAnchor>
412
413 Figure 2
414
415 2.2. Certificates
416
417 Each public key that can be used as a trust anchor is represented as
418 a certificate in PKIX format. Each certificate is signed by the
419 ICANN certificate authority. The SubjectPublicKeyInfo in the
420 certificate represents the public key of the Key Signing Key (KSK).
421 The Subject field has the following attributes:
422
423 O: the string "ICANN".
424
425 OU: the string "IANA".
426
427 CN: the string "Root Zone KSK" followed by the time and date of key
428 generation in the format specified in [RFC3339]. For example, a
429 CN might be "Root Zone KSK 2010-06-16T21:19:24+00:00".
430
431 resourceRecord: a string in the presentation format of the DS
432 [RFC4034] resource record for the DNSSEC public key.
433
434
435
436
437 Abley, et al. Informational [Page 8]
438 RFC 7958 Root Zone Trust Anchor Publication August 2016
439
440
441 The "resourceRecord" attribute in the Subject is defined as follows:
442
443 ResourceRecord
444 { iso(1) identified-organization(3) dod(6) internet(1) security(5)
445 mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) }
446
447 DEFINITIONS IMPLICIT TAGS ::=
448
449 BEGIN
450
451 -- EXPORTS ALL --
452
453 IMPORTS
454
455 caseIgnoreMatch FROM SelectedAttributeTypes
456 { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 }
457
458 ;
459
460 iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
461 dod(6) internet(1) private(4) enterprise(1) 1000 }
462
463 iana-dns OBJECT IDENTIFIER ::= { iana 53 }
464
465 resourceRecord ATTRIBUTE ::= {
466 WITH SYNTAX IA5String
467 EQUALITY MATCHING RULE caseIgnoreMatch
468 ID iana-dns
469 }
470
471 END
472
473 2.3. Certificate Signing Requests
474
475 Each public key that can be used as a trust anchor is represented as
476 a CSR in PKCS #10 format. The SubjectPublicKeyInfo and Subject field
477 are the same as for certificates (see Section 2.2 above).
478
479 3. Root Zone Trust Anchor Retrieval
480
481 3.1. Retrieving Trust Anchors with HTTPS and HTTP
482
483 Trust anchors are available for retrieval using HTTPS and HTTP.
484
485 In this section, all URLs are given using the "https:" scheme. If
486 HTTPS cannot be used, replace the "https:" scheme with "http:".
487
488
489
490
491
492 Abley, et al. Informational [Page 9]
493 RFC 7958 Root Zone Trust Anchor Publication August 2016
494
495
496 The URL for retrieving the set of hashes described in Section 2.1 is
497 <https://data.iana.org/root-anchors/root-anchors.xml>.
498
499 The URL for retrieving the PKIX certificate described in Section 2.2
500 is <https://data.iana.org/root-anchors/KEYDIGEST-ID.crt>, with the
501 string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest
502 element from the XML file, as described in Section 2.1.2.
503
504 The URL for retrieving the CSR described in Section 2.3 is
505 <https://data.iana.org/root-anchors/KEYDIGEST-ID.csr>, with the
506 string "KEYDIGEST-ID" replacing the "id" attribute from the KeyDigest
507 element from the XML file, as described in Section 2.1.2.
508
509 4. Accepting DNSSEC Trust Anchors
510
511 A validator operator can choose whether or not to accept the trust
512 anchors described in this document using whatever policy they want.
513 In order to help validator operators verify the content and origin of
514 trust anchors they receive, IANA uses digital signatures that chain
515 to an ICANN-controlled Certificate Authority (CA) over the trust
516 anchor data.
517
518 It is important to note that the ICANN CA is not a DNSSEC trust
519 anchor. Instead, it is an optional mechanism for verifying the
520 content and origin of the XML and certificate trust anchors. It is
521 also important to note that the ICANN CA cannot be used to verify the
522 origin of the trust anchor in the CSR format.
523
524 The content and origin of the XML file can be verified using a
525 digital signature on the file. IANA provides a detached
526 Cryptographic Message Syntax (CMS) [RFC5652] signature that chains to
527 the ICANN CA with the XML file. The URL for a detached CMS signature
528 for the XML file is
529 <https://data.iana.org/root-anchors/root-anchors.p7s>.
530
531 (IANA also provided a detached OpenPGP [RFC4880] signature as a
532 second parallel verification mechanism for the first trust anchor
533 publication but has indicated that it will not use this parallel
534 mechanism in the future.)
535
536 Another method IANA uses to help validator operators verify the
537 content and origin of trust anchors they receive is to use the
538 Transport Layer Security (TLS) protocol for distributing the trust
539 anchors. Currently, the CA used for data.iana.org is well known,
540 that is, one that is a WebTrust-accredited CA. If a system
541 retrieving the trust anchors trusts the CA that IANA uses for the
542 "data.iana.org" web server, HTTPS SHOULD be used instead of HTTP in
543 order to have assurance of data origin.
544
545
546
547 Abley, et al. Informational [Page 10]
548 RFC 7958 Root Zone Trust Anchor Publication August 2016
549
550
551 5. IANA Considerations
552
553 This document defines id-mod-dns-resource-record, value 70 (see
554 Section 2.2), in the "SMI Security for PKIX Module Identifier"
555 registry.
556
557 6. Security Considerations
558
559 This document describes how DNSSEC trust anchors for the root zone of
560 the DNS are published. Many DNSSEC clients will only configure IANA-
561 issued trust anchors for the DNS root to perform validation. As a
562 consequence, reliable publication of trust anchors is important.
563
564 This document aims to specify carefully the means by which such trust
565 anchors are published, with the goal of making it easier for those
566 trust anchors to be integrated into user environments.
567
568 7. References
569
570 7.1. Normative References
571
572 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
573 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
574 <http://www.rfc-editor.org/info/rfc1034>.
575
576 [RFC1035] Mockapetris, P., "Domain names - implementation and
577 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
578 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
579
580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
581 Requirement Levels", BCP 14, RFC 2119,
582 DOI 10.17487/RFC2119, March 1997,
583 <http://www.rfc-editor.org/info/rfc2119>.
584
585 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
586 Request Syntax Specification Version 1.7", RFC 2986,
587 DOI 10.17487/RFC2986, November 2000,
588 <http://www.rfc-editor.org/info/rfc2986>.
589
590 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
591 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
592 <http://www.rfc-editor.org/info/rfc3339>.
593
594 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
595 Rose, "DNS Security Introduction and Requirements",
596 RFC 4033, DOI 10.17487/RFC4033, March 2005,
597 <http://www.rfc-editor.org/info/rfc4033>.
598
599
600
601
602 Abley, et al. Informational [Page 11]
603 RFC 7958 Root Zone Trust Anchor Publication August 2016
604
605
606 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
607 Rose, "Resource Records for the DNS Security Extensions",
608 RFC 4034, DOI 10.17487/RFC4034, March 2005,
609 <http://www.rfc-editor.org/info/rfc4034>.
610
611 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
612 Rose, "Protocol Modifications for the DNS Security
613 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
614 <http://www.rfc-editor.org/info/rfc4035>.
615
616 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
617 (DS) Resource Records (RRs)", RFC 4509,
618 DOI 10.17487/RFC4509, May 2006,
619 <http://www.rfc-editor.org/info/rfc4509>.
620
621 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
622 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
623 September 2007, <http://www.rfc-editor.org/info/rfc5011>.
624
625 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
626 Security (DNSSEC) Hashed Authenticated Denial of
627 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
628 <http://www.rfc-editor.org/info/rfc5155>.
629
630 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
631 Housley, R., and W. Polk, "Internet X.509 Public Key
632 Infrastructure Certificate and Certificate Revocation List
633 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
634 <http://www.rfc-editor.org/info/rfc5280>.
635
636 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
637 RFC 5652, DOI 10.17487/RFC5652, September 2009,
638 <http://www.rfc-editor.org/info/rfc5652>.
639
640 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
641 and RRSIG Resource Records for DNSSEC", RFC 5702,
642 DOI 10.17487/RFC5702, October 2009,
643 <http://www.rfc-editor.org/info/rfc5702>.
644
645 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
646 Operational Practices, Version 2", RFC 6781,
647 DOI 10.17487/RFC6781, December 2012,
648 <http://www.rfc-editor.org/info/rfc6781>.
649
650
651
652
653
654
655
656
657 Abley, et al. Informational [Page 12]
658 RFC 7958 Root Zone Trust Anchor Publication August 2016
659
660
661 7.2. Informative References
662
663 [DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter,
664 "DNSSEC Practice Statement for the Root Zone KSK
665 Operator", October 2015,
666 <https://www.iana.org/dnssec/icann-dps.txt>.
667
668 [RELAX-NG] Clark, J., "RELAX NG Compact Syntax",
669 Committee Specification, November 2002,
670 <https://www.oasis-open.org/committees/relax-ng/
671 compact-20021121.html>.
672
673 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
674 Thayer, "OpenPGP Message Format", RFC 4880,
675 DOI 10.17487/RFC4880, November 2007,
676 <http://www.rfc-editor.org/info/rfc4880>.
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712 Abley, et al. Informational [Page 13]
713 RFC 7958 Root Zone Trust Anchor Publication August 2016
714
715
716 Appendix A. Historical Note
717
718 The first KSK for use in the root zone of the DNS was generated at a
719 key ceremony at an ICANN Key Management Facility (KMF) in Culpeper,
720 Virginia, USA on 2010-06-16. This key entered production during a
721 second key ceremony held at an ICANN KMF in El Segundo, California,
722 USA on 2010-07-12. The resulting trust anchor was first published on
723 2010-07-15.
724
725 Acknowledgements
726
727 Many pioneers paved the way for the deployment of DNSSEC in the root
728 zone of the DNS, and the authors hereby acknowledge their substantial
729 collective contribution.
730
731 This document incorporates suggestions made by Alfred Hoenes and Russ
732 Housley, whose contributions are appreciated.
733
734 Authors' Addresses
735
736 Joe Abley
737 Dyn, Inc.
738 300-184 York Street
739 London, ON N6A 1B5
740 Canada
741
742 Phone: +1 519 670 9327
743 Email: jabley@dyn.com
744
745
746 Jakob Schlyter
747 Kirei AB
748
749 Email: jakob@kirei.se
750
751
752 Guillaume Bailey
753 Independent
754
755 Email: GuillaumeBailey@outlook.com
756
757
758 Paul Hoffman
759 ICANN
760
761 Email: paul.hoffman@icann.org
762
763
764
765
766
767 Abley, et al. Informational [Page 14]
768
Note that the KeyDigest element is optional; if it is not given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party.
Note that the validUntil attribute of the KeyDigest element is optional; if it is not given, the trust anchor can be used until a KeyDigest element covering the same DNSKEY record, but having a validUntil attribute, is trusted by the relying party.. If the relying party is using a trust anchor that has a KeyDigest element that does not have a validUntil attribute, it can change to a trust anchor with a KeyDigest element that does have a validUntil attribute, as long as that trust anchor's validUntil attribute is in the future and the DNSKEY elements of the KeyDigest are the same as the previous trust anchor.