-----BEGIN PGP SIGNED MESSAGE-----
I came upon a simpler idea: include the original *hash* in a
subpacket. After noting that neither PGP6.5 nor GnuPG puts the
original creation time in its revocation packets, I looked
for a way to achieve backward-compatibility. Putting the
whole original packet in the new one would work, but it's
too large. But the original hash should be sufficiently precise
(much better than just the original creation time).
Specifically, I suggest adding another signature subpacket:
5.2.3.1. (add:)
31 = revocation identification
5.2.3.25. Revocation identification
(1 octet hash algorithm)
(N octets hash)
In revocation certificate, the hash value computed in the
original certificate being revoked. This SHOULD appear
in the hashed portion of the revocation certificate.
This would appear to solve a variety of problems for v4 certificates.
Existing implementations, which won't have the logic to verify
them, should ignore it (unless a sender chooses to mark it critical,
which seems like a bad choice). New implementations can identify
the original certificate precisely. It's a little larger than
just the timestamp, but not that much.
There is no analog for v3 certificates, but then there's nothing
interesting that can be updated in a v3 certificate anyway
(just the certificate creation time). If anyone *really* wants
to do that, I'm happy to require that they use a v4 revocation
or hope that the receiver applies a "most recent prevails" model.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQEVAwUBO41HHWNDnIII+QUHAQFh8gf8CAcE070mOyHQtqddn0qH68y193Yg/xNj
VZ4Zjxztk/IrXL5TRSrgAMDajHcG8fnctc/tWUDJKG/yXDjJQ6TVhzHfCUb7px8m
guexyYsylBhBRIySJr6x14OkHtK6CTjt9VSIXD33UzbNxDWHIBpVGG/E+BbM5GWp
Mz9kdZOYyIhZHTKqZublVg9zNsNQsKWeqr99iRm6gRWVsqn2kMS08Km81YQpPU5C
6aHJFtffJsfIgbNLAn9qhP2NH2UYSzJ0PXfVGapg9IC560xAjgzQX6I3h4yuD5N2
27CI47CT2VzkuCQbU3m2rDgm2s9t8dD98YdSvNH8Qv7mw2vmSQp2nA==
=SOHN
-----END PGP SIGNATURE-----