Hmm, maybe i am confused but let me try explain again. I think the issue here is that you must now auto-verifiy public keys that you have previously trusted on your buddy list with out any limit on the new name its bound too. This could confuse a user about who they are talking to unless you can explain the trust relationship from that last verified key. Without doing that you have the problem:
[email protected] and [email protected] are both on our user's verified buddy list. No one's key has been compromised. [email protected] registers [email protected] and talks to our user. Our user see's this this new patch account as verified because he has previously verified this public key for [email protected]. He assumes that [email protected] is the same as [email protected] because of the name association. So I think you would still need to do either a simplified verification upon contact with [email protected] to let the user know this is the same person as [email protected] or maybe just display the name used for the first confirmation and hide this information from the user. This way the public key used by [email protected] will always appear under the name they originally verified this with to the user even if he is contacting you from [email protected]. On Fri, Nov 1, 2013 at 11:47 AM, Hans-Christoph Steiner <[email protected]> wrote: > > In your example, [email protected] gets access to the secret key material, so all > bets are off there. I don't think your scenario would be any different if > each account had a separate key versus all accounts using the same key. > > .hc > > On 10/31/2013 11:25 PM, Patrick Baxter wrote: >> Forgot to add, that you could do this if you changed verification to >> be aware of a key-hierarchy so that if you verified >> [email protected] with otr key X that is signed by master identity >> M, then if patch@dukgo has otr key Y and a signature from M, its all >> OK. >> >> On Thu, Oct 31, 2013 at 8:21 PM, Patrick Baxter <[email protected]> wrote: >>> I'm assuming OTR verifies [email protected] is bound to public key X, >>> but I don't know the spec. In this case, to use the same key across >>> multiple names with the goal of reducing verification, i think you run >>> into the following problem: >>> >>> 1. You have trusted [email protected] and acquaintance called [email protected]. >>> 2. Evil user creates [email protected] with the same key from >>> [email protected]. >>> 3. You see that this key is trusted but confuse evil as patch >>> >>> One option would may to check only the username so that >>> [email protected] must be the same as [email protected]. This won't >>> work unless you can enforce that people using the same name field >>> always use the same key and are the same user which are not the >>> registration semantics of a federated system. >>> >>> On Thu, Oct 31, 2013 at 7:47 PM, Hans-Christoph Steiner >>> <[email protected]> wrote: >>>> >>>> Is there a particular reason why OTR apps generally create a new secret key >>>> for each account rather than generating a single key and using it for all >>>> accounts? Our keysync app[1] is basically is a band-aid to ameliorate the >>>> proliferation of OTR keys, so I'm curious what issues we should be thinking >>>> about as we progress. I've been thinking that the next step is that >>>> keysync >>>> should pick a single secret key and use it everywhere with the goal of >>>> making >>>> it more likely that both sides are using verified keys. >>>> >>>> [1] https://guardianproject.info/apps/keysync/ >>>> >>>> .hc >>>> >>>> -- >>>> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 >>>> _______________________________________________ >>>> OTR-dev mailing list >>>> [email protected] >>>> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > -- > PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
