Hi Ref
'Expiry: for the server/client. I suspect this is mostly a 'don't care', except in the case where a certificate *should* be revoked after it is expired (nobody does that, right?). Is this worth addressing? I suspect not.' I would imagine that the implementation would pull the session down once the certificate expires, so the session only lasts for the lifetime of the certificate. I know that some IPsec implementation does this. cheers On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley <debcool...@gmail.com> wrote: > So we can break this down into 2 categories: > > expiry > revocation > > for both clients and servers. > > Expiry: for the server/client. I suspect this is mostly a 'don't care', > except in the case where a certificate *should* be revoked after it is > expired (nobody does that, right?). Is this worth addressing? I suspect > not. > > Revocation: The RP* can check this whenever it desires. If one has > designed a long lived connection, then the RP needs to handle it. Does > TLS, the protocol need to handle it? Don't know. > > Short lived certificates: I think these are a good idea. And if one does > this, rekey/renewal early and often is the way to prevent breakage. > IMHO.... > > > > > On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett <graham.i...@gmail.com> > wrote: > >> Hi >> >> I have a fair amount of hands on experience with IPsec VPNs, and many >> organisations look to use TLS in a similar manner. >> >> To give you an example of where you might look to perform a regular >> revocation check on long lived connections; >> >> Solution with many remote devices (think remote access, so phones, >> laptops, IoT devices etc) >> A remote device is compromised, on the gateway there could be 1000s of >> devices connected. >> I've found that most vendor solutions aren't geared up for an admin to >> easily determine the compromised device and prevent this reconnecting. Most >> organisations have a disconnect between the SOC, PKI team and the team that >> manages the remote access gateway, getting a process that'll involve all 3 >> teams usually doesn't work. >> >> I've found that the best method to prevent the device from connecting is >> for the certificate to be revoked, the CRL refreshed and then a >> re-authentication performed on all active connections. >> >> I'm not as familiar with TLS as I am IPsec, but hope that this explains >> a scenario where I feel re-authentication would be very valuable. >> >> cheers >> >> On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> >> wrote: >> >>> Nico Williams <n...@cryptonector.com> writes: >>> >>> >When expirations are short, you will not forget to renew. That's part >>> of the >>> >point of short-lived certificates. >>> >>> So instead of getting one chance a year for your control system to break >>> itself if the renewal fails, you get hundreds of them? >>> >>> Peter. >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
