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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
