On Fri, Jun 20, 2025 at 3:20 PM Yaroslav Rosomakho <yrosoma...@zscaler.com> wrote: > > Hello Watson, > > On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd <watsonbl...@gmail.com> wrote: >> >> >> What exactly is the rationale here? Do we expect that identies >> actually change when a certificate expires? > > > Certificate confirms identity information for a certain period of validity as > long as it is not revoked. Communication with an endpoint that produces a > revoked or expired certificate is deemed to have unacceptable risk and > typically denied. However, this risk applies to established sessions in > exactly the same way as it applies to new sessions. The rationale is to > ensure that the peer identity is still valid by the time the original > certificate expired or got revoked.
Certificate expiry is in some sense driven by the risk of key compromise. If the key is compromised it fails to provide assurance as to the identity of the counterparty. But that compromise could also happen to the keys protecting the session over that length of time (yes, there are some differences in threat model depending on how they are stored). In that case this draft doesn't actually protect anything: an attacker with those keys is able to see the traffic going through and continue to exploit the session. This isn't really a problem of identities expering (how could they) but rather risk limitation. The reason I belabor this point is the conclusion: we have to rekey the connection as well to get the assurances we want. The mechanism here doesn't do that. > > TLS 1.2 and prior could perform re-key and re-authentication through > rehandshake. As the very generic rehandshake carried unacceptable security > risks it was removed in TLS 1.3. Extended Key Update brings back re-key in a > secure way. Similarly, Certificate Update proposal is intended to bring back > re-authentication in a very limited controlled fashion. > > Best Regards, > Yaroslav > > > This communication (including any attachments) is intended for the sole use > of the intended recipient and may contain confidential, non-public, and/or > privileged material. Use, distribution, or reproduction of this communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system. -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
