TOFU for GnuPG

[Neal H. Walfield]

Hi,

At Tue, 03 Nov 2015 16:56:27 +0100,
Andre Heinecke wrote:
> On Tuesday 03 November 2015 16:34:39 you wrote:
> > At Tue, 03 Nov 2015 16:10:24 +0100,
> > 
> > Andre Heinecke wrote:
> > > Don't we need to lookup the new key anyway to make validity decisions?
> > > Until then we assume "Unknown" trust.
> > 
> > In the verify case, yes.  But what about the sign case?  We just see
> > that the old key has been revoked, but we don't know what the new key
> > is.
> 
> I assume you mean the encrypt case (I don't see how this affects sign)? But 
> still I don't see a problem there. If you don't have a valid key to encrypt 
> to. You need to get a different key. How is the trust model involved in that?
> 
> Once you have that new key you can do the UID / Signature checks I suggested.

You're correct, I meant the encrypt case.

Let's say you want to send an email to Alice and she has revoked her
key.  Best practice dictates that you should run something like
Parcimonie to keep your keyring up to date.  So, let's assume that
Parcimonie has also updated Alice's key.  Now, when you try to encrypt
an email to Alice, GnuPG won't let you, because the key is revoked.
The question then becomes: how do you discover her new key?  If we had
a machine readable field, as I propose, GnuPG could tell you the new
key id and even automatically fetch it for you.  If we are using
signature cross checking, then GnuPG can't help the user, because the
new key is necessarily available locally.

Note: the trust model is not relevant here.  The issue of determining
the new key is only relevant insofar as the TOFU code can suppress
spurious conflict messages if it has this information.

Thanks,

:) Neal