💾 Archived View for gemi.dev › gemini-mailing-list › 000437.gmi captured on 2023-11-04 at 12:49:01. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hello gemheads, Amfora recently got some basic client cert support, and it has me wondering: What to do about expiry dates? Should servers not care if client certs expire? Should clients and users be generating certs that last for 100 years? I'm not sure what the best practice is, but I want to get it right. It seems to me that while having an expiry date on client certs might be useful for security, it will become a UX problem a few years down the line, when apps need to have some way to associate a new cert with the same previous account. On the other hand, if a cert gets compromised and never expires, the server then needs to have some sort of revocation mechanism I guess. It seems to me the former is a more prominent issue. makeworld
On Thu, Nov 5, 2020 at 11:12 AM <colecmac at protonmail.com> wrote: > Hello gemheads, > > Amfora recently got some basic client cert support, and it has me > wondering: What to do about expiry dates? Should servers not care > if client certs expire? Should clients and users be generating > certs that last for 100 years? > That totally depends on how much the server cares about the client's identity. > It seems to me that while having an expiry date on client certs might > be useful for security, it will become a UX problem a few years down > the line, when apps need to have some way to associate a new cert with > the same previous account. > A simple approach is to send a SHA256 hash of the new cert out of band, signed with the old cert. Certificates are too big for a rainbow attack, so this is safe against everything but MITM. (In the end, MITM is unpreventable: if Alice controls all of Bob's network connections, she can make him believe anything she wants him to.) On the other hand, if a cert gets compromised and never expires, the > server then needs to have some sort of revocation mechanism I guess. > There's already a concept of Certificate Revocation Lists in X.509. Victims post their compromised certs to the list; verifiers make sure the cert presented is not on the list. See < https://searchsecurity.techtarget.com/definition/Certificate-Revocation-List> for details. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org Not to perambulate the corridors during the hours of repose in the boots of ascension. --Sign in Austrian ski-resort hotel
---