[SSL Observatory] Proposal for IETF Crypto Registry cleanup

[Phillip Hallam-Baker]

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.

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.


In particular I am considering making the following proposal:

IETF requests IANA create three new registries of cryptographic algorithms
as follows:


1) Registry of Cryptographic Algorithm Identifiers.

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.)

The criteria for inclusion would be expert review and RFC required.

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.

The document would be required to

1) Specify the code points for ASN.1 OID, text string, URI and optionally
additional code points for IPSEC, DNSSEC, etc.
2) Specify test vectors in a format that ensures that endian-ness issues
are addressed.
3) Specify the location where further documentation is to be found (which
might be another RFC).


2) Registry of Mandatory to Implement Algorithms

This would be a subset of the algorithms specified in the first registry
and would normally consist of exactly one algorithm of each class.

Criteria for changes would be Standards Action required. Each RFC making
changes would specify the full list of required algorithms each time.

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'


3) Registry of Deprecated Algorithms.

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.

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.

Criteria for changes would be Standards Action required. This would also be
cumulative.

To be in compliance with this specification, applications MUST NOT permit
the use of those algorithms (even if the user requests them).

So to specify compliance, a product would state 'Complies with RFC 2616,
RFC 5246, RFC XXXX & RFC YYYY'


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.

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.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111115/9bc883f8/attachment.html>