expiration sig preferrence incompatibility #55

tomholub · 2021-01-20T16:09:39Z

Example generated keypair:

Contrast with OpenPGP.js generated expiring keypair:

~~The PGPainless key is showing "critical" next to the expiration at https://dump.sequoia-pgp.org/~~ this is fine

~~I'll post an issue at OpenPGP.js~~ see below

The text was updated successfully, but these errors were encountered:

tomholub · 2021-01-20T16:32:34Z

~~Actually, no - this is not a bug on OpenPGP.js.~~

When changing expiration, we are adding a signature. If we leave original signature in which never expires, then adding one more signature that does expire does not make the key expire. The existing indefinitely valid signature will continue making key key valid forever.

I tried to remove the original signatures signatures from the PGPainless key using OpenPGP.js and then check expiration again - it was as expected.

It appears there are two bugs in PGPainless to address:

PGPKeyRing.validSeconds should follow whichever key expires later. Right now it will return 2999 in this situation but it should return 0, following the key that doesn't expire
when changing expiration to expire sooner then original key, cannot leave the original sig behind

For reference this is the expiring key made by PGPainless that I modified to remove the originally generated sigs - showing expiration correctly in OpenPGP.js.

tomholub · 2021-01-20T16:48:24Z

Another way to fix this (possibly easier / clearer)

add expiration directly into the generate method as per Set key expiration time during key creation #50
rename setExpirationDate to something like appendKeyExpirationSignature making it clearer what it does. This will work when extending expirations, anyway. It's uncommon to shorten it, that's what usually revocations are for.
fix PGPKeyRing.validSeconds handling

Thank you for your hard work on this and responsiveness. It's not urgent right now. Let me know your thoughts 👍

vanitasvitae · 2021-01-20T19:23:21Z

Note, that the expiration time is regarding the key, not the signature.
If a key has two signatures, one without a key expiration time and one with a key expiration time, then the signature with the greatest signature creation time wins (the signature that was made later).

I would therefore argue that PGPainless is behaving correctly when expiring a key by adding a signature. If OpenPGP.js interprets the key that was expired using PGPainless as not expiring then I'd say this is a bug in OpenPGP.js. Note that the key is correctly being interpreted as expired by GnuPG.

tomholub · 2021-01-20T19:27:56Z

Ah - that's a sublety I was not aware of. I'll check with OpenPGP.js then. Thanks for the clarification!

tomholub · 2021-01-20T19:40:04Z

Filed 👍

tomholub changed the title ~~key expiration not understood by OpenPGP.js~~ fix expiration / multiple sigs behavior Jan 20, 2021

tomholub changed the title ~~fix expiration / multiple sigs behavior~~ expiration sig preferrence incompatibility Jan 20, 2021

tomholub mentioned this issue Jan 20, 2021

choosing sigs among several with same creation time openpgpjs/openpgpjs#1197

Open

tomholub closed this as completed Jan 21, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

expiration sig preferrence incompatibility #55

expiration sig preferrence incompatibility #55

tomholub commented Jan 20, 2021 •

edited

tomholub commented Jan 20, 2021 •

edited

tomholub commented Jan 20, 2021

vanitasvitae commented Jan 20, 2021 •

edited

tomholub commented Jan 20, 2021

tomholub commented Jan 20, 2021

expiration sig preferrence incompatibility #55

expiration sig preferrence incompatibility #55

Comments

tomholub commented Jan 20, 2021 • edited

tomholub commented Jan 20, 2021 • edited

tomholub commented Jan 20, 2021

vanitasvitae commented Jan 20, 2021 • edited

tomholub commented Jan 20, 2021

tomholub commented Jan 20, 2021

tomholub commented Jan 20, 2021 •

edited

tomholub commented Jan 20, 2021 •

edited

vanitasvitae commented Jan 20, 2021 •

edited