[tech] client certificate expiry

1. mbays (mbays (a) sdf.org)

Does it make sense to give a self-signed client certificate an expiration 
date? I think not, and therefore according to RFC5280 section 4.1.2.5, 
notAfter should be set to 9999-12-31 23:59.
=> https://tools.ietf.org/html/rfc5280#section-4.1.2.5

The same goes for self-signed server certificates, but I mention this in 
the context of client certs because the notAfter time gives a way to 
fingerprint clients. So it would be good for clients which generate client 
certs to agree on this.

Link to individual message.

2. almaember (almaember (a) disroot.org)

On Thu, 25 Mar 2021 23:44:59 +0100
mbays <mbays@sdf.org> wrote:

> Does it make sense to give a self-signed client certificate an 
> expiration date? I think not, and therefore according to RFC5280
> section 4.1.2.5, notAfter should be set to 9999-12-31 23:59.
> => https://tools.ietf.org/html/rfc5280#section-4.1.2.5

To me, it seems that certain clients (I haven't used all of them) allow
the user to select an expiration date when generating the certificate.
In my opinion, this is the best approach. But clients should default to
never-expiring certifications.

> The same goes for self-signed server certificates, but I mention this
> in the context of client certs because the notAfter time gives a way
> to fingerprint clients. So it would be good for clients which
> generate client certs to agree on this.

That fingerprinting would be highly ineffective (can only detect the
client used), and is nothing in comparison to the most important
privacy risk right now, which is your IP.

~almaember

Link to individual message.

3. mbays (mbays (a) sdf.org)



> On Thu, 25 Mar 2021 23:44:59 +0100 mbays <mbays@sdf.org> wrote:
> 
>> Does it make sense to give a self-signed client certificate an
>> expiration date? I think not, and therefore according to RFC5280
>> section 4.1.2.5, notAfter should be set to 9999-12-31 23:59.
>> => https://tools.ietf.org/html/rfc5280#section-4.1.2.5
> 
> To me, it seems that certain clients (I haven't used all of them) allow
> the user to select an expiration date when generating the certificate.
> In my opinion, this is the best approach.

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.

>> notAfter time gives a way to fingerprint clients.
> That fingerprinting would be highly ineffective (can only detect the
> client used), and is nothing in comparison to the most important
> privacy risk right now, which is your IP.

Sure, but I don't think that means it isn't worth dealing with.

Link to individual message.

4. Stephane Bortzmeyer (stephane (a) sources.org)

On Fri, Mar 26, 2021 at 07:54:48PM +0100,
 mbays <mbays@sdf.org> wrote 
 a message of 43 lines which said:

> 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.

Link to individual message.

5. mbays (mbays (a) sdf.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.

Link to individual message.

---

Previous Thread: [tech] Environment variables for proxies

Next Thread: .onion capsules?