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