ietf
[Top] [All Lists]

Re: Working across WGs versus charter fetishes

2015-04-28 12:14:01
On Tue, Apr 28, 2015 at 1:03 PM, Viktor Dukhovni 
<ietf-dane(_at_)dukhovni(_dot_)org> 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.

<Prev in Thread] Current Thread [Next in Thread>