Comment 225 for bug 296867

Security issue: it isn't at all clear to me what "trust" means here. In something like GPG or SSL, the trusted assertion is "the key whose fingerprint is ...63c7cc90 is controlled by 'Simon McVittie <email address hidden>'" or "the key whose fingerprint is ... is controlled by the administrators of bugs.freedesktop.org" - it binds a key to a somewhat human-comprehensible identity (name and email address, or domain name). I would have automatically assumed that the same was true in OTR - binding a key fingerprint to a JID (or whatever else the identifier is, in non-XMPP protocols) - but that doesn't seem to be happening here. Instead, we're saying "I trust this fingerprint" but it isn't clear what property of the fingerprint we're trusting. In particular, we don't seem to be binding a fingerprint to a JID.

Concretely, suppose I talk to <email address hidden> and you present key ID 12345678 [1]. I verify out-of-band that that is really your key ID (perhaps by phoning you or receiving GPG-signed email) and mark it as trusted. Next, I talk to <email address hidden> who presents key ID fedcba98, and again, I mark it as trusted. Now Guillaume hijacks your XMPP account, and when I next try to talk to you, Guillaume presents key ID fedcba98. I have "trusted" that key, so my UI doesn't indicate that anything is wrong - but it isn't your key, it's Guillaume's!

How does OTR typically deal with this situation? Do OTR users memorize key IDs and ignore the JIDs and contact names presented by the UI, or does the Pidgin OTR plugin store pairs (JID, key ID) and warn the user if an unexpected pairing is found, or does "trust" here mean "I trust this person not to impersonate any of my other contacts"?

[1] in real life the key ID would be longer than that, but you get the idea