Hi Paul,
I know this is a fairly late response, but for the record, there's
some somewhat-related discussion on key expiration and signature
expiration in [0].
FWIW, I think your interpretation is correct; in order to shorten the
expiration time of a user ID, the signature needs to be revoked first,
and a new one created.
Technically speaking, the spec doesn't guarantee that the last
self-signature (and thus key expiration date) for a key is taken,
either (though I do think most implementations behave that way), so
arguably, for shortening key expiration, a revocation should be
created too. From [1]:
```
An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent self-
signature.
```
IMO this should be a hard MUST. (...)
... which I agree with, btw.
As I said in [0], I wouldn't be opposed to a "Subject Expiration Time"
subpacket, which applies to whatever is being signed (key or user ID),
which (together with making the above a MUST) would allow you to
change the expiration time of both keys and user IDs without a
revocation, though this is probably out of scope for the current
crypto refresh charter.
Best,
Daniel Huigens
[0]: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/71#note_814223590
[1]: https://mailarchive.ietf.org/arch/msg/openpgp/F9U95U2GOcjPR9DIoF5LNc4pLAU/
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp