ietf-openpgp
[Top] [All Lists]

Re: Series of minor questions about OpenPGP 4

2009-02-01 15:21:16
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_
sigs...

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
before.


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

christoph(_dot_)anton(_dot_)mitterer(_at_)physik(_dot_)uni-muenchen(_dot_)de
mail(_at_)christoph(_dot_)anton(_dot_)mitterer(_dot_)name

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

<Prev in Thread] Current Thread [Next in Thread>