Not that anyone is presently doing or would do such a thing, but... Imagine a CA that wanted to offer up a user/browser tracking service to their subscriber customer.
Is there any rule that prevents an issuing CA from having a "custom" (hiding an identifier for the end-entity certificate) AIA URL? Such that when the browser AIA chases, it's disclosing the fact of the AIA chase as well as a user's IP address (and possibly some browser details) to the CA? One could easily do it with wildcard DNS and a per-end-entity cert host label for the AIA distribution point. On Wed, Dec 4, 2019 at 4:13 PM Ryan Sleevi via dev-security-policy < [email protected]> wrote: > Yes, I am one of the ones who actively disputes the notion that AIA > considered harmful. > > I'm (plesantly) surprised that any CA would be opposed to AIA (i.e. > supportive of "considered harmful", since it's inherently what gives them > the flexibility to make their many design mistakes in their PKI and still > have certificates work. The only way "considered harmful" would work is if > we actively remove the flexibility afforded CAs in this realm, which I'm > highly supportive of, but which definitely encourages more distinctive PKIs > (i.e. more explicitly reducing the use of Web PKI in non-Web cases) > > Of course, AIA is also valuable in helping browsers push the web forward, > so I can see why "considered harmful" is useful, especially in that it > helps further the notion that root certificates are a thing of value (and > whose value should increase with age). AIA is one of the key tools to > helping prevent that, which we know is key to ensuring a more flexible, and > agile, ecosystem. > > The flaw, of course, in a "considered harmful", is the notion that there's > One Chain or One Right Chain. That's not the world we have, nor have we > ever. The notion that there's One Right Chain for a TLS server to send > presumes there's One Right Set of CA Trust Anchors. And while that's > definitely a world we could pursue, I think we know from the past history > of CA incidents, there's incredible benefit to users to being able to > respond to CA security incidents differently, to remove trust in > deprecated/insecure things differently, and to set policies differently. > And so we can't expect servers to know the Right Chain because there isn't > One Right Chain, and AIA (or intermediate preloading with rapid updates) > can help address that. > > On Wed, Dec 4, 2019 at 5:02 PM Tim Hollebeek via dev-security-policy < > [email protected]> wrote: > > > Someone really should write up "AIA chasing considered harmful". It was > > disputed at the TLS session at IETF 105, which shows that the reasoning > > behind it is not as widely understood as it needs to be, even among TLS > > experts. > > > > I'm very appreciative of Firefox's efforts in this area. Leveraging the > > knowledge of all the publicly disclosed ICAs to improve chain-building is > > an > > idea whose time has come. > > > > -Tim > > > > > -----Original Message----- > > > From: dev-security-policy < > [email protected] > > > > > On > > > Behalf Of Wayne Thayer via dev-security-policy > > > Sent: Monday, December 2, 2019 3:29 PM > > > To: Ben Laurie <[email protected]> > > > Cc: mozilla-dev-security-policy > > <[email protected]>; > > > Peter Gutmann <[email protected]> > > > Subject: Re: [FORGED] Re: How Certificates are Verified by Firefox > > > > > > Why not "AIA chasing considered harmful"? The current state of affairs > is > > that > > > most browsers [other than Firefox] will go and fetch the intermediate > if > > it's not > > > cached. This manifests itself as sites not working in Firefox, and > users > > switching > > > to other browsers. > > > > > > You may be further dismayed to learn that Firefox will soon implement > > > intermediate preloading [1] as a privacy-preserving alternative to AIA > > chasing. > > > > > > - Wayne > > > > > > [1] > > > > > > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > > > #Intermediate_CA_Preloading > > > > > > On Thu, Nov 28, 2019 at 1:39 PM Ben Laurie <[email protected]> wrote: > > > > > > > > > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > <[email protected]> > > > > wrote: > > > > > > > >> Ben Laurie via dev-security-policy > > > >> <[email protected]> > > > >> writes: > > > >> > > > >> >In short: caching considered harmful. > > > >> > > > >> Or "cacheing considered necessary to make things work"? > > > > > > > > > > > > If you happen to visit a bazillion sites a day. > > > > > > > > > > > >> In particular: > > > >> > > > >> >caching them and filling in missing ones means that failure to > > > >> >present correct cert chains is common behaviour. > > > >> > > > >> Which came first? Was cacheing a response to broken chains or > broken > > > >> chains a response to cacheing? > > > >> > > > >> Just trying to sort out cause and effect. > > > >> > > > > > > > > Pretty sure if broken chains caused browsers to not show pages, then > > > > there wouldn't be broken chains. > > > > > > > > -- > > > > I am hiring! Formal methods, UX, SWE ... verified s/w and h/w. > > > > #VerifyAllTheThings. > > > > > > > > https://g.co/u58vjr https://g.co/adjusu *(Google internal)* > > > > > > > _______________________________________________ > > > dev-security-policy mailing list > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
