Why not use OCSP? On Wed, Dec 4, 2019 at 3:52 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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 < > dev-security-policy@lists.mozilla.org> 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 < > > dev-security-policy@lists.mozilla.org> 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 < > > dev-security-policy-boun...@lists.mozilla.org > > > > > > > On > > > > Behalf Of Wayne Thayer via dev-security-policy > > > > Sent: Monday, December 2, 2019 3:29 PM > > > > To: Ben Laurie <b...@google.com> > > > > Cc: mozilla-dev-security-policy > > > <mozilla-dev-security-pol...@lists.mozilla.org>; > > > > Peter Gutmann <pgut...@cs.auckland.ac.nz> > > > > 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 <b...@google.com> wrote: > > > > > > > > > > > > > > > > > > > On Thu, 28 Nov 2019 at 20:22, Peter Gutmann > > > > > <pgut...@cs.auckland.ac.nz> > > > > > wrote: > > > > > > > > > >> Ben Laurie via dev-security-policy > > > > >> <dev-security-policy@lists.mozilla.org> > > > > >> 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 > > > > dev-security-policy@lists.mozilla.org > > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > > _______________________________________________ > > > dev-security-policy mailing list > > > dev-security-policy@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
