Re: [openpgp] Fingerprints

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

On Fri 2015-04-10 09:23:18 -0400, Phillip Hallam-Baker wrote:
> On Fri, Apr 10, 2015 at 7:38 AM, Stephen Farrell <[e-mail]> wrote:
>>
>> Hiya, here's the 2nd thread, starting from DKG's list.
>>
>> a) update the fingerprint format (avoid inclusion of creation date, use
>>    stronger digest algorithm; i'm dubious about embedding algorithm
>>    agility in the fingerprint itself, but explicit version info in the
>>    fingerprint might be reasonable so we don't have to keep guessing by
>>    fpr structure for future versions)
>
> I would like to get started on this bit ASAP as it is the one that has
> the most long term consequences.

I've been chewing over this discussion for a while, and i find myself
coming out fairly conservative on this.  I think i'm leaning toward
something like a 200- or 250-bit truncation of a strong digest (sha-512
is fine with me) over a common representation of just the key material
(SubjectPublicKeyInfo is fine with me, though i understand the ASN.1
concerns).  I am ok with inferring fingerprint version by structure.  I
don't much care about the difference between hex (base16) and base32 --
base32 reduces the length by 20% and it introduces some extra confusion
when communicating the fingerprint by voice.

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?


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



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?

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

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

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

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


Did i miss any factors?

    --dkg