Algorithm Names - registry?

[Brad Wetmore]

I'm just one person, but I'm completely open to discussing on 
security-dev potential names/values to add.  I do have strong 
hesitations about just opening it up to anyone to add something (i.e. a 
wiki), allowing them to reserve names with no discussion.  (I'm thinking 
what a mess it could be if there was no IETF-IANA.)

The JDK 7 edition is at:

 
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html

The current doc does have most of the items you're suggesting, but maybe 
not as structured.  A reformatting might be helpful.

I would also hesitate including optional secondary names, as the point 
of a standard name is to settle on one name that can be used across 
implementations.  Having three possible aliases like for SHA1 (SHA-1, 
SHA1, SHA) just makes things confusing for end users.

Hadn't really thought about adding Javacard algids here.  I know outside 
Oracle this shouldn't matter, but they're a completely different group.

My $.02.

Brad




On 11/28/2011 10:30 AM, Michael StJohns wrote:
> One of the items that seems terribly out of date is the "Standard Names" list.  Also, sometimes its difficult to tell which algorithm - specifically - the name applies to.
>
> I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names.  I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list.
>
> I would suggest as data elements:
>
> Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this").
>
>
> Continuing this thought - the Javacard algorithm identifiers could also be included in this table.
>
> Mike
>