💾 Archived View for gemi.dev › gemini-mailing-list › 000834.gmi captured on 2023-11-04 at 13:08:36. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

-=-=-=-=-=-=-

[tech] client certificate expiry

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.

almaember <almaember (a) disroot.org>

On Thu, 25 Mar 2021 23:44:59 +0100
mbays <mbays at 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.

mbays <mbays (a) sdf.org>



>On Thu, 25 Mar 2021 23:44:59 +0100 mbays <mbays at 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.

Stephane Bortzmeyer <stephane (a) sources.org>

On Fri, Mar 26, 2021 at 07:54:48PM +0100,
 mbays <mbays at 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.

mbays <mbays (a) sdf.org>



>On Fri, Mar 26, 2021 at 07:54:48PM +0100,
> mbays <mbays at 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?