Daniel Kahn Gillmor <dkg(_at_)fifthhorseman(_dot_)net> 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
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp