- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 06 Apr 2015 19:34:23 +0000
- To: noloader@gmail.com, Eric Mill <eric@konklone.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8heEvfnTLuXbfFLHqn6N1W_Si-FoDLdK9eYkMKafV6Lgw@mail.gmail.com>
>The WebApp Sec group is creating policy and providing implementation > guidance based on a particular trust model that's not being followed. >How can the WebApp Sec group claim its not their problem when they are >predicating functionality like secure origins on it? All technology has dependencies and foundations. The policy questions about acceptable business practices for binding a name to a key, making assertions about that in a certificate, and what audit and control procedures should govern that are at a different layer than WebAppSec operates at. Even if we wanted to talk about it, the people who actually manage these issues for browsers and operating systems are not paying attention here - they are participating at the CABF and the Mozilla policy list, and that's where you need to go to effect any changes. -Brad On Mon, Apr 6, 2015 at 12:27 PM Jeffrey Walton <noloader@gmail.com> wrote: > On Mon, Apr 6, 2015 at 2:56 PM, Eric Mill <eric@konklone.com> wrote: > > > > As Peter Bowen pointed out in another thread, intermediate CAs (like > Google > > G2) have since become subject to auditing requirements they were not in > > 2005. > > The problem is not ex post facto auditing. > > The problem is the loss of the independent third party that assesses > the validity of the signing request (the RA). Under this system, the > inmates are running the asylum. > > The PKI trust model is predicated on trust with various entities > fulfilling separate roles. The trust is not transitive from a CA/RA to > an organization. > > What the GeoTrust root has managed to do is create a third class of > certificate. Here are the three classes. You decide on the relative > trustworthiness: > > * Extended Validation (EV) - restores due diligence checking > and restores CA profit levels. > * Domain Validation (DV) - minimal validation by third party, > suffered race to the bottom > * Organization Validation (OV) - no request validation by a third > party, organization just buys their way in and can mint > certificates, "just trust us" security model > > > I hate to extend the off-topic thread more, but so it's clear, this is a > > 10-year old announcement: > > http://www.hostreview.com/news/050215geotrust.html > > Yes. That was the missing piece of the puzzle for me. I am a slow > learner at times. But the problems it created still exist today. Q.v. > > Its seems to me the proposal on secure origins and access to power > features is based upon a belief in EV, DV and OV provide some type of > reputational service (despite the fact the CAs don't make those > claims). > > The only thing OV proves is an organization has the money to purchase > membership. Why should OV be granted access to powerful APIs when its > riskier than DV and EV, and it has fewer assurances than DV and EV? > > The WebApp Sec group is creating policy and providing implementation > guidance based on a particular trust model that's not being followed. > How can the WebApp Sec group claim its not their problem when they are > predicating functionality like secure origins on it? > > (And I agree with Brad that the problem was likely forged with the CAs > and the Browsers in the CA/B Forums). > > Jeff > > > > On Mon, Apr 6, 2015 at 1:05 PM, Daniel Veditz <dveditz@mozilla.com> > wrote: > >> > >> I echo Brad's suggestion to take this concern to Mozilla's security > policy > >> group. Issuing unconstrained and un-audited sub-CA certs would violate > >> Mozilla's certificate policy (see section 8 of > >> https://www.mozilla.org/en-US/about/governance/policies/ > security-group/certs/policy/inclusion/). > >> The press release doesn't actually say such certs would be > unconstrained and > >> GeoTrust should be well aware of these requirements, but it doesn't > hurt to > >> follow-up and make sure. > >> > >> -Dan Veditz > > > >
Received on Monday, 6 April 2015 19:34:51 UTC