Hi Jon, thanks for the comments.
On Apr 6, 2016, at 7:37 PM, Jon Callas <jon(_at_)callas(_dot_)org> wrote:
On Apr 6, 2016, at 12:20 PM, Bryan Ford <brynosaurus(_at_)gmail(_dot_)com
<mailto: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.
That’s a really good point - I definitely agree with the desirability of making
fingerprints less useful as tracking identifiers. On the other hand, one might
argue that there are other ways to address this, e.g., by just having separate
keys (or subkeys?) representing nyms. If you *really* want your nyms to be
unlinkable to each other it doesn’t seem avoidable that they’ll need to be
based on separate keys and not just different fingerprints for the same key.
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.
Agreed, and this consideration definitely seems to argue for a strict 1-to-1
fingerprint-to-key relationship.
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.
There’s nothing wrong with keeping the existing format as a legacy thing, but
if we’re not actually going to do anything with the timestamp - and clearly we
can’t trust it for anything anyway - I’d be in favor of either eliminating it
or just fixing it to 0 as Werner mentioned Google End-to-End does.
B
Jon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp