On Apr 6, 2016, at 12:20 PM, Bryan Ford <brynosaurus(_at_)gmail(_dot_)com>
wrote:
* PGP - S/MIME Signed by an unverified key: 04/06/2016 at 12:20:08 PM
Getting back to DKG’s question of whether the Unix creation-timestamp should
be included in the octet-stream passed to a (future) OpenPGP fingerprint
scheme… I want to generalize the question into a choice between three
options:
1. The fingerprint covers *only* the public-key material itself, in a
verifiably and enforceably canonical form.
2. The fingerprint covers the public-key material and some other fixed-format
stuff like version info and Unix timestamp, as in rfc4880.
3. The fingerprint covers the public-key material and some extensible
variable-length information, e.g., parameters the key-holder specifies in its
self-signed cert at key creation time.
I've gone back and forth on this over the years. I finally ended up with #2 (or
#3) being right enough.
If you do #1, then you make it so that you can't use the same key for multiple
purposes. You can't for example use it for aliases and nyms. I think #1 is a
bad idea because it tends to turn the fingerprint into a tracking identifier
and I think that making your crypto be implicitly tracking-friendly is a bad
idea.
So let's talk about #2 and #3 as somewhere on a continuum of saying that the
fingerprint is a computable database identifier that provides some onewayness
from key to fingerprint.
The way OpenPGP presently does it is kinda meh. It achieves the goal that
knowing a fingerprint can find a key, but is merely onto, not one-to-one. It
is, however, the way that it is.
If you change it, you end up with unknown breakage. I also don't see a *goal*.
What problem are you trying to solve? I recognize that creating a new
fingerprint algorithm provides an opportunity, but I have to ask why.
If you specify extra data to be thrown in, it gives the future more places to
attack fingerprints in clever ways. Whatever algorithm you pick, it ought to be
simple. I can see perhaps that you might want to put some "salt" into it, but
if you do, it ought to be relatively small, and if it is variable-length, you
need to add in the length as well.
However, despite not being able to say a lot of good things about #2 (the
existing one), it is the existing one. Arguably one should keep it unless
there's stated goodness to be had.
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp