Self-Signed certs with user date offsets

[mriise]

In order to provide overlapping valid certs, I would like to add not_before and not_after to the existing Identity::self_signed()

Is it alright for the API to change, or would adding a function and then using the existing as a wrapper for it be a better choice?

Although this is somewhat moot as one can construct their own certs to use already with a bit of extra work.

[BiagioFesta]

Once the certificate is generated it cannot be changed (as it is signed).

It would be possible to change a little bit the API and to provide a builder to generate the self-signed certificate (given thus the possibility to set the temporal validity range for it).

However, I am wondering what is the use case. The utility Identity::self_signed has a very precise scope: generate a self signed certificate which is compliant to W3C specifications.

For example:

[...] the total length of the validity period MUST NOT exceed two weeks.

Therefore, this method is very specific to generate an usable certificate for web browser to accept in WebTransport protocol.

[mriise]

The idea is to generate and publish future self-signed certificates that will be valid a week (next_notbefore = current_cert_notbefore + seven_days) after the currently used certificate was created, so that clients with stale server info (>2 weeks old) can still connect without worry of connecting mid-changeover or re-fetching the currently valid certhash.

This concept is included in the w3c spec by allowing for multiple certhashes to be passed during connect, though i suspect the original intent is for shorter overlapping cert validities.

W3C spec : [...] it also forces server operators to design systems that support and actively perform key rotation. [...]

Having rotating keys also helps prevent leaked any leaked keys from being valid for too long- even if we are self-signing.

[BiagioFesta]

I see, that's interesting; thank you