Graham, Deb,
* '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 agree. * 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. Agree. I guess this case rarely happens because short-lived certificates are not so short lived after all. * 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. I don’t see a need for TLS to do something. * 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.... I would imagine that the change of certificate will trigger a new handshake. If only the client-side certificate changes on a regular basis then I could imagine the Post handshake authentication to be quite useful. Ciao Hannes On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley <debcool...@gmail.com<mailto: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<mailto: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<mailto:pgut...@cs.auckland.ac.nz>> wrote: Nico Williams <n...@cryptonector.com<mailto: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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
