[openpgp] Fingerprints

["Neal H. Walfield" <[e-mail]>]

Hi,

The crypto-refresh defines fingerprints as follows:

> 5.5.4.  Key IDs and Fingerprints
>
>    A v5 fingerprint is the 256-bit SHA2-256 hash of...

draft-koch defines fingerprints as follows:

> 12.2.  Key IDs and Fingerprints
>
>    A V5 fingerprint is the 256-bit SHA2-256 hash of...

Historically, it has been possible to use the length of the
fingerprint to derive the version.  If draft-koch is deployed, and the
crypto-refresh does s/v5/v6/, then this will no longer be possible.


I'm concerned about this, because it makes the programmatic use of
fingerprints more difficult.  Note: I'm not actually worried about
collisions here.  I'm thinking primarily about implementation
complexity, and how to apriori avoid bugs.

Consider.  In Sequoia, we have a Fingerprint data structure.  It may
eventually look something like this:

  enum Fingerprint {
      V4([u8; 20]),
      V5([u8; 32]),
      V6([u8; 32]),
      Invalid(Box<[u8]>),
  }

This data structure implements equality, i.e., it implements the ==
operator, and hash, so that it can be used as a key in a hash table.

Let's imagine that we have a collection of certificates stored in a
hash table.  If a program using Sequoia is handed a fingerprint (FPR)
without a version, perhaps a user copied and pasted it, then it either
can't use the Fingerprint data structure as the key and needs a second
data structure, perhaps, UnversionedFingerprint, or it needs to first
try looking up Fingerprint::V5(FPR) and then try looking up
Fingerprint::V6(FPR).

To be clear: I'm not claiming that this is a showstopper, or that the
complexity is unmanageable.  I'm just saying that it increases
implementation complexity without any other gains, i.e., its a bad
tradeoff.


I see two solutions:

First, we could use a different fingerprint length from draft-koch.
That's straightforward, but potentially changes the security calculus,
e.g., if we use a truncated SHA2-256 hash.  That's annoying.

Second, we could just make the version number part of the fingerprint.
That is, the fingerprint could be defined as the concatenation of 6
(assuming we do s/v5/v6/) plus the 256-bit SHA2-256 hash.

This works nicely as, as far as I can see, whenever crypto-refresh
specifies a fingerprint, the version is also specified.  So, all of
the data structures like the Issuer Fingerprint subpacket can be
redefined without changing the wire format.  And an implementation
would never be tempted to accept a fingerprint without a version, as
the version is by definition part of the fingerprint.

Thoughts?

Neal