On Tue, Apr 28, 2015 at 1:03 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > On Tue, Apr 28, 2015 at 12:36:16PM -0400, Phillip Hallam-Baker wrote: > >> One of the things we seem to lack in IETF is some sort of friction >> when it comes to creating new registries. JOSE has just created a new >> set of crypto registries instead of re-using the PEM set and there are >> a half dozen other crypto registries besides. We seem to re-invent the >> MIME content-type registry repeatedly. And quite why .well-known, URI >> and SRV should be separate is a mystery to me. >> >> In general, the way to get interoperation between protocols and avoid >> silos is for people to use existing registries whenever possible. > > Sounds reasonable at first blush. Perhaps this (more generally > unnecessary "siloization") is something sponsoring ADs and the IESG > might keep an eye on? I think it is something the IAB should push for. Now I don't want to hold up the JOSE docs over this. But I do have a fix for the crypto algorithm fiasco. Basically IETF should choose exactly one mandatory algorithm for each purpose and exactly one backup. And at this point the sets are pretty obvious and undisputed: Mandatory: AES / SHA-2 / HMAC-SHA2 / RSA-2048 / DH Backup: [Blank] / SHA-3 / [Blank] / [Crfg curves here] / [Crfg curves here] These and legacy code points would be the only ones for which new entries are created. to use any other algorithm, one would have to use an OID expressed in text or binary format as appropriate. There would then be one draft per protocol explaining how to use such identifiers in that protocol if that was desired. This would kick all crypto algorithm discussions other than for mandatory/recommended status out of IETF scope permanently. Anyone who wants to can use any crypto they like but the only crypto anyone can claim IETF endorsement for is the very limited set that has been subject to IETF review.