The creation date in the fingerprint is used for two purposes I can
think of:
Firstly, it is commonly used by users to pick a key when a keyserver
search returns more than one result, which is made possible without
processing the full key by integrity protecting the creation date in the
fingerprint. It is questionable whether this behavior should be
encouraged, but if there is no attacker this is often a reasonable
guess. If there is an attacker, you are doomed no matter what you do
with an unauthenticated key.
Secondly, implementations use it as a boundary for signature validity.
I don't think this behavior is actually specified, so this is mostly
just guesswork in the trust model?
Including the key material as the only dynamic part of the fingerprint
is the most basic decision. So the question becomes, do we have a good
reason to include anything more? For the creation date in particular,
are the above two properties desirable and worth it?
Just for brainstorming, the other extreme would be allowing arbitrary
properties (e.g. signature subpackets) to be included in the
fingerprint, allowing an implementation to have properties which can
never change throughout the lifetime of a key, and which cannot be
suppressed by an attacker unlike irrecovable signature packets.
- V
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp