Cryptographic Algorithm Identifier Allocation for DNSSEC
Extracted elements (9)
Experimental or documentation-only reserved values were considered and rejected. Historical IETF experience showed experimental values tend to become permanent when software ships with them before a 'real' value is assigned, causing interoperability lock-in that no one wants to break.
The requirement was relaxed from Standards Track to RFC Required for two reasons: some useful algorithms may not qualify for Standards Track due to insufficient evaluation or unclear intellectual property rights; and with infrequent new algorithm proposals and ~250 available entries, restricting the registry is unnecessary for decades.
The order of algorithms in the IANA registry does not signify or imply cryptographic strength or preference; implementations must not infer relative security from registry ordering.
DNSSEC implementations are not required to include all algorithms listed in the IANA registry; only algorithms listed as mandatory-to-implement in RFC 4034 (or its updates) must be implemented for compliance. This document does not change the mandatory-to-implement list.
IANA has marked values 123 through 251 as 'Reserved' in the DNS Security Algorithm Numbers registry. When most unreserved values are taken, the IETF should re-evaluate registry entry requirements.
The registration procedure for new values in the DNS Security Algorithm Numbers registry is 'RFC Required', meaning any published RFC of any type (not just Standards Track) suffices for an algorithm to receive an assigned identifier.
Private-use algorithm identifier values 253 and 254 remain unchanged in semantics. They allow developers to test algorithms for which no RFC exists; each use must include an unregistered private name to differentiate algorithms sharing those values.
This document updates the registration procedure for the 'Domain Name System Security (DNSSEC) Algorithm Numbers' sub-registry from 'Standards Action' to 'RFC Required', effective for all values assigned after publication.
An algorithm described in a non-Standards-Track RFC may have weaker security than one on the Standards Track—that may be why it was excluded from Standards Track. However, not being on the Standards Track does not necessarily mean an algorithm is weak; intellectual property concerns can keep strong algorithms off Standards Track.