> On 8 Jan 2021, at 17:38, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Fri, Jan 08, 2021 at 11:34:44AM +0100, Olle E. Johansson wrote: > >> I am working on a project where we issue short term client TLS certs, >> with just a few days lifespan. >> >> I realized that in some protocols, like SIP, MQTT, XMPP, we have quite >> long lived client connections over connection-oriented protocols. >> During those connections, a cert may expire. >> >> I have looked, but found no advice, on how to handle that situation. >> If a SIP client authenticates with a client cert that is valid for 42 >> hours more, opens a connection that stays open for a long time, >> several lifespans… >> >> >> Another situation is that the client cert is valid, but another cert >> in the trust chain expires. The intermediate cert or the server cert >> may expire during the connection lifetime, as an example. >> >> What should the server and client do here? I imagine the connection >> should be closed when the one of the certs in the mutual chain of >> trust expires. > > No in fact in typicall applications, where certificates are *identity* > certificates, nothing should happen, certainly nothing quite as > counter-productive as closing the connection. If the identity was > valid at the start of the connection, it remains valid even after > the certificate expires. Do you delete all old signed mail from > your mailbox when the S/MIME certificate expires? > > Now if the client makes various API requests during the lifetime of the > connection, and these are subject to entitlement checks, you probably > want to make sure that stale entitlements are not cached forever. > Ok, so if I understand you right, I should focus on the validity of the cert for authentication only, not for authorization. If the authorization to perform certain tasks is withdrawn, a server may close the connection or just decide to deny any request.
I don’t think that’s very clear in many documents, but let’s aim for making it clear in the future :-) > Therefore, with *capability* certs, it may indeed make sense to require > a new client certificate after the original expires, and if that takes > a new connection, then so be it. I am not familiar with those certs, but will investigate :-) Thank you for your response! /Olle _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
