[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Series of minor questions about OpenPGP 4

On Sat, 2009-01-31 at 22:36 -0500, David Shaw wrote:
> > To conclude:
> >
> > Public Key
> > 0x1F (timestamp 1)
> > 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1
> > 0x1F (timestamp 3)
> > 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3
> > 0x1F (timestamp 5)
> > UID
> > 0x13 (timestamp 1)
> > 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
> > 0x13 (timestamp 3)
> > 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3
> > 0x13 (timestamp 5)
> >
> > would work as I described in the example, and ONLY:
> > 0x1F (timestamp 5)
> > 0x13 (timestamp 5)
> > would be usable, right?
> >
> > But something like:
> > Subkey
> > 0x18 (timestamp 1)
> > 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1
> > 0x18 (timestamp 3)
> > doesn't work, and the subkey will still be revoked.

> No, because that implementation, completely in accordance with the  
> RFC, does not have to regard that user ID as valid after seeing a  
> single revocation.  An implementation is free to treat any user ID  
> with a revocation on it as permanently dead.
Oh my god :-O
Surely? I thought that the 0x30 says it only applies to _earlier_

Hmm,.. that's bad ^^ such applications should be forbidden,.. and their
programmers be imprisoned xD
Well seriously,.. that's a point.

So if an implementation doesn't behave like this,.. the above would work
(expect it behaves in some other very obscure way) and would be in
accordance with the RFC?
I just ask to see whether my understanding of the revocations and so on
is now "correct".
Or at least, the above is the way it would work in gnupg, as you've said

> I understand what you're trying to accomplish, I really do.   
> Unfortunately, the RFC doesn't give you the tools to do what you  
> want.  Luckily, the problem you're trying to solve isn't actually a  
> problem with any known implementation of OpenPGP.
Of course, the whole thing (at least from my point of view) was more a
theoretical discussion, in the sense if this would give us the tools to
handle implementations which don't follow the RFC's advice.

> If you want to generate extra revocations, go right ahead (it should  
> work fine), but understand it is not a "RFC safe" way of doing things.
Actually I don't intend to use this revocation-trick....
I've already thought about doing so, but now that you've said, an
_conforming_ implementation might treat a UID invalid forever after a
single revocation,... I'm not so sure anymore ;)

Ok,.. thanks for the enormous effort you spend on this,
Christoph Anton Mitterer
Ludwig-Maximilians-UniversitÃt MÃnchen


Attachment: smime.p7s
Description: S/MIME cryptographic signature