Re: Identifying revoked certificates

[[e-mail]]

-----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-----