<div>During the Jose meeting at the IETF on Monday morning (i.e. Sunday night for me) there was a side discussion about the current state of the IANA registries of cryptographic algorithms. At the moment there are 16 or so separate registries some of which use OIDS, some of which use numeric codes, some of which use text strings.</div>
<div><br></div><div>JOSE may turn out to be a forcing function for defining a new master registry, which is something I have been pushing for for some time. I think that the discussion is relevant here because should that effort get off the ground it could also serve to provide a mechanism for declaring key sizes insufficient and algorithms obsolete.</div>
<div><br></div><div><br></div><div>In particular I am considering making the following proposal:</div><div><br></div><div>IETF requests IANA create three new registries of cryptographic algorithms as follows:</div><div><br>
</div><div><br></div><div>1) Registry of Cryptographic Algorithm Identifiers.</div><div><br></div><div>This would be a registry that is divided up into separate sub-registries for various types of algorithm (public key signature, public key encryption, digest, encryption, mac, suites, etc.)</div>
<div><br></div><div>The criteria for inclusion would be expert review and RFC required. </div><div><br></div><div>The RFC would start off with a pre-amble that states that the IETF makes no endorsement of the strength of the cryptographic algorithm and the expert review would be strictly limited to determining that the format of the document is correct, the document would not be allowed to specify code either. The purpose of these requirements being to prevent people from presenting assignment of code points as an IETF endorsement of the algorithm strength.</div>
<div><br></div><div>The document would be required to </div><div><br></div><div>1) Specify the code points for ASN.1 OID, text string, URI and optionally additional code points for IPSEC, DNSSEC, etc.</div><div>2) Specify test vectors in a format that ensures that endian-ness issues are addressed.</div>
<div>3) Specify the location where further documentation is to be found (which might be another RFC).</div><div><br></div><div><br></div><div>2) Registry of Mandatory to Implement Algorithms</div><div><br></div><div>This would be a subset of the algorithms specified in the first registry and would normally consist of exactly one algorithm of each class. </div>
<div><br></div><div>Criteria for changes would be Standards Action required. Each RFC making changes would specify the full list of required algorithms each time.</div><div><br></div><div>Specifying compliance with this would be separate from specifying compliance with the base specification. So if a vendor was specifying standards compliance for its Web server it would specify 'Complies with RFC 2616, RFC 5246 & RFC XXXX'</div>
<div><br></div><div><br></div><div>3) Registry of Deprecated Algorithms.</div><div><br></div><div>This is the registry of algorithms and key sizes that IETF warns against using. The warning may be immediate or have some specific action date.</div>
<div><br></div><div>It would also be possible to state that an algorithm is deprecated for specific purposes or with certain protocols. For example, MD5 should not be used for any purpose that requires protection against collision attack. There are certainly cases where use of MD5 does not raise a security issue, though the cost of going through the necessary justification is almost never going to be worthwhile unless there is a major legacy deployment issue. </div>
<div><br></div><div>Criteria for changes would be Standards Action required. This would also be cumulative.</div><div><br></div><div>To be in compliance with this specification, applications MUST NOT permit the use of those algorithms (even if the user requests them).</div>
<div><br></div><div>So to specify compliance, a product would state 'Complies with RFC 2616, RFC 5246, RFC XXXX & RFC YYYY'</div><div><br></div><div><br></div><div>The task of ongoing maintenance would be left to the IETF SAAG and SECDIR. Actually making these decisions is much less difficult than deciding on having one place to make them.</div>
<div><br></div><div>Although the bar is set at 'standards action required', this would normally be something I would see being done on an individual submission basis rather than requiring a Working Group to be formed.</div>
<div><br></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>