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? :-)
I don't want to judge whether this is really necessary for the real
world, as probably most sane implementations follow the advice, to use
the most recent only, and thus the sig+sig+revoc thingy will work.
(Of course for all of this, a working key server infrastructure is
needed)
Personally I'd prefer that a future version of the RFC really enforces
that advice, in order to be 100% sure, that in every conforming
application, the sig1+sig2+revoc example or sig1+sig2 example works as
expected.
I think for these kind of attacks, revoking the old self-sigs wouldn't
help anything, would it?
Because an attacker could always strip of newer self-signatures and
revocation signatures as he likes, and thus users and actually the
whole
OpenPGP-PKI really _RELY_ on functional keyservers the distribute the
complete and up-to-date version of the key.
Exactly right.
Excellent :-)
Good night (at least in my time zone ;) ),
--
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
smime.p7s
Description: S/MIME cryptographic signature