Neal H. Walfield
neal at walfield.org
Mon Jul 20 11:16:13 CEST 2015
Thanks for taking a look at my proposal.
At Fri, 17 Jul 2015 10:11:18 -0400,
Robert J. Hansen wrote:
> > I'd like to informally present the high-level design that I'm
> > working on for TOFU in GnuPG and some open questions. I'm interested
> > in feedback. But if all you have to say is that you think TOFU is a
> > bad idea, please restrain yourself.
> I didn't see any discussion about the use case where there are multiple
> certificates associated with an email address. There are many people
> who have such arrangements for a variety of reasons: for instance, up
> until very recently I had an RSA certificate for signing Fedora RPMs, a
> DSA2 certificate I used for most email, an RSA certificate I used for
> testing Enigmail's smartcard support, and an ECDSA certificate I used to
> test Enigmail's ECC support.
> There needs to be some consideration for the case of multiple
> certificates for a given email address. It's just too commonplace to
This is a good point and I should have covered it explicitly in my
When you say that there are multiple certificates associated with a
single email address, I think you mean multiple primary keys and not
multiple subkeys. When a message is signed using a subkey, I plan to
use the primary key for the binding. So, in this case, nothing
special needs to be done.
When there are multiple primary keys with a single email address, the
- The first time the email / key binding is seen, the user is
prompted to verify the new binding (as usual).
- When a message is verified and the email address is known, but the
key isn't, then, as I wrote in my note, we assume the user might
have a new key. In this case, we indicate this to the user as
well as some information about the old key and the new key and ask
whether to create the new binding. (I should have written all of
the old keys.)
What I didn't say in my previous note, but should have made
explicit is that the old binding is not removed. This is because
the user might still want to verify messages signed by the old
key. It might make sense to say that the new key supersedes the
old key and that any signatures made after the new key's creation
time should be marked as suspect. However, this should be an
advanced option. In the case you mention, we obviously don't want
to mark the old key being superseded by the new one.
> > Should TOFU bindings be exportable?
> Definitely not in 1.0. Get a basic system bootstrapped and running, and
> then revisit this issue.
I agree with this advice.
Thanks for your feedback!
More information about the Gnupg-devel