idnits 2.17.1 draft-jabley-dnssec-trust-anchor-13.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 2 instances 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 (January 04, 2016) is 3028 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) Summary: 3 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: July 07, 2016 Kirei 6 G. Bailey 8 January 04, 2016 10 DNSSEC Trust Anchor Publication for the Root Zone 11 draft-jabley-dnssec-trust-anchor-13 13 Abstract 15 The root zone of the Domain Name System (DNS) has been 16 cryptographically signed using DNS Security Extensions (DNSSEC). 18 In order to obtain secure answers from the root zone of the DNS using 19 DNSSEC, a client must configure a suitable trust anchor. This 20 document describes how such trust anchors are published. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 07, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Root Zone Trust Anchor Publication . . . . . . . . . . . . . 3 58 2.1. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Certificate Signing Request (PKCS#10) . . . . . . . . . . 4 60 3. Root Zone Trust Anchor Retrieval . . . . . . . . . . . . . . 4 61 3.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Signature Verification . . . . . . . . . . . . . . . . . 5 64 4. Implementation Considerations . . . . . . . . . . . . . . . . 6 65 4.1. HTTP Over TLS Transport . . . . . . . . . . . . . . . . . 6 66 4.2. XML Validation . . . . . . . . . . . . . . . . . . . . . 6 67 4.3. Trust Anchor Validation . . . . . . . . . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Trust Anchor Publication Document Schema . . . . . . 10 75 Appendix B. Example Signed Trust Anchor Set . . . . . . . . . . 11 76 Appendix C. ASN.1 Module for DNS Resource Record . . . . . . . . 12 77 Appendix D. Historical Note . . . . . . . . . . . . . . . . . . 12 78 Appendix E. About this Document . . . . . . . . . . . . . . . . 12 79 E.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 13 80 E.2. Document History . . . . . . . . . . . . . . . . . . . . 13 81 E.2.1. draft-jabley-dnssec-trust-anchor-00 . . . . . . . . . 13 82 E.2.2. draft-jabley-dnssec-trust-anchor-01 . . . . . . . . . 13 83 E.2.3. draft-jabley-dnssec-trust-anchor-02 . . . . . . . . . 13 84 E.2.4. draft-jabley-dnssec-trust-anchor-04 . . . . . . . . . 13 85 E.2.5. draft-jabley-dnssec-trust-anchor-05 . . . . . . . . . 13 86 E.2.6. draft-jabley-dnssec-trust-anchor-06 . . . . . . . . . 13 87 E.2.7. draft-jabley-dnssec-trust-anchor-07 . . . . . . . . . 14 88 E.2.8. draft-jabley-dnssec-trust-anchor-10 . . . . . . . . . 14 89 E.2.9. draft-jabley-dnssec-trust-anchor-11 . . . . . . . . . 14 90 E.2.10. draft-jabley-dnssec-trust-anchor-12 . . . . . . . . . 14 91 E.2.11. draft-jabley-dnssec-trust-anchor-13 . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 95 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. 96 Security extensions to the DNS (DNSSEC) are described in [RFC4033], 97 [RFC4034], [RFC4035], [RFC4509], [RFC5155] and [RFC5702]. 99 A discussion of operational practices relating to DNSSEC can be found 100 in [RFC6781]. 102 In the DNSSEC protocol, resource record sets (RRSets) are signed 103 cryptographically. This means that a response to a query contains 104 signatures that allow the integrity and authenticity of the RRSet to 105 be verified. Signatures are validated by following a chain of 106 signatures to a key called a "trust anchor". The reason for trusting 107 such a key is outside the DNSSEC protocol, but having one or more 108 trust anchors is required for the DNSSEC protocol to work. 110 The publication of trust anchors for the root zone of the DNS is an 111 IANA function performed by ICANN. A detailed description of 112 corresponding key management practices can be found in [DPS], which 113 can be retrieved from the IANA Repository [IANA-DNSSEC-INFO]. 115 This document describes the distribution of the DNSSEC trust anchors 116 from IANA. This document is concerned only with the distribution of 117 trust anchors for the root zone, although the data formats and the 118 publication and retrieval methods described here can be adapted for 119 other uses. 121 The protocol described in this document is not a substitute for the 122 automated DNSSEC trust anchor update protocol described in [RFC5011]. 123 That protocol allows for secure in-band succession of trust anchors 124 when trust has already been established. The protocol described in 125 this document allows a trust anchor to initially be established out- 126 of-band, possibly relying on trusted out-of-band authorities. Thus, 127 this document and [RFC5011] are complementary protocols. 129 2. Root Zone Trust Anchor Publication 131 Trust anchors for the root zone are published in two formats, each of 132 which is described in this document: 134 o as the hashes of the corresponding DNSKEY records, consistent with 135 the defined presentation format of Delegation Signer (DS) resource 136 records [RFC4034], contained within an XML document, as described 137 in Section 2.1, and 139 o as Certificate Signing Requests (CSRs) in PKCS#10 format [RFC2986] 140 for further processing by other entities such as Certification 141 Authorities and validation of proof of possession of the 142 corresponding private keys, as described in Section 2.2. 144 2.1. XML 146 Trust anchors are published in an XML document whose schema is 147 described in Appendix A. The document contains a complete set of 148 trust anchors for the root zone, including anchors suitable for 149 immediate use and also historical data. 151 Examples of trust anchors packaged and signed for publication can be 152 found in Appendix B. 154 2.2. Certificate Signing Request (PKCS#10) 156 To facilitate signing the trust anchor by a public key 157 infrastructure, trust anchors are also published as Certificate 158 Signing Requests (CSRs) in PKCS#10 format [RFC2986]. 160 Each CSR will have a Subject with following attributes: 162 O: the string "ICANN". 164 OU: the string "IANA". 166 CN: the string "Root Zone KSK" followed by the time and date of key 167 generation in the format specified in [RFC3339], e.g. "Root Zone 168 KSK 2010-06-16T21:19:24+00:00". 170 resourceRecord: the hash of the public key consistent with the 171 presentation format of the Delegation Signer (DS) [RFC4034] 172 resource record (see Appendix C for attribute definition). 174 3. Root Zone Trust Anchor Retrieval 176 3.1. HTTP 178 Trust anchors are available for retrieval using HTTP [RFC2616]. 180 The URL for retrieving the CSR is , with "key-label" replaced by the key label of the 182 corresponding KSK. 184 The URL for retrieving a signed X.509 certificate is , with "key-label" again 186 replaced as described above. 188 The URL for retrieving the complete trust anchor set is available 189 from [TA-HTTP-XML]. 191 The URL for a detached S/MIME [RFC5751] signature for the current 192 trust anchor set, in XML format, is available from [TA-HTTP-SMIME]. 194 The URL for a detached OpenPGP [RFC4880] signature for the current 195 trust anchor set, in XML format, is available from [TA-HTTP-PGP]. 197 3.2. HTTP Over TLS 199 Trust anchors are available for retrieval using HTTP over TLS 200 [RFC2818]. 202 The URLs specified in Section 3.1 are also available using HTTPS. 203 That is: 205 The URL for retrieving the CSR is , with "key-label" replaced by the key label of the 207 corresponding KSK. 209 The URL for retrieving a signed X.509 certificate is , with "key-label" again 211 replaced as described above. 213 The URL for retrieving the complete trust anchor set available from 214 [TA-HTTPS-XML]. 216 The URL for a detached S/MIME [RFC5751] signature for the current 217 trust anchor set is available from [TA-HTTPS-SMIME]. 219 The URL for a detached OpenPGP [RFC4880] signature for the current 220 trust anchor set is available from [TA-HTTPS-PGP]. 222 TLS sessions are authenticated with certificates presented from the 223 server. No client certificate verification is performed. The 224 certificate presented by the server is chosen such that it can be 225 trusted using an X.509 trust anchor that is believed to be well- 226 known, e.g. one that corresponds to a WebTrust-accredited Certificate 227 Authority. Other TLS authentication mechanisms may be considered in 228 the future. 230 3.3. Signature Verification 232 The OpenPGP [RFC4880] keys used to sign trust anchor documents carry 233 signatures from personal keys of staff who are able to personally 234 attest to their validity. Those staff members will continue to make 235 their personal keys freely available for examination by third 236 parties, e.g. by way of PGP key parties at operator and IETF 237 meetings. In this fashion a diverse set of paths through the PGP web 238 of trust will be maintained to the trust anchor PGP keys. 240 An OpenPGP keyring containing public keys pertinent to signature 241 verification is published at [ICANN-PGP]. The public keys on that 242 keyring will also be distributed widely, e.g. to public PGP key 243 servers. 245 Certificates used to create S/MIME [RFC5751] signatures for the 246 current trust anchor set, in XML format, are signed by a Certificate 247 Authority (CA) administered by ICANN as the IANA functions operator 248 and also optionally by well-known (e.g. WebTrust-certified) CAs to 249 facilitate signature validation with widely-available X.509 trust 250 anchors. 252 4. Implementation Considerations 254 Note: This non-normative section gives suggestions for implementing 255 root zone trust anchor retrieval. 257 Root trust anchor retrieval by the HTTP or HTTP over TLS transports 258 has several implementation considerations to ensure robustness, 259 usability and secure operation. 261 4.1. HTTP Over TLS Transport 263 The HTTP over TLS transport [RFC2818] is suggested instead of using 264 the unencrypted HTTP transport [RFC2616] for implementations that use 265 the XML-format root trust anchors, since the latter transport does 266 not provide authentication. It is not suggested that implementations 267 restrict certification path validation of the HTTP over TLS transport 268 session to the current or historical certificate authorities used by 269 the root trust anchor server, since doing so would reduce robustness 270 of the implementation. It is suggested that the implementation 271 configure the HTTP over TLS transport library to: validate the 272 certification path against certificate revocation lists [RFC5280], 273 and/or with the online certificate status protocol [RFC6960]; and 274 reject self-signed certificates and certification paths that do not 275 terminate in a trusted certificate authority. 277 Implementations can allow configuration of the URL used to retrieve 278 the root trust anchor resources, but it is suggested that the default 279 configuration use the URLs specified in Section 3.2. 281 4.2. XML Validation 283 Implementations may perform strict validation of the retrieved XML 284 document against the XML schema; however, such an implementation 285 would not be robust against future changes in the XML schema. It is 286 suggested that the implementation perform "loose" validation, where 287 unknown attributes and elements are ignored. This suggestion allows 288 for future additions to the XML schema without affecting existing 289 implementations. 291 4.3. Trust Anchor Validation 293 The implementation can ignore trust anchors for which the Algorithm 294 or DigestType elements refer to an unknown, or unsupported algorithm. 295 Additionally, trust anchors for which the Algorithm or DigestType 296 elements refer to a deprecated algorithm can be ignored, provided 297 that this suggestion does not cause all trust anchors to be ignored. 298 Further, note that these suggestions may not apply where an 299 implementation shares trust anchors between many DNS validating 300 resolvers, since the set of supported algorithms may vary between 301 resolvers, and could possibly be disjoint. 303 The implementation can also ignore a trust anchor when the validUntil 304 time, if present, is in the past. If the implementation also 305 supports automated updates of trust anchors [RFC5011], it can ignore 306 trust anchors where the current time subtracted from the validFrom 307 time, if present, is greater than the add-hold down time [RFC5011] 308 for the trust point. 310 The implementation can reject any trust anchor for a trust point 311 other than the root zone. 313 5. IANA Considerations 315 Key Signing Key (KSK) management for the root zone is an IANA 316 function. This document describes an initial set of publication 317 mechanisms for trust anchors related to that management. In the 318 future, additional publication schemes may also be made available, in 319 which case they will be described in a new document that updates this 320 one. 322 Existing mechanisms will not be deprecated without very strong 323 technical justification. 325 This document serves as the reference for id-mod-dns-resource-record, 326 value 70, in the SMI Security for PKIX Module Identifier registry. 328 6. Security Considerations 330 This document describes how DNSSEC trust anchors for the root zone of 331 the DNS are published. It is to be expected that many DNSSEC clients 332 will only configure IANA-issued trust anchors to perform validation, 333 and that the trust anchors they use will be those of the root zone. 334 As a consequence, reliable publication of trust anchors is important. 336 This document aims to specify carefully the means by which such trust 337 anchors are published, as an aid to the formats and retrieval methods 338 described here being integrated usefully into user environments. 340 7. Acknowledgements 342 Many pioneers paved the way for the deployment of DNSSEC in the root 343 zone of the DNS, and the authors hereby acknowledge their substantial 344 collective contribution. 346 This document incorporates suggestions made by Paul Hoffman and 347 Alfred Hoenes, whose contributions are appreciated. 349 8. References 351 8.1. Normative References 353 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 354 STD 13, RFC 1034, November 1987. 356 [RFC1035] Mockapetris, P., "Domain names - implementation and 357 specification", STD 13, RFC 1035, November 1987. 359 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 360 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 361 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 363 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 365 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 366 Request Syntax Specification Version 1.7", RFC 2986, 367 November 2000. 369 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 370 Internet: Timestamps", RFC 3339, July 2002. 372 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 373 Rose, "DNS Security Introduction and Requirements", RFC 374 4033, March 2005. 376 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 377 Rose, "Resource Records for the DNS Security Extensions", 378 RFC 4034, March 2005. 380 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 381 Rose, "Protocol Modifications for the DNS Security 382 Extensions", RFC 4035, March 2005. 384 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 385 (DS) Resource Records (RRs)", RFC 4509, May 2006. 387 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 388 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 390 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 391 Trust Anchors", STD 74, RFC 5011, September 2007. 393 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 394 Security (DNSSEC) Hashed Authenticated Denial of 395 Existence", RFC 5155, March 2008. 397 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 398 Housley, R., and W. Polk, "Internet X.509 Public Key 399 Infrastructure Certificate and Certificate Revocation List 400 (CRL) Profile", RFC 5280, May 2008. 402 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 403 and RRSIG Resource Records for DNSSEC", RFC 5702, October 404 2009. 406 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 407 Mail Extensions (S/MIME) Version 3.2 Message 408 Specification", RFC 5751, January 2010. 410 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 411 Operational Practices, Version 2", RFC 6781, December 412 2012. 414 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 415 Galperin, S., and C. Adams, "X.509 Internet Public Key 416 Infrastructure Online Certificate Status Protocol - OCSP", 417 RFC 6960, June 2013. 419 8.2. Informative References 421 [DPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, 422 "DNSSEC Practice Statement for the Root Zone KSK 423 Operator", May 2010. 425 [IANA-DNSSEC-INFO] 426 , "IANA DNSSEC Information", , . 429 [ICANN-PGP] 430 , "ICANN PGP Keys", , 431 . 433 [TA-HTTP-PGP] 434 , "Root DNSSEC Trust Anchors (OpenPGP)", , 435 . 437 [TA-HTTP-SMIME] 438 , "Root DNSSEC Trust Anchors (S/MIME)", , 439 . 441 [TA-HTTP-XML] 442 , "Root DNSSEC Trust Anchors (XML)", , 443 . 445 [TA-HTTPS-PGP] 446 , "Root DNSSEC Trust Anchors (OpenPGP)", , . 449 [TA-HTTPS-SMIME] 450 , "Root DNSSEC Trust Anchors (S/MIME)", , . 453 [TA-HTTPS-XML] 454 , "Root DNSSEC Trust Anchors (XML)", , . 457 [root-anchors] 458 , "DNSSEC Trust Anchors", , . 461 Appendix A. Trust Anchor Publication Document Schema 463 A Relax NG Compact Schema for the documents used to publish trust 464 anchors can be found in Figure 1. 466 datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes" 468 start = element TrustAnchor { 469 attribute id { xsd:string }, 470 attribute source { xsd:string }, 471 element Zone { xsd:string }, 473 keydigest+ 474 } 476 keydigest = element KeyDigest { 477 attribute id { xsd:string }, 478 attribute validFrom { xsd:dateTime }, 479 attribute validUntil { xsd:dateTime }?, 480 element KeyTag { 481 xsd:nonNegativeInteger { maxInclusive = "65535" } }, 482 element Algorithm { 483 xsd:nonNegativeInteger { maxInclusive = "255" } }, 484 element DigestType { 485 xsd:nonNegativeInteger { maxInclusive = "255" } }, 486 element Digest { xsd:hexBinary } 487 } 489 Figure 1 491 Appendix B. Example Signed Trust Anchor Set 493 Figure 2 describes two trust anchors for the root zone such as might 494 be retrieved from [root-anchors]. 496 498 502 . 504 507 34291 508 5 509 1 510 c8cb3d7fe518835490af8029c23efbce6b6ef3e2 511 513 515 12345 516 5 517 1 518 a3cf809dbdbc835716ba22bdc370d2efa50f21c7 519 521 523 Figure 2 525 Appendix C. ASN.1 Module for DNS Resource Record 527 ResourceRecord 528 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 529 mechanisms(5) pkix(7) id-mod(0) id-mod-dns-resource-record(70) } 531 DEFINITIONS IMPLICIT TAGS ::= 533 BEGIN 535 -- EXPORTS ALL -- 537 IMPORTS 539 caseIgnoreMatch FROM SelectedAttributeTypes 540 { joint-iso-itu-t ds(5) module(1) selectedAttributeTypes(5) 4 } 542 ; 544 iana OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 545 dod(6) internet(1) private(4) enterprise(1) 1000 } 547 iana-dns OBJECT IDENTIFIER ::= { iana 53 } 549 resourceRecord ATTRIBUTE ::= { 550 WITH SYNTAX IA5String 551 EQUALITY MATCHING RULE caseIgnoreIA5Match 552 ID iana-dns 553 } 555 END 557 Appendix D. Historical Note 559 The first KSK for use in the root zone of the DNS was generated at a 560 key ceremony at an ICANN Key Management Facility (KMF) in Culpeper, 561 Virginia, USA on 2010-06-16. This key entered production during a 562 second key ceremony held at an ICANN KMF in El Segundo, California, 563 USA on 2010-07-12. The resulting trust anchor was first published on 564 2010-07-15. 566 Appendix E. About this Document 568 [RFC Editor: please remove this section, including all subsections, 569 prior to publication.] 571 E.1. Discussion 573 This document is not the product of any IETF working group. However, 574 communities interested in similar technical work can be found at the 575 IETF in the DNSOP and DNSEXT working groups. 577 The team responsible for deployment of DNSSEC in the root zone can be 578 reached at rootsign@icann.org. 580 The authors also welcome feedback sent to them directly. 582 E.2. Document History 584 E.2.1. draft-jabley-dnssec-trust-anchor-00 586 This document is based on earlier documentation used within and 587 published by the team responsible for DNSSEC deployment in the root 588 zone. This is the first revision circulated with the intention of 589 publication in the RFC series. 591 E.2.2. draft-jabley-dnssec-trust-anchor-01 593 Incorporated initial community suggestions. Editorial improvements. 594 Allocate OID and clean up syntax of ASN.1 module. 596 E.2.3. draft-jabley-dnssec-trust-anchor-02 598 Draft expired. 600 E.2.4. draft-jabley-dnssec-trust-anchor-04 602 Added the optional element to the XML schema to provide 603 a mechanism for locating external X.509 certificates relating to a 604 particular key. 606 E.2.5. draft-jabley-dnssec-trust-anchor-05 608 Update author address. 610 E.2.6. draft-jabley-dnssec-trust-anchor-06 612 Update references. 614 E.2.7. draft-jabley-dnssec-trust-anchor-07 616 Minor changes based on review by Paul Hoffman. 618 E.2.8. draft-jabley-dnssec-trust-anchor-10 620 Incorporate additional suggestions by Paul Hoffman. Add 621 consideration for OCSP to Implementation Considerations. 623 E.2.9. draft-jabley-dnssec-trust-anchor-11 625 Draft expired. 627 E.2.10. draft-jabley-dnssec-trust-anchor-12 629 Draft expired. 631 E.2.11. draft-jabley-dnssec-trust-anchor-13 633 Update author address and affiliation. 635 Removed the element from the XML schema. 637 Authors' Addresses 639 Joe Abley 640 Dyn, Inc. 641 470 Moore Street 642 London, ON N6C 2C2 643 Canada 645 Phone: +1 519 670 9327 646 Email: jabley@dyn.com 648 Jakob Schlyter 649 Kirei AB 651 Email: jakob@kirei.se 653 Guillaume Bailey 655 Email: GuillaumeBailey@outlook.com