On Apr 15, 2015, at 4:04 PM, Christoph Anton Mitterer
<calestyo(_at_)scientia(_dot_)net> wrote:
On Wed, 2015-04-15 at 12:11 -0700, Jon Callas wrote:
There was a proposal that floated around that defined an extended
fingerprint to be an algorithm number followed by the actual bits.
For example, ASCII-fied 23:ABCDEF0123...FF. There's an obvious binary
representation. There's an obvious way to truncate that as well --
just decide if you truncate little-endian or big. (Personally, despite
being a little-endian bigot, this is a place where network byte order
is even to me the obvious win.)
The major advantage of this is that you can define it and then you
never have to change it again. We don't have to have any arguments
over what hash function is proper to use, etc. An implementation can
decide to support or not support whatever.
+1
But shouldn't one define better the number to be either a string?
Sure a one byte number with 255 possible future algorithms seem plenty
enough, but people also once thought that about 32bit IPv4 addresses,
two digit year numbers and so on.
Using a string is fine, but even with numbers, there is no rule that the number
has to be a single byte. After enough years and algorithms added, it could be
"100000:ABCDEF0123..."
Whether it's a string or number, there has to be a list for what number/string
means what algorithm. Once you have a list, it doesn't really matter if it's a
string or a number.
David
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp