Open AndersAbel opened 3 months ago
I don't know if I agree. For example, DP keys can use an X509 cert and the expiration time there is never inspected (or honored).
Perhaps we should not set an expiration at all (if that's even possible)?
DP keys are never exposed in a discovery/metadata doc so they can just decide that they will internally ignore the expiry time. For us, the certificate becomes part of the public contract/communication.
As far as I can tell the not before and not after values are mandatory to supply.
But once the cert is created (w/ an expiration), then you can't change it, right?
When we create an
X509Certificate2
to wrap our keys whenUseX509Certificate
is set totrue
, we use the configured expiry lifetime of the keys as the certificate's expiry time.If the key lifetime (rotation interval) is then increased that will let the current keys live for longer. However, the expiry time captured in the certificate will now not be honoured. We will continue to the use the key beyond that time, which is confusing.
The JWK spec does not mention the expiry time. It does however state that
If all information in the certificate should be consistent with they key data and usage, then we should not continue using a certificate beyond it's lifetime. Updating the certificate when the lifetime changes is non-trivial; the certificates would not be the same and that could cause issues with key lookup.
This is an edge case, but the right thing to do would probably be to take the X5C expiry time into consideration when deciding when to create a new key.