Hi Phillip,
On 1/4/14 7:43 PM, Phillip Hallam-Baker wrote:
IETF should only endorse a single core set of algorithms with a
maximum of one preferred and one alternative algorithm and this should
be an IETF consensus, not a WG consensus. A WG might add in additional
recommendations to support legacy interop, for example 3DES is still a
defacto requirement for S/MIME.
The 1+1 approach seems a good ideal from an interoperability
perspective. What we the IETF lack is sufficient expertise to "endorse"
crypto. Yes we have some people who know some stuff, but not at the
heavy math end of it, which is where you want it. The benefit of
developing this expertise would be that there could be a go-to place
that is viewed by governments without the need to develop their own
specifications or endorse "in country" specifications. But that will
take a long time. This could also be done elsewhere, but the key would
be to follow the OpenStand principles.
How this stuff is endorsed (e.g., an IETF working group or by the whole
of the IETF) is an interesting question. The question that must be
answered is whether all of our specifications would make use of the same
algorithm in the same way. If the answer is yes, then we can shut down
registries. I fear the answer is no, but the aspiration is still a good
one, when it is possible. Arguably what you are really getting at is
that we need to have the right common building blocks to handle all of
encryption (e.g., TLS, S/MIME, and a few others). Developers want to
reuse code. My personal experience is that I have perhaps re-used code
(maybe as we all have) in ways that it was really not intended to be
used, hoping that the semantics were sufficiently close to intended use
(think RFC-5218 and "wildly successful").
Ok, that's my Sunday blather.
Eliot