[cabfpub] FW: Bylaw update proposal

[Ryan Sleevi]

On Mar 24, 2015 8:07 AM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
> 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.

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)

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.

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.

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.

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)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150324/0906851b/attachment-0003.html>