On Friday, 6 May 2016 15:06:30 UTC+1, Richard Barnes wrote: > I would phrase this slightly differently :) If C is a Mozilla program > root, it has an obligation to verify that all of the subordinates under B > are audited and disclosed. My point is that if C doesn't do this check > proactively, before issuing the subordinate to B, or if C relies on > information from B and B gets things wrong, then A now has to get an audit > in emergency mode, or else cease operations.
This is where I think our interpretations of the situation diverge. Why should A get an "emergency audit" ? I think it's patently ridiculous to insist they do any such thing, and it's certainly beyond the practical power of Mozilla. Mozilla can distrust C though. > Whereas under the C='cert' policy, either A would be unconstrained and > already audited/disclosed, or they would have name constraints and there > would be no problem. Consider an only very slightly different scenario, with entities A1 through C1 instead of A through C, but now A1 and B1 are private CA issuers which previously weren't part of the web PKI at all. Maybe they were companies issuing mostly client certs to a specific industry, whatever the circumstances they weren't covered by the BRs or by Mozilla root programme rules. B1 is thinking of getting into the public CA business, and is talking to C1. Somebody at C1 jumps the gun and issues an unconstrained certificate joining B1, and thus A1 into the web PKI before they've actually done any sort of audit or due diligence. Whoops. In that scenario it doesn't matter whether you have policy C or policy CoAP, either way suddenly A1 is part of the Web PKI without being audited or disclosed. I believe this is because C1 screwed up and that trust stores like Mozilla should react accordingly, you seem to believe that instead A1 screwed up, by... allowing a business they have no direct relationship with to be run incompetently? And they now need to go through an emergency audit because... that will help the incompetents stay in business? As I said, I feel you have the trust arrow upside down. When C1 violates the rules, the negative consequences need to accrue to C1, otherwise they have no incentive to obey. When Mozilla was informed that The Walt Disney Company Root CA cert was in fact revoked by its issuer before that CA began violating the BRs but they didn't notify Mozilla, the expression of disappointment was - correctly - directed at that trusted CA issuer. Not at Disney, because that would be futile. > I'm more concerned about our ability to verify that CAs are in compliance > with the policy, in a world where we don't know the whole universe of > cross-certs. (And about consistency with the BRs on this point.) Consistency with the BRs is indeed worth having, but probably shouldn't be the primary consideration here. If we can choose a policy that's good, or one that's consistent, let's pick "good" and send the consistency problem to CA/B Forum for them to look at. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
