On Fri, May 6, 2016 at 9:46 AM, Nick Lamb <[email protected]> wrote:
> On Friday, 6 May 2016 11:59:32 UTC+1, Rob Stradling wrote: > > Nick, IIUC you're arguing for "CoAP" (to use Richard's terminology). Is > > that right? > > I suppose so. I think Richard has the trust arrow upside down in his > reflection on this policy. Take his scenario in which a SubCA (A) is > surprised to discover that its previously constrained parent (B) has now > obtained an unconstrained certificate from a trusted root (C). > > Richard seems concerned that this puts A in an awkward position, but what > idiot is running C? They've just issued an unconstrained certificate to B, > and they apparently didn't so much as reach out to previously constrained > A, never mind having it properly audited for the new responsibilities > they've given it. Did they even review the signatures from B to ensure they > knew A existed? Nobody should trust C after this. With C untrusted, the > unconstrained certificate they've erroneously issued is now worthless and A > can continue to be as well run as it was before - once its leadership team > have recovered from their heart attacks. > 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. 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. That said, you're correct that the CoAP policy is consistent, and I agree that the risk of surprise isn't that bad if everyone is being responsible. 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.) --Richard > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
