[OTR-dev] Separate Fingerprint For Each Account?

[otr at synx.us.to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Goldberg wrote:
> But IM clients (that I've seen, anyway) don't have that concept.  All
> they see are account names.  So if I've previously authenticated you as
> "Bob", and your key suddenly shows up as "alice at jabber.de", how does my
> IM client let me know that "alice at jabber.de" is really the person I
> previously knew as "Bob", and not the person I know as
> "alice at jabber.ca"?

So your problem is that the client would show it as Alice, even though
Bob had hacked her account, which is true even without OTR. With OTR in
its current state it would still show the identity as Alice, but say
that she wasn't verified since Bob could not duplicate the key for
Alice's account. With OTR in the way that I'm thinking, it would show
Bob's key as verified, for Bob's account, but if the same key showed up
on Alice's account, it would show the key was still owned by Bob, even
though it had been verified.

You claim it is unreasonable to pop up a notification like, "Bob's key
just showed up on Alice's account" when you deliver many notifications
and dialogs and warnings when the key on Alice's account is completely
unverified. I'm not saying all those warnings should disappear when
Bob's key appears on Alice's account. I'm only saying that the warnings
should inform the user that the account has been taken over by Bob,
which will usually prompt them to seek another way to contact Alice. In
its current state, all you see is an unverified key, which could be
Alice losing her key, or it could be an impersonator. With my method,
obviously Bob would be forced to use a new unverified key, since
otherwise his attempted subterfuge would be easily detected. But if
Alice changed accounts, she would not have to use a new unverified key,
since we aren't expecting anyone else's key from that account.

What I'm saying is, if Bob's key shows up on alice at jabber.de, then just
pop up a dialog saying "Bob took over this account" and then people can
use that account to speak with Bob, if they so choose. That will allow
Alice to change accounts to aliceHasBetterPassword at jabber.de, and when
she adds her buddies to that new account, since she's using the same key
it's already verified and pops up a notice saying, "This is Alice." That
provides a great utility to Alice, especially if Bob changes the
password and locks her out of the account, while providing Bob with no
utility to nefariously impersonate Alice.

Indeed if there was an account called "president at company.com" then
perhaps it would be legitimate if one verified key were replaced with
another, whenever the president of the company changed.

>  Worse, what if I already know (and have verified)
> the _real_ alice at jabber.de, and you're spoofing her account?

My idea was if you already verified alice at jabber.de, the notice that
pops up is big and dangerous and says "Bob took over Alice's account!"
whereas if you don't have any history of verifying with alice at jabber.de,
the notice is more benign saying, "Alice is now using this account" or
something.

> IM account names are like non-portable phone numbers: they're tied to
> the underlying architecture.  If we had a higher-level concept of
> identity, that would be more like modern portable phone numbers.

Which is why I'm saying that OTR should base its keys not on
non-portable phone numbers, but on a higher-level concept of identity. A
name perhaps, or some kind of record of who they claim to be. Something
not tied to the physical channel of distribution.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjWyTwACgkQB/meY5RuPPSGZgCfeR5L0XyG+JMUPsnBmvyUy1wl
Tq0AnjfiTXtYmKFzPrIx1NFtydM80n2p
=TAVf
-----END PGP SIGNATURE-----