TOFU Design

Neal H. Walfield neal at
Mon Jul 20 11:16:13 CEST 2015

Hi Robert,

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
> ignore.

This is a good point and I should have covered it explicitly in my
design document.

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
following happens:

  - 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!

:) Neal

More information about the Gnupg-devel mailing list