Re: [openpgp] Fingerprints

[Werner Koch <[e-mail]>]

On Fri, 17 Apr 2015 19:46, [e-mail] said:

> key to satisfy two different fingerprint camps.  the transition period
> where i need a v4 fingerprint and a v5 fingerprint is going to be bad
> enough, let's not make that persistent.  If i put one form of a v5

I do not think that this is major problem.  For many years we had to
cope with the v3 and v4 fingerprints.  It was easy to explain that they
are similar but that 4-hex-nibble fingerprint are used with modern keys
and most folks like to be modern or own modern keys.

> fingerprint on mine, and you put another, then any implementation that
> copes with them (keyservers; manual verifiers) will have to understand

Right, that is not going to work.  It is worse enough that there is no
fingerprint standard for X.509 and we need to avoid it.  I understood
the proposal as to define a common fingerprint format which can be
re-used for a v6 key format.  The number of different ways to render a
string of hex digits is limited.

>  * truncation: how long is the fingerprint?  Is it acceptable to
>    truncate further?  If so, by how much?  Werner's note is also
[...]
>    If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's
>    the point?

BTW, there is another option: We could demand a specific subkey
(e.g. 256 bit ECDSA) which directly acts as the fingerprint.  This
fingerprint-key could then also be used for forthcoming distributed
naming systems.

>  * digest algorithm; we need preimage resistance; we do not need
>    collision resistance.

Thus SHA-256 should be sufficient.

>  * what material gets digested; at a minmum, this is:
>     - the algorithm for the key (incl. any parameters)
>     - public key values (mpi's, bitstrings)
>       it's not clear to me that there is any advantage to adding
>       anything else here.

It has been discussed that a hard expiration date would be useful.

Having a creation date as part of the key allows to create a key from
the same key material but still be identified as a different key.  This
is for example useful if the key material is on a smartcard and you want
(e.g. due to company policy) two independent looking keys.

>  * human-representable form of the digest: e.g. hex, base32, common
>    hyphenation patterns, etc.  there are legibility/usability factors
>    here that i don't know enough to comment on.

For a long time I pondered with the idea to suggest base32 for a v5 key
but meanwhile I think that hex digits are easier to read and spell over
noisy channels. 

 08-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0-12345678-9abcdef0

would fit into one line and is still not too hard to read.



Shalom-Salam,

   Werner

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