-----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" <dshaw(_at_)akamai(_dot_)com>
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-----