[OTR-users] Feature request- Revoke identity

[Ian Goldberg]

On Fri, Nov 18, 2005 at 08:06:37AM +0100, Paul Wouters wrote:
> On Thu, 17 Nov 2005, Gregory Maxwell wrote:
> 
> > someone with this new identity it will provide them with proof it knew
> > the old identity's private key. The old identity is then marked in
> > their list as revoked and the software should refuse to communicate
> > over it, even if they have not yet verified the new identity (if an
> > attacker has my key I couldn't be more pleased if he went around using
> > it to revoke it rather than using it to impersonate me!)
> 
> Uhm, couldn't the attacker do the same with with the stolen key, and
> inject new false identities to your buddies too?

But the *new* key wouldn't be trusted.  The only way to trust a key (at
the moment) is to indicate that you've manually verified it.  This is a
mechanism only to automatically *untrust* keys.  [And it's a little
stronger than the "untrust" we've got now, which just marks the key as
unverified; it will actually mark it as explicitly untrusted, and refuse
to use it.]

> I'd prefer using OTR identities in GPG (sub)keys. There you can do all the
> revoke/sign/trust relationships already. We just need to bind those to OTR
> identities (with a special (sub)key combing my GPG entity with my OTR keys
> and IM identities).
> 
> This was discussed before a few weeks back, but the developers were eerily
> quiet and probably don't want to be known as "the people who put all those
> keys in the PGP keyservers".

Actually, I thought it was at least a semi-plausible idea that bears
further looking at.  But not just right at this moment.  You did catch
the major tricky bit that most people miss: they say "I want to use my
existing GPG key to sign my OTR key and have it checked automatically!"
but they neglect to realize that you need some way to know that the GPG
key for <ian at cypherpunks.ca> is allowed to sign for the AIM ID otr4ian.
You correctly point out that you should add a subkey to your GPG key
with some automatically parsable ID like <AIM:otr4ian> or something like
that.

Howver, one of the big downsides of relying on GPG for the
revocation/etc.  behaviour is that (approximately) no one understands
how to use it.  OTR is supposed to be usable for anyone that can use,
say, gaim.  If it's not, that's a potential bug that needs to be fixed,
keeping in mind that we need to maintain appropriate security.

I'm all for "reducing it to a previously solved problem", as the
mathematicians are wont to say.  But I don't think that GPG revocation
certs are a previously solved problem.

   - Ian