> > This doesn't apply in case we're distrusting a CA because it's failed. In > 9.1 we're rotating keys. As I laid out in my initial mail, we can already > sign the new root with the old root to enable rotation. There's no size > impact to up-to-date clients using intermediate suppression or abridged > certs. >
The approach you describe requires the cooperation of the CA, in signing the new root with the old root. My understanding is that CAs (especially CAs in trouble with their root program) are often uncooperative or absentee. It also requires the CA's customers to go through a full issuance cycle before they get certificates with the new root, which could take over a year, during which time the compromised root will still need to be trusted. This draft is substantially better than that. It normalizes websites having multiple certificates from different CAs. In a future world with widespread adoption of Trust Expressions and ACME, a root could be distrusted immediately without warning and nothing would break because websites would transparently switch to their alternate CA. During the very very long period in which this is being incrementally deployed by clients and servers, Trust Expressions is still substantially better than the approach you describe because it creates the possibility for clients to negotiate away from a compromised CA where possible (i.e., even if a website operator has taken no action but presents multiple certificates, a client can choose a certificate with a non-compromised root). If we want to say that, we should have an extension that actually says you > have an accurate clock. > As has been mentioned, it takes a very long time for TLS extensions to gain adoption by a broad set of client implementations, server implementations, and website operators. If we built an extension that just said "I have an accurate clock, you can send me short-lived certificates" then it would need adoption by client implementations, server implementations, and website operators, and this would take a long time. Trust Expressions creates a happy path where 1.) clients indicate support for a feature by trusting a fancy new CA, and 2.) website operators support that feature simply by configuring their ACME client to get a certificate from that CA. Changing the server implementation isn't necessary. This happy path seems quite nice and useful to me On Tue, Apr 30, 2024 at 8:38 AM Dennis Jackson <ietf= 40dennis-jackson...@dmarc.ietf.org> wrote: > As mentioned above, we have such an extension already insofar as > indicating support for Delegated Credentials means indicating a desire for > a very short credential lifetime and an acceptance of the clock skew risks. > > Given how little use its seen, I don't know that its a good motivation for > Trust Expressions. > On 30/04/2024 16:33, Eric Rescorla wrote: > > > > On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd <watsonbl...@gmail.com> wrote: > >> On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla <e...@rtfm.com> wrote: >> > >> > >> > On the narrow point of shorter lifetimes, I don't think the right way >> to advertise that you have an accurate clock is to advertise that you >> support some set of root certificates. >> > >> > If we want to say that, we should have an extension that actually says >> you have an accurate clock. >> >> That says you *think* you have an accurate clock. >> > > Quite so. However, if servers gate the use of some kind of short-lived > credential > on a client signal that the client thinks it has an accurate clock > (however that > signal is encoded) and the clients are frequently wrong about that, we're > going > to have big problems. > > -Ekr > > > > >> Sincerely, >> Watson >> >> -- >> Astra mortemque praestare gradatim >> > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://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
