On 3/01/13 19:17 PM, Jon Callas wrote:
The proposal that we had a long time ago which was essentially prefix a hash
with an algorithm number was a good one. I remember everyone thinking it was a
good idea and no one belling the cat. I vaguely remember someone writing up an
I-D on it, too.
That's the way I'd go, as it's future-proofed.
If we have to have hash agility, I agree that's a good way to do it.
Alternatively we can do OIDs in which case we will generate arguments,
external dependencies and work for ourselves for generations -- over on
another list some were arguing recently about whether Taiwan was allowed
to use this OID or that OID for their root key, Taiwan being one of
those not-a-countries, and everyone arguing being not-those-authorities.
Hence my earlier question - has anyone allocated the OpenPGP numbers for
Keccak as yet? The reason I asked is because I stumbled on the code
last week and thought what a fine idea it would be to at least prepare
the way.... Strawman?
SHA3-224 4 12
SHA3-256 5 13
SHA3-384 6 14
SHA3-512 7 15
Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there
any spots already allocated?
Another question, back on the fingerprints. If we end up doing a
hash-agile fingerprint, how does the algorithm number get laid out by
the users on their business cards?
E.g., can we agree on a one byte number, values 0 to 7F, with leading
bit reserved for future escape valve?
Then, if it is to be written out, this would mean a "new-style
fingerprint" is always an odd number of bytes. Could we agree on a
stylistic convention? Something like:
7F-- AB01 CD23 EF45 ...
Just thinking aloud. Are there any other practical ramifications of
going to an agile fingerprint?
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp