💾 Archived View for rawtext.club › ~sloum › geminilist › 006205.gmi captured on 2024-02-05 at 11:02:26. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
mbays mbays at sdf.org
Fri Mar 26 18:54:48 GMT 2021
- - - - - - - - - - - - - - - - - - -
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.-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 195 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210326/25e598ae/attachment.sig>