<p dir="ltr"><br>
On Mar 24, 2015 8:07 AM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<br>
> Given that the browsers run the root programs and collect the audits, I was wondering if they knew whether all the subCAs listed below are covered by an audit.  That may be the only way to get this practice stopped.</p>
<p dir="ltr">Which practice? Unaudited subCAs? We still haven't closed the truck-sized loophole in the BRs that makes this obviously bad - instead, Mozilla has had to do so through their policy (Sections 8 and 10)</p>
<p dir="ltr">If you're not sure what the hole is, this is the whole discussion about scope of the BRs and measuring by technical capability, rather than the current Scope introduction of the BRs that measures by intent.</p>
<p dir="ltr">As you heard during our most recent F2F, this is something Mozilla has slowly been working towards. The aforementioned May 2014 CA Communication was the "come clean with amnesty" moment in which all CAs were to disclose all certs capable of issuing certs that chain to their roots, and the attendant audits. Sections 8&10 of the Mozilla policy establish that such disclosures and audits are necessary *before* any new certificates with CA=TRUE are given out and used to issue certs.<br></p>
<p dir="ltr">To make sure we are on the same page, and I'm not misinterpreting your question or the reasoning behind it, yes, this makes it explicit that every certificate with CA=TRUE, and without the technical constraints applied by Section 9 of the Mozilla policy, MUST be audited and disclosed. This makes roots and subCAs functionally equivalent in terms of responsibility.</p>
<p dir="ltr">The remaining difference is that roots applying for inclusion go through public review *before* inclusion, whereas such subCAs inherently go through review AFTER inclusion (since they can immediately be issuing publicly trusted certs once the PITRA per Section 17.4 of the BRs has completed). To balance that risk, the issuing (cross-certifying, if it's easier to think of) CA assumes ultimate liability for that subCA. The only way to divest the root of that liability is for the subCA to apply for inclusion themselves, go through the same public review and comment, and be included. At that point, cross-certifying (issuing) CAs are off the hook (other than ensuring disclosure beforehand and timely revocation after if the root is later removed)</p>
<p dir="ltr">For the sake of discussions here, historically it has been measured by the audit scheme. If you pass the "WebTrust Principles and Criteria for CAs" (_not_ the SSL BRs, as this proposal erroneously and mistakenly does), which all certs capable of issuance are required to do in Moz (SSL, CS, email, or otherwise), then you're arguably member eligible. The only implied rule we've been operating under is one audit, one vote - if your certificate is part of another's audit, you don't get two memberships & two votes for that one audit.</p>