Re: Identifying revoked certificates

["Michael Young" <[e-mail]>]

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

On Thu, Sep 06, 2001 at 12:06:49PM -0700, Jon Callas wrote:
> A signature subpacket called "revocation target" that contains a 1-octet
> PKalg, a 1-octet hash algorithm, and then a hash body. It denotes that a
> revocation signature is intended to revoke the signature so specified.

Sounds good.  I didn't have the PK algorithm in my original proposal.
I don't feel a need for it, but I don't mind having it there, either.

From: "David Shaw" <[e-mail]>
> 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*.

  Although the current packet ordering rules don't address certificate
  revocation, I'd suggest that a prudent ordering would put each after
  its target.  This would an even stronger hint.  I note that neither
  PGP6.5 nor GnuPG produces this ordering.  At first glance, it appears
  that they use order of arrival.  [Just the same, would anyone object
  to suggesting this ordering in section 10?]

  I expect many implementations will cache certificate verifications and
  revocation results upon receipt/incorporation, rather than doing them
  every time.

  An implementation that doesn't cache will have to compute the hash
  before using the PK algorithm to verify the original anyway.  Since
  the PK verification is (relatively) expensive, it makes sense to look
  for any revocations first.  A failing 20ish-byte hash match won't take
  longer than an (unaligned big-endian) 4-byte time match (and may fall
  out sooner); a successful match would require the 20ish-byte test anyway.
  If there's a match, the revocation certificate gets tested instead
  (and, assuming it verifies, the original verification can be skipped).

But as I said up front, I don't object strongly to having it.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5flQGNDnIII+QUHAQGuMwf9EIRKx/gEJ5PV2hySzvBJV/2nrGie3ZQN
oNpbE0Gze/rgOZEHjviajeOTcKrCnzNk4JMeiWYT2FiWsNwXHKj/Qkbnifsl8f17
aJ6RBoUTlwjhjiiOJVFC14A0Vy3PWTBLpQ2tCJSd02D5Yvtc5L+SHOez6iwVh1/j
hKv4hQUqCJbfjBH6E5o8BncsZTR4if+zlgrm24IXymr4f83yqCxoOYC+EyhZnANn
9oEzAE7WJiKYznt/wL3THXzZRDPgefVeGH6turU+LMDS7p02gsiWrHGjKU3l/3I5
QvlFsc9KKpahtJGuaq/VymBmfxw1kX/vH2GIWb8QGwMxHXbS60YJRg==
=e/dy
-----END PGP SIGNATURE-----