Re: [openpgp] New fingerprint: to v5 or not to v5

[Daniel Kahn Gillmor <[e-mail]>]

On Mon 2015-10-05 10:16:23 -0400, ianG wrote:
> On 5/10/2015 07:33 am, Werner Koch wrote:
>> On Mon,  5 Oct 2015 12:27, [e-mail] said:
>
>> Is your request to leave the timestamp out of a v5 fingerprint
>> computation?
>
>
> Makes sense to me.
>
> Or, as it is just a calculation, the 4 octets MUST be set to 0.

<no hats>

I would agree that leaving the key creation time out of the fingerprint
calculation makes it easier to associate the mathematical object of raw
key material with an explicit key ID.

For X.509, we do have certificate fingerprints, but they turn out to not
be particularly useful.  The main place where X.509 fingerprints have
come in handy in protocols is in HPKP, where the subjectPublicKeyInfo
material is what is fingerprinted, not the certificate itself.

>> That would make some things easier but raises the issue that the owner
>> of the key can change the creation date and only the then broken key
>> signatures and the history of self-signatures would reflect this.

if the fingerprint calculation doesn't include the key creation time,
we would also need to decide whether key creation time should be
included in the material digested for other OpenPGP certifications.

in that case, i see three options:

 a) don't include any key creation time at all; signatures themselves
    have a creation time, which is sufficient.

 b) include key creation time in the material certified only for
    self-sigs (certifications issued by the key itself).  Do not include
    any key creation time in the material certified by third-parties.

 c) Include creation time of the certified key in the material certified
    for all certifications -- first-party or third-party.

I'm tempted by the simplicity of (a), to be honest.

(b) sounds doable, but i don't know how useful it is to have assertions
from the key of when the key was created, or what to do with situations
where some self-sigs assert a different key creation time than others.
Should we reject or ignore some of them?  if so, which ones?

(c) sounds like trouble -- you'll get self-signed assertions of key
creation time that don't match third-party assertions of key creation
time.  What does that mean?  how should it be represented to the user?
I think this is the issue that Werner was hinting at.

what are the downsides of (a)?  What are the advantages of having a key
creation time at all?  Is it simply that it provides a universally-known
temporal boundary when to accept signatures made by that key?

        --dkg