Signature Algorithm Identifiers

As discussed on the interim call this week, there’s a proposal for changing the algorithm identifiers used in the message signatures draft. There was spirited discussion on the topic, which I’ll try to summarize here, and it’s been discussed in the following issue:

https://github.com/httpwg/http-extensions/issues/1510 <https://github.com/httpwg/http-extensions/issues/1510>

First, please note that we are only talking about the algorithm identifiers, not the algorithm definitions. The identifiers are simple strings, not parsed structures. Their job is to convey to an implementor a unique value that can be dereferenced to a fully-defined algorithm definition; the definition would include the parameters, the identifier does not. Also, note that the algorithm identifiers are optional within the protocol. Message signatures explicitly allows ANY signature method to be used if known by both parties, and the algorithm identifiers are there solely for the purpose of identifying a known algorithm at runtime against a set of publicly known fixed values in a registry. 

The editors have defined the following identifiers in the current draft, to be used with fully-specified cryptographic algorithms:

- rsa-v1_5-sha256
- rsa-pss-sha512
- hmac-sha256
- ecdsa-p256-sha256

Additional algorithms can be defined in an IANA registry, and as stated above, applications are free to use their own signature algorithms without registering a code point.

The counter-proposal in question (at the issue above) proposes a date-based method for identifiers instead (replacing each identifier in the above list respectively):

 - rsa-2003
 - rsa-2005
 - hmac-2006
 - ecdsa-2013

Summarizing some of the arguments for and against presented on the call:

In favor:
 - simpler for developers to pick the “latest” date of an algorithm as more secure
 - developers will pick a higher number without having to understand the differences
 - can “nudge” the community to using better algorithms through labeling
 - can register new date identifiers to “refresh” best practice definitions
 - names are shorter and don’t look like cryptographic primitives

In opposition: 
 - date is a poor stand-in for a quality metric
 - developers will pick a higher number without understanding differences
 - newer algorithms and profiles aren’t necessarily “better” than older ones
 - if a community-specific profile is defined later, like rsa-2024 for IoT devices, it could lead to developers choosing poorly-fit security
 - developers still need to know the difference between RSA, hmac, ecdsa, etc, otherwise “hmac-2006” looks universally better than “rsa-2005”
 - proposed names are not generally known or meaningful to  cryptography experts and developers, while current names are descriptive and recognizable to them
 - namespace collision if two profiles are published within a single year

What stays the same in both cases:
 - Algorithm parameters are defined in a document paragraph referenced from the identifier (the identifier itself does not define parameters)
 - Algorithms must be fully defined in a standard to be registered
 - Applications can still use whatever they want and avoid the named algorithm field entirely

The sentiment on the call seemed fairly clear, but the editors are seeking feedback and consensus as to whether the registered draft should switch to the date-based identifier format as proposed or to keep the current labels. 

Thank you,
 — Justin