On Mon, 12 Oct 2015 14:06, look@my.amazin.horse said:
The creation date in the fingerprint is used for two purposes I can
think of:
and this one:
Thirdly, to figure out a suitable subkey for encryption. For this case
I see no security problem to put the creation date into a key-binding
signature. IT needs quite some code chnages though.
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,
I don't think so. v3 keys didn't include the timestamp in the
fingerprint but had other problems. Maybe this was just an
over-cautiousness from the PGP-5 architects. Jon: Do you remember?
Assuming we leave the timestamp out of the fingerprint but still sign it
with the self- and key-binding signatures, how does it change the attack
model:
For a key without any third party key-signatures, the holder of the key
can change the creation date arbitrarily while keeping the same
fingerprint. The immediate problem will be that keyservers and other
code may choke on the timestamp conflict because they may assume two
keys with the same fingerprint are identical. Even today keys may not
be identical because there are different ways to encode the packet
length. I doubt that this is or should be a problem which cannot be
fixed while adding v5 format. The holder of the key can change the
expiration time of the key by adjusting the creation timestamp. He is
also able to do this today by issuing a new self-signature.
If the key has a third party key-signature any change of the creation
time can be detected. If key-signatures are part of the trust model
such a change will be detected.
I conclude that leaving out the timestamp from the fingerprint
computation is only a problem for "self-signed" keys where the trust
model is based solely on the fingerprint, and relies on the creation
date. Not something I would worry about.
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
We had a similar discussion already related to a fixed expiration time.
Although this hard-wired expiration time was not considered to be part
of the fingerprint, no valid use-case for this irrevocable signature
attribute was shown.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp