On Thu, 6 Sep 2001 14:33:10 -0700, Jon Callas said:
Now then, a question for implementors: If this gets put in, would you
implement it? "Yes, but not right away" is a fine answer, as are "Yes" and
No.
I don't see a reason for the revocation target specifiers. The only
sound handling of self-signature revocations (and that's what we are
talking about) is to use the latest valid self-signature, be it a
revocation or a real self-signature. All other ways makes the
protocol more complex and ambiguous and is error prone. Checking the
timestamps of valid revocations and self-signatures is sufficient in
about all cases. There are only 2 problems I can identify with this:
* 2 signatures done in the same second.
Solution: Don't do this and if you receive one, choose one of them
by whatever means.
* Sequence of packets messed up.
This should not happen, but if it does there is the same chance that
the UIDs or subkeys and their self-signatures are out of order and so
one would need to specify the UID in the self-signature. Solution:
Either drop these packets because they don't comply to OpenPGP or
reorder them which might take a couple milliseconds. From experience
I know that the reordering is only rarely needed and in most cases due
to buggy keyserver implementations.
Werner
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus