[tech] client certificate expiry

mbays mbays at sdf.org
Sun Mar 28 15:25:49 BST 2021
* Saturday, 2021-03-27 at 10:23 +0100 - Stephane Bortzmeyer <stephane@sources.org>:

> On Fri, Mar 26, 2021 at 07:54:48PM +0100,
> mbays <mbays@sdf.org> wrote
>> Under what circumstances would it make sense to set an expiration
>> date? What does it indicate? RFC5280 says "The certificate validity
>> period is the time interval during which the CA warrants that it
>> will maintain information about the status of the
>> certificate.". With a self-signed certificate there's no CA, so this
>> seems to be meaningless.
>
> Without an expiration date, any compromission of the private key lasts
> forever. Expiration dates are also here to prevent the thief from
> using the certficate infinitely.

Right, I suppose this is actually still meaningful with TOFU -- the validity period is the time in which the certificate claims that it represents the same identity it did on first use.

That could make sense if you're linking the certificate to an existing identity, e.g. an email address, or an astrobotany account. But when a new certificate creates a new pseudonymous identity, which is often the case currently in gemspace, I can't imagine wanting to give it a limited lifespan. If there's no way to rotate the certificate, that means choosing the day the identity will die on the day it's born. If there is, it still means the identity will permanently die if you neglect to rotate in time, which is pretty harsh.

Revised version then: if you're writing a client which generates client certificates, and *if* you plan not to set a proper end validity, then rather than use something arbitrary like 100 years from creation, consider using the value given in rfc5280.


Archive home | About this archive