The bad thing is that merging the keys may not produce the same result,
so that each time the key would be re-requested. E.g., there are many
keys floating around that have been revoked on multiple occasions, i.e.
the merged key would need to contain multiple revocation certificates, to
provide the same checksum, which does not conform to RFC 2440.
Well this was the point of sorting the key before calculating the hash. So
long as everyone is using the same sort order for the different packets in
the key they should generate the same hash for the same key.
William,
this was said thinking about duplicate signatures or revocation certificates
or other stuff:
- Many key owners seem to revoke their keys more than once, so many
keys on different servers have different revocation certificates.
(Importing Peter Wan's keyring into my database gives some hundred of
these).
- Many users sign the same UserID more than once. The current pksd
prunes them to all but one. Currently, pksd does this by taking the one
with the newest time stamp. Other keyservers may have a different policy.
- If keyservers are put into place which really check the validity of the
revocations/signatures before either adding them or allowing them to
replace other revocations or signatures, there may be even more differences.
Unless all keyservers follow exactly the same policies and these policies
do not depend on the order in which the PGP packets are received, the
number of unresolved or unresolvable differences will increase. And I
am not really sure which policy is the "right" one.
-Marcel