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? :-)