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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201105/0406 e33f/attachment-0001.htm>
---
Previous in thread (1 of 2): 🗣️ colecmac (a) protonmail.com (colecmac (a) protonmail.com)