-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
On Thu, Sep 06, 2001 at 12:06:49PM -0700, Jon Callas wrote:
Is it worth adding the timestamp from the original signature to help
find it without having to look at the (larger) hashes? On a uid with
many signatures, this could speed things up. Once found, of course,
the hash could then be checked for confirmation.
I don't mind having the timestamp there, but I don't feel a need for
it, either. While I feel a need for this subpacket, at the same time,
I expect this situation to be rare, and there are other ways to
control the cost:
Note that this disambiguation is necessary only for signatures within
the same context (key, key/user, key/subkey) and made by the *same
creator*.
do not forget that sigs can be revoked not only by the *same creator*,
but also by *designated revoker*.
(AFAIK currently no PGP implementation supports designated revokers for
userid signatures, but it is allowed in 5.2.1. 0x30)
btw currently there is not possible to know what is
revoked by designated revoker - keys self signature or
revokers signature if there is one.
for example:
key A have signed by A (self sig) and B,
in self sig B is specified as designated revoker.
now if B revokes his signature, but currently it looks exactly like
he have revoked A's self signature.
Although the current packet ordering rules don't address certificate
revocation, I'd suggest that a prudent ordering would put each after
its target.
11.1. says that key and subkey revocation is *before* signatures.
why make it different for userid revocation?
== <EOF> ==
Disastry
http://i.am/disastry/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1
iQA/AwUBO5hiZjBaTVEuJQxkEQM2ywCcDUR8Ru7Zj12mHGGyZH7Kcdi8XqUAmwVx
SyqrvY8wYoDZOyiyFItJ+RZT
=2jSN
-----END PGP SIGNATURE-----