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

Reply via email to