I know it is there in theory from the IETF end and in practice at the IANA end. I didn't see Jari advancing that as a goal in the article.
But that theory does not quite align with the current registry organization with the crypto alg registries aligned to protocols rather than being generic identifiers. And there is still an element that believes that the purpose of the IETF is to protect the Internet from the mistakes of bad wizards.
What I am doing is thinking through what it would take to make the theory a reality. Right now we have a bizarre situation where W3C takes the IETF crypto alg names, splices a URL prefix on the front and cuts a new URL.
The DANE folk just tried to define alg identifiers for their spec and found that there were four different labels defined for SHA-2, 256 bit in the IETF already.
On Sun, Jan 5, 2014 at 2:01 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Phill, that is built into clause 1 of our MoU with ICANN (RFC 2860).
I assume that when the IETF Chair writes about IANA, he's writing
about the part of IANA that we control under that MoU.
Brian
On 06/01/2014 06:36, Phillip Hallam-Baker wrote:
> One of the points that I should have made in response to Jari is that a
> major limitation in his thinking is that he sets out the function of IANA
> as an IETF support service rather than an Internet support service.
>
> The distinction is important as there is no reason that IANA should only be
> used by the IETF. The IETF is not the only Internet standards making
> organization and I hope to see many, many more. There is a natural limit to
> the size of organizations and the IETF is at that point. So are OASIS and
> W3C. We cannot attempt to scale the development of cool Internet uses by
> increasing the size of the IETF and it is counterproductive to try.
>
> If we look at the wider context, there are now communities focused on
> single applications that are roughly the size of IETF areas. The Linux
> plumbers is the size of the IETF at a similar stage in IETF growth. They
> will soon grow to about the same size.
>
>
> We can't scale organizations but we CAN scale the IANA. The function of the
> protocol registries is simply to avoid ambiguous name assignments. Why
> limit scope to just protocol?
>
>
> On Sun, Jan 5, 2014 at 3:06 AM, Patrik Fältström <paf@xxxxxxxxxx> wrote:
>
>> On 5 jan 2014, at 07:16, manning bill <bmanning@xxxxxxx> wrote:
>>
>>> Jari, you can’t be serious. unlimited means -without- limit, not just
>> the limits of your imagination.
>>
>> Bill, it was not Jari, it was Phillip Hallam-Baker that said "unlimited",
>> which I objected to.
>>
>
> And I excluded the very protocols you used as examples in your counter
> argument. So complaining about Bill mistaking attribution is a bit rich.
>
> And I said 'effectively' unlimited which means without effective limit,
> i.e. sufficiently large that there is no conceivable circumstance in which
> we would need more. So suggesting that the identifiers need to be
> infinitely long is yet another straw man.
>
> RFC822 header tags are not in fact unlimited, I can't remember the limit
> offhand but for practical purposes it is 20 bytes. But that is still enough
> space to encode a 100bit random identifier in base32 which is certainly
> 'effectively unlimited'.
>
>
> The test is whether the risk of code point exhaustion is justification for
> limiting registrations. If someone can make the argument that 'we might run
> out' then obviously the number of code points is not effectively unlimited.
>
> What I am trying to get away from here is the expectation that every
> protocol is going to have a separate registry for every item that might
> need to be identified.
>
> Shaving a few bytes should not be an excuse to create a new ongoing
> maintenance requirement for IANA and creating an extensibility nightmare
> which is what short fixed length codes do.
>
>
> Now what we could do that would achieve most goals for most people would be
> to have a single registry of text labels. Each entry would have four pieces
> of information:
>
> 1) The label itself
> 2) A unique numeric code
> 3) The purpose for which the label is defined
> 4) References
>
> So "AES" would have the entry
>
> "AES" 4242 Algorithm/Encryption FIPS-yada-yada
>
> There might then be additional information in the Algorithm/Encryption
> registry which would continue to provide additional information (e.g. the
> OID assignment, modes etc).
>
>
>
>
> Signup would be by simply entering filling out a web form, similar to the
> allocation of OID arcs.
>
>
> The advantage of this approach is that if someone wants to simply reserve a
> label to prevent a conflicting use, this is easily done. It is not even
> necessary to specify the use.
>
> The numeric codes can be used for the handful of protocols where byte
> shaving is a real concern. A new protocol using the technique would have to
> make provision for allowing 64 bit codes but it is unlikely the
> registrations would exceed a 4 byte space any time soon.
>
> Another use for the codes would be to define an OID assignment and a URI
> form of the same label. Since some codes already have OID and URI forms,
> these need to be tracked but that would be best done separately.
>
> I would do this with two registries, one for OIDs, the other for URIs which
> would list the code points that are synonyms for codes listed in the text
> label table and whether they are canonical.
>
>
> The current situation suffers from the hierarchical fallacy which is the
> mistaken belief that it is useful to separate identifiers by category. The
> prime example of this failed notion being the .com, .net and .org
> registries in DNS which do nothing but confuse.
>
> Separating the registration of encryption algorithms from other crypto
> algorithms does not help because it should be obvious that if FOO is a
> symmetric encryption algorithm identifier, it cant be a digest algorithm
> either. It is also the case but somewhat less obvious that the FOO label
> can't then be a RFC821 command or a RFC822 header either. At least not
> unless the use of FOO in the other context is completely specified and
> constrained by the symmetric encryption spec.
>
>
> If we rationalize the operation of IANA we can reduce the amount of work
> required in both the IETF space and the IANA. More importantly we can
> encourage all the other standards organizations to rely on IANA to register
> code points.
>
Website: http://hallambaker.com/