Re: [openpgp] Proposed text for V5 fingerprint

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 14, 2016 at 9:39 AM, Thijs van Dijk <[e-mail]>
wrote:

> 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]
>

​That is a really bad cartoon to bring up at a standards body.

The point is that we create another standard and THE OTHER ONES DIE. It
really does happen. Before SAML there were 30+ single sign on schemes in
use. Now everything supports SAML.

But in this case we are already proposing a new OpenPGP fingerprint. So
designing that so that other applications can use the same spec is no
additional cost.​

​The SMIME group has been talking about a fingerprint mode. There is no
guarantee that they will do it. BUT if they do it, they would be doing so
to converge with OpenPGP so it is logical to expect them to do the same
thing.​




> 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.
>

​The current design neither forces the version ID to stay the same nor to
change it. So that isn't a decision we need to take now.

The only thing that forces a change of VersionID is a change in digest
algorithm. Which is probably the thing that would lead to a V6 format
anyway.​


> 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.
>

​Which bits OpenPGPv5 uses for the session key can be defined separately.
Since the key must be a v5 key, there is no need for a version ID.​


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:
>

​I added it out of my usual intent to create as wide a prior art trail as
possible in developing a spec.​


```
> 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?
>


​I think we should kill fingerprints with a work factor of less than 2^92 ​
​as unsafe.​ No matter what, they just keep coming back and biting in bad
ways.