Re: [Sks-devel] expiration date in machine readable results

[Daniel Kahn Gillmor]

On 10/18/2012 09:53 PM, John Clizbe wrote:
> I think it's doable.

nice :)

> Daniel Kahn Gillmor wrote:
>> i'm a little unsure of the logic about the direct signatures.  perhaps
>> it should just select the key expiration time from the most recent
>> direct signature?
> 
> That is what it does
> 
>> If a direct signature gets made on a key at time T with a key expiration
>> subpacket of X seconds from creation, and then another direct signature
>> gets made at time T+1 with a key expiration subpacket of X-1 seconds
>> from creation, should the resulting expiration be X or X-1 ?
> 
> X-1, since it was made last. This is how a user changes expiration date/time
> 
>> What if the newer direct signature has no key expiration subpacket at all?
> 
> Then there would be no expiration time at all

I think this all makes sense, but i'm coming up against some confusing
corner cases.  What about the situation where the direct key signature
is more recent than any user ID self-sig, but their key expiration
subpackets conflict?

Consider the attached example OpenPGP certificate.

This key has one direct signature, one user ID, and one self-signature
over the uid+key.

The direct key signature was made at: 2012-10-18 22:45:02 EDT
The uid-self-signature was made at:   2012-10-18 17:44:09 EDT

So the direct sig is more recent than the uid-self-sig.

However, the uid-self-sig has a key expiration subpacket, and the direct
sig does not (it just contains a designated revoker).  What conclusion
should be drawn about the key expiration?

fwiw, this was created using standard gpg commands, and it looks like
gpg thinks that we should respect the key expiration subpacket from the
uid-self-sig.  i'm not sure what gpg would do if the direct key
signature explicitly stated a conflicting key expiration subpacket.

        --dkg

example-key.txt
Description: Text document

signature.asc
Description: OpenPGP digital signature