💾 Archived View for rawtext.club › ~sloum › geminilist › 006193.gmi captured on 2023-11-14 at 09:32:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
almaember almaember at disroot.org
Thu Mar 25 22:59:15 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Thu, 25 Mar 2021 23:44:59 +0100mbays <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) allowthe user to select an expiration date when generating the certificate.In my opinion, this is the best approach. But clients should default tonever-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 theclient used), and is nothing in comparison to the most importantprivacy risk right now, which is your IP.
~almaember