Re: [openpgp] Proposed text for V5 fingerprint

[Thijs van Dijk <[e-mail]>]

Hi Phillip,

Thanks for clearing that up.


> It would be really nice if we could all use the same format to identify a
> root of trust. But that is of course not going to happen unless we can get
> all six of the major PKI infrastructures to agree on one approach and that
> probably isn't even desirable.
>

Yes. Out of curiosity, are you currently working with any of the other five
groups to adopt a similar proposal there?
I realise that one has to be the first, and it might as well be us, but I
wouldn't want to be the one to add the n+1'th competing standard. [1]

The other reason for having the content-id in is to allow versioning within
> OpenPGP. So for example, lets say that there is a V6 key format but we
> don't want to change the digest value. We can change the OpenPGP content
> definition format as many times as we like without having to use up any of
> those scarce fingerprint version IDs.
>

Ah, so the version ID pertains to the fingerprint method only and not the
underlying key? That's good to know, and probably a good thing to document
for posterity if we choose to adopt this scheme.
In that case I'll have to lower my previous +1 on prepending a version ID.
I'd have loved to have been able to tell at a glance if a fingerprint
belongs to a v5 or a v6 key even if we keep the hash format the same, but I
see now that that isn't going to be possible without downloading the keys
in full.

Also, one other consequence of prepending a version ID to a key fingerprint
and reading the key ID from the start of the fingerprint rather than the
back is that the Public-Key Encrypted Session Key packet now only has 24
useful bits of key ID, down from 32. I don't think this will be problematic
since the probability of a collision is negligible in normal use [2], and
the opportunities for malice are very limited [3]. Furthermore, it could go
hand in hand with removing the key ID from the PKESK altogether and
defaulting to "anonymous" encryption / trial decryption - of which I would
be in favour. Nonetheless, it's something to keep in mind.


About the text, the last paragraph feels out of place. Did you add it in
anticipation of many backreferences to the term "fingerprint strengthening"
[4], or are you just describing client behaviour? In my understanding, most
operations (verifying a signature, encrypting to someone, etc. [5]) will
require one to have the full public key anyway, not just the fingerprint.
It might therefore be better served by e.g. the following:

```
Client applications MAY import a public key from an external source using
only the short 50-bit key ID as a reference. However, when checking a key's
integrity, applications SHOULD use the full fingerprint for verification.
```

Your thoughts?


-Thijs


[1]: A tale as old as time - https://xkcd.com/927/
[2]: One would need 2^12+ private keys in their keyring in order to be
affected by this (down from 2^16).
[3]: At best, an attacker could force many trial decrypts.
[4]: Or "key strengthening". Are those terms interchangeable?
[5]: In fact, any operation which isn't "select a key from my keyring" or
"download and import a key from a keyserver".