Handling a TOFU conflict

[Andre Heinecke]

Hi,

On Wednesday 07 December 2016 15:06:11 Neal H. Walfield wrote:
> On Wed, 07 Dec 2016 11:27:09 +0100,
> Andre Heinecke wrote:
> > On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote:
> > A mua needs the E-Mail normalisation anyway to provide the argument for
> > --sender.
>
> The more important issue has to do with listing conflicting keys.
> AFAICT, there is no reason for TOFU to necessarily normalize a user id
> in a way that the rest of gpg understands.  Consider the case where we
> try to protect against homograph attacks by mapping characters with
> similar glyphs to the same symbol.  In this case, a "Cyrillic a" and a
> "latin a" might be assigned the same symbol, and asking gpg to find
> the key corresponding to the normalized email address can result in no
> keys being found.
> 
> I don't think it makes sense to expose TOFU normalization to the rest
> of gpg nevermind to external libraries or applications.  This is
> particularly the case if we want to preserve the flexibility to
> identify new conflicts in the future, which would require changing the
> mapping function.  As such, I think it is necessary for the TOFU code
> to emit the list of conflicting keys.

Ok. I could live witht his if we also add the user id that was used in a 
verification result which was the one used for verifcation, meaning the one 
that had the sign count increased and here we would need to add the 
unnormalized E-Mail. So that when I query the key (according to the fingerprint 
in the verification result) I can still figure out which UserID matches to
the verification result so that I can take the TOFU Info for that UserID for
validitiy display.

This then should be done even when TOFU is ommited so that a MUA that provided 
--sender can show a mail only as green if the verification result also contains 
a User ID and we don't need duplicated normalisation in MUA's.

--sender would then get the unnormalized Mail address from the MUA.

> If we are going to emit the conflicting keys, then we might as well
> also emit the stats, since the data is readily available.  But, I
> don't care too much about this point.

I'm a bit concerned about the API simplicity of this. I think in GPGME this 
would look like:

- Signature
 -- Key (only the fingerprint set)
 --- The Uid matched; unnormalized.
 -- List of Conflict-Fingerprints
 -- List of TofuInfo structures in sync with conflict fingerprints.

Or which I would find worse a new struct with a fingerprint and tofuInfo.

> In short: I think it is essential that we emit the set of conflicting
> keys when a conflict is encountered.

Yes if I don't have the normalisation anymore and so can't rely on the fact 
that I can find the Uid on the Key used for the verification I would indeed need 
the set of conflicting keys.

> > I currently don't think that I need information about an old key at all in
> > case of a conflict in the user interface. But that's a different
> > discussion. :-)
> I'm not sure what you mean by an old key.  If there is a conflict,
> then you need to show all of the keys, right?

Right, thinking about this more I need it if a user does not resolve a conflict 
right away. And then tries to resolve while he is looking at a mail that was 
recieved before and is signed by the old key.

Initially I thought I would resolve a conflict by a question like:

----
The key used to secure this message differs from the key usually used to secure 
messages from "foo at example.com"

Please call "foo at example.com" or your IT Support to call what happend
and check if the new key to secure your communication with him has
the fingerprint:

 1101 C077 198C 91E3 5BB9  CC78 856B 9E7E 60A1 542A

Secure communication with "foo at example.com" is no longer possible
until you have ensured that the new key is legitimate.

							[Use new key] [Keep using the old key]
----

With such a Dialog I would not need to have the conflicting keys, but
as I probably need an "Ask me later" or allow the user to delay that decision
I need indeed need the TOFU stats of the conflicting keys to show that dialog 
with the correct "old / new" keys later.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161207/42b73343/attachment.sig>