I think what the discussion of the fingerprint issue is demonstrating
is that there is actually a semantic difference between the hash
algorithm ID and the fingerprint ID.
While this does not make a difference to the bits on the wire, we
should probably maintain the distinction or else confusion will be
introduced.
It is settled practice that if you are going to sign any important
piece of data then you had better sign (Content-Type + Data) and not
just Data. Otherwise there is a substitution attack waiting. The same
principle applies to fingerprints.
With a fingerprint we have to distinguish:
1) The hash algorithm used to create a fingerprint
2) The packaging format that converts
(AlgorithmID, PublicKeyBytes) -> PackedBytes
Right now (2) is a PGP format. But it is not impossible that we would
want to switch to a different format down the road. The chief
limitation in the PGP format is that all the slots and structures are
essentially fixed. The chief benefit of JSON is that it the slots in a
structure are not fixed and unlike previous attempts (ASN.1, XML)
making use of the extension mechanism does not completely suck.
Given the way fingerprints are used, there is an intense pressure to
use a single algorithm for everything. That is why I think that we
should pick either SHA-2-512 or SHA-3-512 and truncate as necessary.
As a practical matter, I could care less about the code points people
choose. But this really is a separate registry from the hash
algorithms.
We don't need to do anything to identify legacy fingerprints because
they are a different size. But totting up all the expected needs, I
can only see the need for 3 entries in the next 20 years, maximum:
Code, Packaging, Algorithm
10, PGP, SHA-?-512
0, X.509 KeyInfo, SHA-2-512
42, JSON-y, SHA-3-512
The type 10 fingerprint would be used for all keys that have a PGP
algorithm identifier code assigned and type 0 would be used for vanity
crypto, etc.
I picked 10 for PGP because that is the code for the SHA-2-512
algorithm which I think is probably the best choice right now and 42
for some future packing because why not and 0 because that is what I
am using now.
I don't think we are likely to need code 42 for a decade. It is the
sort of thing that you do AFTER all the other structures are
converted. And even then only if you have to.
But the point is that this is a registry with 3 entries maximum. It is
not equivalent to the hash registry.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp