Handling a TOFU conflict

[Werner Koch]

On Wed,  7 Dec 2016 22:32, neal at walfield.org said:

> If I remove the --command-fd, then I still get the "GET_LINE
> tofu.conflict".  Only if I add --batch is it disabled.

Right, either you use --command-fd or --batch.

> As far as I can tell, whether the client uses the "GET_LINE
> tofu.conflict" or not, whether to supply the list of conflicting keys
> is orthogonal.

Yep.  But that is not how GPGME works, which is my primary concern.  If
EasyPG wants to handle this different, so be it - but changing our
interface for this is a no-go.  Adding additional status information in
case of conflicting keys is acceptable as long as we have this info
already available.  In fact we already have all status lines for this
available:

  TOFU_USER <fingerprint1> <mbox>  
  TOFU_STATS 0 ....
  TOFU_USER <fingerprint2> <mbox>  
  TOFU_STATS 0 ....

indicates that the two keys FINGERPRINT1 and FINGERPRINT2 conflict on
the address MBOX.  (The 0 is "conflict" value of that SUMMARY byte).


> Well, as far as I can tell, the TFS records and the TOFU_STATS contain
> the same information.  Your approach also doesn't exclude keys that
> are known now to conflict with the selected key (e.g., if they are
> cross signed), and doesn't deal with the aliasing issue.

I have noticed that you put code in place to detect this and thus avoid
a conflict.  What do you mean by aliasing?

> about how this is supposed to work?  Why should the TOFU
> implementation not try to detect homograph attacks?

Because that is not the duty of gpg - this is an entire different layer.
A MUA _might_ care about this but most likely it can only support the
user in detecting this.  This has nothing to do with with T0FU.

Mixing up layers is the cause of a lot of evil.

> I just tried this using the WoT and gpg doesn't handle this case
> specially:

Right, but with T0FU we are going to improve this.  Before 2.1.16 we did
not distinguish on how a key was specified.  Now a key specified by mail
address is treated different than a key specified by other means.  This
is to support our major goal of easily using the right key for a mail.
With tofu and tofu+gpg we can and should drop the old checks and
consider a key specified by fingerprint as DWIW-and-encrypt-to-this-key.
For backward compatibility we can't do this for the pgp trust model.

Thus it will eventually be possible for MUAs to avoid the use of
GPGME_ENCRYPT_ALWAYS_TRUST (--always-trust in gpg) after the keys have
been selected and passed by fingerprint to gpg.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: </pipermail/attachments/20161208/5f65852b/attachment-0001.sig>