On Jan 31, 2009, at 8:18 PM, Christoph Anton Mitterer wrote:
On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote:
The point I was trying to make is a little different. The RFC
specifies a (RECOMMENDed) way to handle this problem, so that the
extra revocations are not needed for any implementation that is
compliant with that advice.
Ok,.. in that case (if an implementation follows that advice, we don't
have to talk, as you're right and everything is fine :-)
This method with extra revocations is an
attempt to force non-compliant implementations into doing the right
thing. I suspect this may be tilting at windmills. These
implementations are already disregarding the RFC advice. It is
difficult to use RFC advice to get a non-RFC advice following
implementation to do the right thing.
Ok I got your point,.. and the following is probably a little bit
pedantic and quibbling. The point I was trying to make is:
As this "use the most recent" is "only" a RECOMMENDS, an
implementation
might not follow this advice, and would be still conforming, right?
As you've said, it's only an advice.
We cannot do anything about really-non-conforming implementations (the
ones that breaks the MUSTs and so on), so lets forget about them.
But the just plain (very) stupid ones which are compliant (and thus
would follow the revocations of the previous self-sigs, as Peter
suggested) but don't follow that advice/recommendation would break and
possibly do bad things.
And this could be avoided by following Peters ideas.
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.
Is this correct so far, and something we can agree on? :-)
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.
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.
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.
David