ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Fingerprint schemes versus what to fingerprint

2016-04-07 09:56:45

On Apr 7, 2016, at 3:39 AM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:

On Wed,  6 Apr 2016 20:15, brynosaurus(_at_)gmail(_dot_)com said:

1. What fingerprint scheme(s) should OpenPGP move to going forward?

A SHA-256 hash of the artificial OpenPGP key packet as we use it right
now.  The open question is whether to 

 - include a creation timestamp,
 - a timestamp but fixed to 0 (as Google End-to-End does),
 - some other static info data to surely separate that fingerprint from
   other protocols fingerprint using the same key (i.e. token based)
 - no creation timestamp

The rationale for SHA-256 is that this is the only fast algorithm on all
platforms.

What about Blake2?  If OpenPGP will be using Argon2 for password hashing, then 
all implementations will need to have a Blake2 implementation anyway because 
Argon2 builds on Blake2.

A related question is how to identify the new fingerprint scheme in
OpenPGP objects which store a fingerprint:

 - Implicit by the length of the fingerprint,
 - or by a prefix byte with the hash algorithm,
 - or by a prefix byte with the key version number,
 - or by a prefix byte with the length of the fingerprint.

This is tricky: a further related question is how OpenPGP implementations 
decide what “kind” of fingerprint to produce, or present to the user, or expect 
to get, when doing something with a particular public key.  As many people have 
pointed out, it will be terrible for user experience if users have to start 
juggling “new-style” and “old-style” fingerprints for the same public key: 
e.g., you sent me your pub key and I want to verify it but your OpenPGP 
implementation defaulted to the new fingerprint but mine is giving me an 
old-style fingerprint to compare against.

A couple possible solutions occur:

- Define each pub key scheme as having one and only one corresponding 
fingerprint scheme.  i.e., all existing/legacy pub key schemes remain stuck 
with old SHA1 fingerprints and only new pubkeys generated under a new pub key 
scheme will get new-style fingerprints.  This would have the desirable property 
of ensuring that users never confusingly see two different legitimate 
fingerprints for the same public key - but it might mean that we never get to 
use new fingerprints with RSA/DSA key pairs etc, which may be a non-starter.

- Add a “preferred fingerprint scheme” field of some kind to the self-signed 
cert that public keys are created with, so it becomes a property like E-mail 
address etc.  Benefit: users still only ever see one fingerprint for a given 
public key, SHA1 for old public keys or SHA256 (or whatever) for newly-created 
public keys, even if the new public key uses an “old” pub key scheme like 
RSA/DSA.  Drawbacks: implementation complexity; users need to regenerate (or at 
least re-self-sign) their keys if they want to get a new-style fingerprint for 
their pre-existing public keys.


2. What exactly should the OpenPGP “application” fingerprint with that 
scheme?

To clarify, I propose to define a “fingerprint scheme” as an algorithm
that takes a raw octet string and produces an ASCII string of some

You describe how a fingerprint is presented to the user.  This has been
out of scope for OpenPGP.  Implementations have settled for a de-facto
standard outside of the protocol.  I think we should keep it this way
and at best give only a suggestion for a human readable format.

Humans are bad at comparing fingerprints; this should in general be left
to the software and additional protocols to establish a connection
between an identity and a key/fingerprint.

Although it might be good enough to rely in practice on “de facto” standards 
for fingerprint presentation, it would suck if two users with different OpenPGP 
implementations had no way at all of comparing/verifying fingerprints because 
one uses presentation X and the other uses presentation Y and there’s no common 
ground.  Wouldn’t it at least be worth recommending at least one “common” 
fingerprint presentation format be supported for cross-implementation 
verifiability, even if individual implementations might have their own 
“preferred” presentation/verification mechanism for when both users are using 
the same implementation?

B



Shalom-Salam,

  Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp