Subject: Re: Identifying revoked certificates

From: [email-masked]
Date: Fri, 07 Sep 2001 10:01:01 +0200

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

---

From: "Michael Young" <[email-masked]>
Date: Fri, 7 Sep 2001 18:05:01 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> userid signatures, but it is allowed in 5.2.1. 0x30)

I couldn't believe this, so I had to reread the spec, and indeed
that's what it says.  Is it really intended that a designated revoker
should be able to revoke other *certifications* (not just the key)?

[Arguably, a revoker subpacket in a certification would permit that.
We're talking about a revoker subpacket in the key self-signature here.]

Indeed, PGP6.5 does not support this.  It provides no way to generate
one, and even if it receives such a certificate revocation, it
applies only to the issuer (not keys for which it is designated).
[In fact, it isn't applied to subsequent signatures by the issuer,
suggesting that either: it is caching the validity computation
(but asking for reverification doesn't help), or it is applying
a "most recent prevails" rule.]

> revoked by designated revoker - keys self signature or
...

Indeed, this is why this is a bad idea.  I feel strongly that
a "designated revoker" subpacket should apply to only that
certificate.  Usually that's a key-only self-signature,
and a revocation on that would affect *any* other signatures
made by that key.

> why make it different for userid revocation?

Fair point... "immediately preceding" would be more consistent.
But I am willing to give up on this.