Re: [openpgp] Fingerprints

[Derek Atkins <[e-mail]>]

Daniel Kahn Gillmor <[e-mail]> writes:

> Here's my attempt at clarification for why i find myself in this
> position:
>
> As an exercise, i tried to write down all the places that i expect
> fingerprints to be useful.  Perhaps surprisingly, i think there are not
> that many good use cases for fingerprints.  I came up with:
>
>  0) keyserver lookup -- Finding or retrieving a key on the basis of a
>     fingerprint.  If you have hte fingerprint, you should be able to get
>     a copy of the key.
>
>  1) key verification -- I have a copy of a key that i think might be
>     yours, and i want to confirm that it's yours without a mechanized
>     byte-for-byte comparison of the entire key.  This covers the "put it
>     on a slip of paper for out-of-band confirmation" use case.
>
> Are there actually any other use cases for the fingerprint?

Specified Revokers use the (binary) full fingerprint, not the
(truncated) keyID.

> Truncated fingerprints (which we call keyids) are also used in some
> workflows, for example, by some tools to provide a human-accessible
> handle for the key.  I don't think this is appropriate, as i've argued
> elsewhere:
>
>  https://www.debian-administration.org/users/dkg/weblog/105

It's important to have a keyserver API to lookup a key based on the
keyID in a signature.

> I should also be clear: i *don't* think we want a many different
> fingerprint variants.  I actually don't think we want more than one for
> OpenPGPv5.  And i don't think we should choose a design that will
> encourage people to pick their favorite fingerprint algorithm.
>
> Fingerprints are useful because everyone uses the same one.  I don't
> want to put have to two v5 fingerprints on my business card for the same
> 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
> fingerprint on mine, and you put another, then any implementation that
> copes with them (keyservers; manual verifiers) will have to understand
> and work with them both.
>
>
> The fingerprint decisions i made came from these factors:
>
>  * version detection: how do we know that this is fingerprint format X?

Leading byte with the FPVNo.  (FingerPrint Version Number)

>  * truncation: how long is the fingerprint?  Is it acceptable to
>    truncate further?  If so, by how much?  Werner's note is also
>    relevant here as we move to ECC keys:
>
>      > Short fingerprints are important; if they are getting too long
>      > they won't serve a purpose because the public key could be used
>      > directly.
>
>    If we use a 256-bit fingerprint for a 255-bit curve25519 key, what's
>    the point?
>
>  * digest algorithm; we need preimage resistance; we do not need
>    collision resistance.

So you're saying we can stick with SHA1?  ;)

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

I still believe that the creation time (and key expiration time, if it
exists) should be included.

>  * what structure is used to frame the material before digest; v4 uses
>    an approximation of the public key packet format as a framing device,
>    but this ends up including the creation date.  we could use the ASN.1
>    SubjectPublicKeyInfo format (as phb suggests), though some people are
>    (probably understandably) allergic to ASN.1.  Or we could make up our
>    own structure, yuck!

Personally I like the current framing (because I do believe the creation
date should be included).

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

I prefer either hex or base32.

> Did i miss any factors?
>
>     --dkg

-derek
-- 
       Derek Atkins                 617-623-3745
       [e-mail]             www.ihtfp.com
       Computer and Internet Security Consultant