[Sks-devel] expiration date in machine readable results
Hello, Sorry if the answer to this question is obvious. I've noticed that the search results with the mr option do not return the expiration date of a key. For example: $ curl -G -d search=kcl...@riseup.net -d op=vindex -d options=mr -d exact=on http://pool.sks-keyservers.net:11371/pks/lookup info:1:1 pub:83EB2E0A:1:4096:1249591341:: uid:K Clair kcl...@serve.com:1282001811:: uid:K Clair kcl...@riseup.net:1334289101:: uid:k clair kcl...@pickledradish.com:1334289086:: However, the key does have an expiration date, in the self signature: http://zimmermann.mayfirst.org/pks/lookup?op=vindexfingerprint=onsearch=0x06FF617083EB2E0A I've tried it with a few different keys email addresses which have keys with expiration dates, and it's not shows in the search results for any of them. Is there a reason why it's not returned in the search results? Thanks! Kristina ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] expiration date in machine readable results
On 10/18/2012 07:39 PM, Daniel Kahn Gillmor wrote: get_times in ParsePGP.ml checks the subpacket type against ssp_exptime_id, which is set to 3 (which is correct, afaict [3]). ah, looking a bit closer, i think i understand the situation here. when gpg sets the key expiration time, it does so by creating a key expiration subpacket (subpacket id 9) in the self-sig binding each User ID to the primary key. There is no signature expiration subpacket (subpacket id 3) in the self-sig which binds the User IDs to the key at all. Unfortunately, the fix is not so simple as changing ssp_exptime_id from 3 to 9, since the two subpackets' values' are measured differently. signature expiration subpackets are measured in seconds from the signature creation time, and key expiration subpackets are measured in seconds from key creation time. looking deeper at the code and the spec, it looks like we can't possibly get expiration from v4 primary key packets themselves. So it loos like sks needs to trawl all associated self-sigs (uids and direct-key sigs, but not subkey binding signatures -- and i don't think user attribute self-sigs matter for this either, since at least one uid is mandatory but one uat is not) for key expiration times, and aggregate them somehow into a maximum? something like (in pseudocode): if pub.expires is None: for each pub.uids as uid: if uid.is_not_revoked: mss = get_selfsig_with_max_creation_time(uid.selfsigs) if mss.key_expiration is not None: if pub.expires is None or pub.expires mss.key_expiration: pub.expires = mss.key_expiration for each pub.directsigs as dsig: if dsig.key_expiration is not None: if pub.expires is None or pub.expires dsig.key_expiration: pub.expires = dsig.key_expiration 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? 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 ? What if the newer direct signature has no key expiration subpacket at all? --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] expiration date in machine readable results
Daniel Kahn Gillmor wrote: I think it's doable. Compare http://keyserver.gingerbear.net/pks/lookup?search=0x83EB2E0Afingerprint=onop=index and http://keyserver.gingerbear.net/pks/lookup?search=0x83EB2E0Afingerprint=onop=vindex Presently, options=mr returns the same for either op value, index or vindex. 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 -John -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:Just how do the residents of Haiku, Hawai'i hold conversations? A:An odd melody / island voices on the winds / surplus of vowels signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
