idnits 2.17.1 draft-ietf-dnsext-dnssec-alg-allocation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2535, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3755, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2535, updated by this document, for RFC5378 checks: 1997-07-24) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 22, 2009) is 5328 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) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Updates: 2535, 3755, 4034 September 22, 2009 5 (if approved) 6 Intended status: Standards Track 7 Expires: March 26, 2010 9 Cryptographic Algorithm Identifier Allocation for DNSSEC 10 draft-ietf-dnsext-dnssec-alg-allocation-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 26, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document specifies how DNSSEC cryptographic algorithm 59 identifiers in the IANA registries are allocated. It changes the 60 rule from "standard required" to "RFC required". It does not change 61 the list of algorithms that are recommended or required for DNSSEC 62 implementations. 64 1. Introduction 66 [RFC2535] specifies that that IANA registry for DNS Security 67 Algorithm Numbers be updated by IETF Standards Action only, with the 68 exception of two values 253 and 254. In essence, this means that for 69 an algorithm to get its own entry in the registry, the algorithm must 70 be defined in an RFC on Standards Track as defined in [RFC2026]. The 71 rule from RFC 2535 is repeated in [RFC3755] and [RFC4034]. 73 RFC 2535 allows algorithms that are not on standards track to use 74 private values 253 and 254 in signatures. In each case, an 75 unregistered private name must be included with each use of the 76 algorithm in order to differentiate different algorithms that use the 77 value. 79 2. Requirements for Assignments in the DNS Security Algorithm Numbers 80 Registry 82 This document changes the rule for registration from requiring a 83 Standards Track RFC to requiring a published RFC of any type. There 84 are two reasons for relaxing the rule: 86 o There are some algorithms that are useful that may not be able to 87 be in a Standards Track RFC. For example, an algorithm might be 88 sponsored by a government and use cryptography that has not been 89 evaluated thoroughly enough to be able to be put on Standards 90 Track. Another example is that the algorithm might have an 91 unclear intellectual property rights situation, and that prevents 92 the algorithm from being put on Standards Track. 94 o Although the size of the registry is quite restricted (about 250 95 entries), new algorithms are proposed relatively rarely. It could 96 easily be many decades before there is any reason to consider 97 restricting the registry again. 99 Some developers will care about the standards level of the RFCs that 100 are in the registry. The registry should reflect the current 101 standards level of each algorithm listed. 103 Because the size of the registry is smaller than many IETF 104 registries, and because some members of the DNS community have 105 expressed concern about the registry eventually filling up, the IETF 106 should re-evaluate the requirements for entry into this registry when 107 the registry is about half full. That evaluation may lead to tighter 108 restrictions or a new mechanism for essentially extending the size of 109 the registry. 111 The private-use values, 253 and 254, are still useful for developers 112 who want to test, in private, algorithms for which there is no RFC. 113 This document does not change the semantics of those two values. 115 3. Expectations For Implementations 117 It is important to note that, according to RFC 4034, DNSSEC 118 implementations are not expected to include all of the algorithms 119 listed in the IANA registry; in fact, RFC 4034 and the IANA registry 120 list an algorithm that implementations should not include. This 121 document does nothing to change the expectation that there will be 122 items listed in the IANA registry that need not be (and in some 123 cases, should not be) included in all implementations. 125 There are many reasons why a DNSSEC implementation might not include 126 one or more of the algorithms listed, even those on Standards Track. 127 In order to be compliant with the RFC 4034, an implementation only 128 needs to implement the algorithms listed as mandatory to implement in 129 that standard, or updates to that standard. This document does 130 nothing to change the list of mandatory to implement algorithms in 131 RFC 4034. 133 It should be noted that the order of algorithms in the IANA registry 134 does not signify or imply cryptographic strength or preference. 136 4. IANA Considerations 138 This document updates allocation rules for unassigned values in the 139 "Domain Name System Security (DNSSEC) Algorithm Numbers" registry 140 located at http://www.iana.org/assignments/dns-sec-alg-numbers/ 141 dns-sec-alg-numbers.xhtml, in the sub-registry titled "DNS Security 142 Algorithm Numbers". The registration procedure for values that were 143 not assigned before this document is published is "RFC Required". 145 IANA is requested to add a textual notation to the "References" 146 column in the registry that gives the current standards status for 147 each RFC that is listed in the registry. 149 5. Security Considerations 151 An algorithm described in an RFC that is not on Standards Track may 152 have weaker security than one that is on standards track; in fact, 153 that may be the reason that the algorithm was not allowed on 154 Standards Track. Note, however, that not being on Standards Track 155 does not necessarily mean that an algorithm is weaker. There are 156 other reasons (such as intellectual property concerns) that can keep 157 algorithms that are widely considered to be strong off of Standards 158 Track. 160 6. References 162 6.1. Normative References 164 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 165 RFC 2535, March 1999. 167 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 168 Signer (DS)", RFC 3755, May 2004. 170 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 171 Rose, "Resource Records for the DNS Security Extensions", 172 RFC 4034, March 2005. 174 6.2. Informative References 176 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 177 3", BCP 9, RFC 2026, October 1996. 179 Appendix A. Experimental and Documentation Values 181 During the early discussion of this document, it was proposed that 182 maybe there should be a small number of values reserved for 183 "experimental" purposes. This proposal was not included in this 184 document because of the long history in the IETF of experimental 185 values that became permanent. That is, a developer would release 186 (maybe "experimentally") a version of software that had the 187 experimental value associated with a particular extension, 188 competitors would code their systems to test interoperability, and 189 then no one wanted to change the values in their software to the 190 "real" value that was later assigned. 192 There was also a proposal that IANA should reserve two values to be 193 used in documentation only, similar to the way that "example.com" has 194 been reserved as a domain name. That proposal was also not included 195 in this document because all values need to be associated with some 196 algorithm, and there is no problem with having examples that point to 197 commonly-deployed algorithms. 199 Appendix B. Change History 201 This section is to be removed before publication as an RFC. 203 B.1. Differences between draft-hoffman-dnssec-alg-allocation-00 and -01 205 A few editorial nits that really should have been caught in the -00. 207 Added the section on "Expectations For Implementations" to clarify 208 that this document is not changing any such expectations or updating 209 that part of RFC 4034. 211 B.2. Differences between draft-hoffman-dnssec-alg-allocation-01 and 212 draft-ietf-dnsext-dnssec-alg-allocation-00 214 First WG draft. 216 Clarified the intent of the document in the Abstract by adding "It 217 does not change the list of algorithms that are recommended or 218 required for DNSSEC implementations". 220 Added to Section 3: "It should be noted that the order of algorithms 221 in the IANA registry does not signify or imply cryptographic strength 222 or preference." 224 Author's Address 226 Paul Hoffman 227 VPN Consortium 229 Email: paul.hoffman@vpnc.org