Client certificate expiry dates

1. colecmac (a) protonmail.com (colecmac (a) protonmail.com)

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

Link to individual message.

2. John Cowan (cowan (a) ccil.org)

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>

Link to individual message.

---

Previous Thread: TLS recommendations

Next Thread: [ANN] twins, a Gemini server written in Go