idnits 2.17.1 draft-laurie-dnssec-key-distribution-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2006) is 6526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3757' is mentioned on line 90, but not defined ** Obsolete undefined reference: RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Unused Reference: 'I-D.ietf-dnsext-rfc2538bis' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC2418' is defined on line 239, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Laurie 3 Internet-Draft Nominet 4 Expires: December 16, 2006 June 14, 2006 6 Distributing Keys for DNSSEC 7 draft-laurie-dnssec-key-distribution-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 16, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Until DNSSEC is fully deployed, so-called "islands of trust" will 41 exist. This will lead to a large number of keys with no method 42 within DNSSEC to manage the keys. This proposal seeks to address 43 that issue using existing mechanisms to allow cross-signing of root 44 (i.e. roots of islands) keys. This cross-signing of keys creates a 45 non-hierarchical web of trust which permits the efficient gathering 46 and validation of trust anchors. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Island CAs . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Key Signing . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Publication of Certificates . . . . . . . . . . . . . . . . . . 4 54 5. Location of Island Publication URL . . . . . . . . . . . . . . 4 55 6. Use of Certificates . . . . . . . . . . . . . . . . . . . . . . 4 56 7. Verification of Certificates . . . . . . . . . . . . . . . . . 5 57 8. Variations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 9. Security Non-issues . . . . . . . . . . . . . . . . . . . . . . 5 59 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 60 11. Requirements notation . . . . . . . . . . . . . . . . . . . . . 6 61 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 13.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 13.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction 70 When DNSSEC signatures are validated the validators will follow a 71 chain of authority from a pre-configured trust anchor to the data 72 that is to be validated. The DNSSEC protocol (RFC 4033 [RFC4033], 73 RFC 4034 [RFC4034] and RFC 4035 [RFC4035]) clearly describes how 74 these chains of trust are to be established but does not address the 75 issue of the distribution of the trust anchors. 77 This document describes how an X.509 based public key infrastructure 78 can be used to bootstrap the configuratation of a set of trust 79 anchors. SEP keys are stored in certificates that are signed by the 80 registries' Certificate Authorities. The system allows registries to 81 indicate levels of trust which allows for prudent cross-signing. 83 The Certificate Authority and the certificates are discussed in 84 Section 2 and Section 3. Section 4 and Section 5 describe how the 85 certificates are published. Section 6 describes how the certificates 86 are used to establish the trust-anchors. 88 In this document the term secure entry point (SEP) key is used to 89 describe the (sub)set of public key(s) that is intended as a secure 90 entry point into the zone [RFC3757]. The term Island of security, or 91 island for short, is used for a zone for which one of the SEP keys 92 are used as a trust-anchor and which is therefore the start of a 93 chain of authority. 95 2. Island CAs 97 The root of each island will publish an X.509 CA certificate. This 98 will be a long-term, self-signed certificate, known as the Island 99 Root CA (IRCA). This CA will then be used to create two subsidiary 100 CAs, each with a shorter expiry, known as the High Assurance Island 101 CA and the Low Assurance Island CA. The High and Low Assurance CA 102 certificates will each contain an X.509v3 extension indicating their 103 role. 105 Each island will have a set of requirements for cross-signing, one 106 for low assurance and one for high assurance. The reason for having 107 two is to allow cross-signing of keys that the island's operators do 108 not have high confidence in without exposing them to accusations of 109 insufficient prudence. 111 3. Key Signing 113 Each island will issue a certificate signed by the Island Root CA for 114 each of its own SEPs. The public key in the certificate will be the 115 same public key as used by the SEP. 117 For each other island that meets the island's requirements for cross- 118 signing, the island will issue a certificate for their IRCA signed by 119 either the Low or High Assurance Island CA, as appropriate. That is, 120 the certificate will have the same subject name and public key as the 121 IRCA being signed, but the issuer will be one of this island's 122 subsidiary CAs. This could be done using the cross-certification 123 protocol from RFC 2510 [RFC2510] 125 Each certificate issued will contain an X.509v3 extension with the 126 name of the domain associated with the signed public key. 128 4. Publication of Certificates 130 Each island will maintain a URL (known as the Island Publication URL 131 or IPU) where all current certificates issued by any of its CAs are 132 available. This URL may also have a collection of certificates 133 issued by other island CAs and also the CA certificates themselves of 134 other islands. Note, however, that the presence of a certificate 135 does not indicate any kind of trust in it - that is done purely by 136 the certificate signatures. 138 5. Location of Island Publication URL 140 The location of each IPU will be held in the IRCA using an X.509v3 141 certificate extension registered for the purpose. 143 6. Use of Certificates 145 A resolver wishing to bootstrap its collection of trust anchors need 146 only choose a small set of IRCAs to trust (or, with luck, a single 147 one). Once it has done so, it can extract the IPU from the CA 148 certificate, use HTTP to retrieve the certificate collection 149 available there, check their (chained) signatures, extract the public 150 keys from the certificates and use these as the initial set of SEPs 151 for the domains named in the certificates. 153 Once the initial set of certificates has been retrieved, this process 154 can be followed recursively for other IRCAs retrieved. Also, the set 155 of trusted IRCAs could be expanded to include some or all of the 156 retrieved IRCAs. 158 After the set of trusted trust anchors have been established, in-band 159 mechanisms can be used to keep them up to date. If for some reason 160 the set of trust anchors becomes too stale to update (for example, 161 because the device has been offline for an extended period), then the 162 process can be repeated from the start. 164 7. Verification of Certificates 166 Once the collection of certificates is complete, the resolver uses 167 the trusted IRCAs to verify the certificate of each SEP. Because of 168 the use of cross-certification, the X.509 verification must be 169 capable of trying multiple paths to verification, as specified in RFC 170 3280 [RFC3280]. 172 Users may choose to restrict the verification path, for example by 173 requiring certificate chains to be below some length, or not 174 permitting verification through Low Assurance CAs. 176 Once the set of verified SEPs has been established, then the public 177 keys are extracted from each one and associated as trust anchors for 178 DNSSEC with the corresponding domain. 180 8. Variations 182 Instead of a URL, the certificate could contain a domain name and 183 socket number. 185 Certificates could be published in the DNS [I-D.ietf-dnsext- 186 rfc2538bis]. 188 Rather than using X.509 for signing, OpenPGP [RFC2440] could be used 189 instead. 191 9. Security Non-issues 193 Note that DNSSEC is not required to secure the domain names used for 194 certificate retrieval, since the signature of the selected IRCA(s) 195 will be sufficient to validate the retrieved certificates. 197 10. Acknowledgements 199 Thanks to Olaf Kolkman for comments on early drafts and Russ Housley 200 for explaining how to use X.509 the way I wanted to. 202 11. Requirements notation 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 12. Security Considerations 210 13. References 212 13.1. Normative References 214 [I-D.ietf-dnsext-rfc2538bis] 215 Josefsson, S., "Storing Certificates in the Domain Name 216 System (DNS)", draft-ietf-dnsext-rfc2538bis-09 (work in 217 progress), October 2005. 219 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 220 "OpenPGP Message Format", RFC 2440, November 1998. 222 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 223 Infrastructure Certificate Management Protocols", 224 RFC 2510, March 1999. 226 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 227 X.509 Public Key Infrastructure Certificate and 228 Certificate Revocation List (CRL) Profile", RFC 3280, 229 April 2002. 231 13.2. Informative References 233 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 234 3", BCP 9, RFC 2026, October 1996. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 240 Procedures", BCP 25, RFC 2418, September 1998. 242 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 243 Rose, "DNS Security Introduction and Requirements", 244 RFC 4033, March 2005. 246 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 247 Rose, "Resource Records for the DNS Security Extensions", 248 RFC 4034, March 2005. 250 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 251 Rose, "Protocol Modifications for the DNS Security 252 Extensions", RFC 4035, March 2005. 254 Author's Address 256 Ben Laurie 257 Nominet 258 17 Perryn Road 259 London W3 7LR 260 England 262 Phone: +44 (20) 8735 0686 263 Email: ben@algroup.co.uk 265 Intellectual Property Statement 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be 274 found in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this 280 specification can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at 287 ietf-ipr@ietf.org. 289 Disclaimer of Validity 291 This document and the information contained herein are provided on an 292 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 293 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 294 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 295 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 296 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 297 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 299 Copyright Statement 301 Copyright (C) The Internet Society (2006). This document is subject 302 to the rights, licenses and restrictions contained in BCP 78, and 303 except as set forth therein, the authors retain all their rights. 305 Acknowledgment 307 Funding for the RFC Editor function is currently provided by the 308 Internet Society.