[openpgp] Fingerprint requirements for OpenPGP

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

Hi all--

I was hoping to see someone write up the specific use cases for the
OpenPGP fingerprint, but i haven't seen it yet, so i'm trying to do that
here.

I tend to agree with the discussion elsewhere in this thread that
"internal database ID" is *not* the defining use case for the
fingerprint, so i'm not including it here.

I think there are only two use cases:

 a) looking up a particular OpenPGP key in some remote database like a
    public keyserver
 
 b) confirming that a particular key matches some out-of-band
    communication

These are things that might happen by fingerprint transfer via any of:

 * business cards (pre-planned, printed)

 * scraps of paper (impromptu, hand-written)

 * over the telephone or other voice channels

 * copy and paste from a non-OpenPGP-specific message (chat, e-mail,
   etc)

Note that a human is always in the loop in these transfers.  If no human
is in the loop, we do not need the fingerprint, and can (and probably
should) use some other technique.

As such, i think we have these human-specific constraints:

 * the fingerprint should be identifiable as a fingerprint, including
   where it starts and where it stops.

 * it should avoid ambiguity -- readers shouldn't have to puzzle over
   whether a character is an "o" or an "O" or a "0", for example, and
   writers shouldn't have to worry about it either.

 * there should be one (and exactly one) fingerprint per key; otherwise
   comparisons become impossible.

 * it should be as close as possible to the human attention span -- this
   is Vincent's point, i think.  Humans really can't reliably deal with
   512 bits of entropy when doing any kind of data entry or comparison.

 * data entry should be easy to do with standard tools

And we have these machine-specific constraints:

 * it should be cheap to compute from a given key -- you shouldn't need
   a gig of RAM or a minute of CPU to calculate the fingerprints of any
   key.

 * it should be strong enough that we do not believe anyone can create a
   key with a fingerprint that collides with another key's fingerprint

And these spec constraints:

 * it should be easy for implementers to understand and generate

Is this problem framed correctly?

If not, what's missing?

If so, can someone try to apply it to one of the fingerprint proposals
and see what the takeaway is?

   --dkg