Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6014 VPN Consortium
Updates: 4033, 4034, 4035 November 2010
Category: Standards Track
ISSN: 2070-1721
Cryptographic Algorithm Identifier Allocation for DNSSEC
Hoffman Standards Track [Page 1]
RFC 6014 DNSSEC Alg. Allocation November 2010
Copyright Notice
1. Introduction
[RFC2535] specifies that the IANA registry for DNS Security Algorithm Numbers be updated by IETF Standards Action only, with the exception of two values -- 253 and 254. In essence, this means that for an algorithm to get its own entry in the registry, the algorithm must be defined in an RFC on the Standards Track as defined in [RFC2026]. The requirement from RFC 2535 is repeated in [RFC3755] and the combination of [RFC4033], [RFC4034], and [RFC4035].
Hoffman Standards Track [Page 2]
RFC 6014 DNSSEC Alg. Allocation November 2010
This document changes the requirement for registration from requiring a Standards Track RFC to requiring a published RFC of any type. There are two reasons for relaxing the requirement:
3. Expectations for Implementations
It is important to note that, according to RFC 4034, DNSSEC implementations are not expected to include all of the algorithms listed in the IANA registry; in fact, RFC 4034 and the IANA registry list an algorithm that implementations should not include. This document does nothing to change the expectation that there will be items listed in the IANA registry that need not be (and in some cases, should not be) included in all implementations. There are many reasons why a DNSSEC implementation might not include one or more of the algorithms listed, even those on the Standards Track. In order to be compliant with RFC 4034, an implementation only needs to implement the algorithms listed as mandatory to implement in that standard, or updates to that standard. This document does nothing to change the list of mandatory-to-implement algorithms in RFC 4034. This document does not change the requirements for when an algorithm becomes mandatory to implement. Such requirements should come in a separate, focused document.
Hoffman Standards Track [Page 3]
RFC 6014 DNSSEC Alg. Allocation November 2010
It should be noted that the order of algorithms in the IANA registry does not signify or imply cryptographic strength or preference.
4. IANA Considerations
This document updates allocation requirements for unassigned values in the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry located at http://www.iana.org/assignments/ dns-sec-alg-numbers, in the sub-registry titled "DNS Security Algorithm Numbers". The registration procedure for values that are assigned after this document is published is "RFC Required".
5. Security Considerations
An algorithm described in an RFC that is not on the Standards Track may have weaker security than one that is on the Standards Track; in fact, that may be the reason that the algorithm was not allowed on Standards Track. Note, however, that not being on the Standards Track does not necessarily mean that an algorithm is weaker. Conversely, algorithms that are on the Standards Track should not necessarily be considered better than algorithms that are not on the Standards Track. There are other reasons (such as intellectual property concerns) that can keep algorithms that are widely considered to be strong off the Standards Track.
Hoffman Standards Track [Page 4]
RFC 6014 DNSSEC Alg. Allocation November 2010 6. References 6.1. Normative References[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
6.2. Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Hoffman Standards Track [Page 5]
RFC 6014 DNSSEC Alg. Allocation November 2010 Appendix A. Experimental and Documentation ValuesDuring the early discussion of this document, it was proposed that maybe there should be a small number of values reserved for "experimental" purposes. This proposal was not included in this document because of the long history in the IETF of experimental values that became permanent. That is, a developer would release (maybe "experimentally") a version of software that had the experimental value associated with a particular extension, competitors would code their systems to test interoperability, and then no one wanted to change the values in their software to the "real" value that was later assigned.
