You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A subkey signature packet can have two expiration times:
expiry of the signature (subpacket type 3), and
expiry of the key that is signed (subpacket type 9).
It appears that only the type 3 subpacket is parsed and used to calculate the attributes raw_expiration_time and expiration_time and subpacket type 9 is not parsed.
The key expiration time is also important. It would be good to have raw_key_expiration_time and key_expiration_time attributes. But ...
There would be a complication in calculating these in that subpacket 9 encodes the expiry as "number of seconds after key creation time" instead of an actual date, and the key creation time is not stored in the signature packet. To avoid problems (e.g. key creation time can't be found in the subkey packet) it would probably be best to instead expose the subpacket 9 value in an attribute called key_lifetime_s and leave any further calculations to the user.
Would the developers welcome a PR to implement that?
The text was updated successfully, but these errors were encountered:
A subkey signature packet can have two expiration times:
It appears that only the type 3 subpacket is parsed and used to calculate the attributes
raw_expiration_time
andexpiration_time
and subpacket type 9 is not parsed.The key expiration time is also important. It would be good to have
raw_key_expiration_time
andkey_expiration_time
attributes. But ...There would be a complication in calculating these in that subpacket 9 encodes the expiry as "number of seconds after key creation time" instead of an actual date, and the key creation time is not stored in the signature packet. To avoid problems (e.g. key creation time can't be found in the subkey packet) it would probably be best to instead expose the subpacket 9 value in an attribute called
key_lifetime_s
and leave any further calculations to the user.Would the developers welcome a PR to implement that?
The text was updated successfully, but these errors were encountered: