Hi all. Thanks for the discussion! While we're digesting it all, one quick comment regarding the feedback in Prague:
>From talking with folks at the meeting, it seemed part of this was due to a misunderstanding. Trust expressions are not intended to capture per-user customizations to root stores, as that has a number of issues. The intent was to capture only what is implied by the browser + version. (Or the analog for other kinds of TLS deployments. More precisely, base it on your desired anonymity set.) We rewrote the privacy considerations <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations> section after that meeting in response to this, to try to make that clearer. On Tue, Apr 30, 2024 at 5:34 PM Brendan McMillion < brendanmcmill...@gmail.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
