Gervase Markham <g...@mozilla.org> wrote: > On 18/11/16 19:13, Brian Smith wrote: > > Regardless, the main point of that message of mine was left out: You > could > > limit, in policy and in code, the acceptable lifetime of name-constrained > > externally-operated sub-CAs > > Presumably the "externally-operated" part would need to be policy, or a > code-detectable marker enforced by policy, because there's no way of > detecting that otherwise? >
In another message in this thread, I suggested one way to mark intermediate certificates as meeting the criteria of an name-constrained externally-operated sub-CA that uses certificate policy OIDs. That proposed mechanism also ensures externally-operated sub-CAs comply with Mozilla's technical requirements (e.g. SHA-1 deprecation and future deprecations or transisitions). > > > and/or the end-entity certificates they issue > > strictly, independently of whether it can be done for all certificates, > and > > doing so would be at least part of the solution to making > name-constrained > > externally-operated sub-CAs actually a viable alternative in the market. > > I'm not sure what you mean by "a viable alternative" - I thought the > concern was to stop them proliferating, Absolutely we should be encouraging them to proliferate. Every site that is doing anything moderately complex and/or that wants to use key pinning should be using them. > if what's underneath them was > opaque? And if it's not opaque, If draft-ietf-trans-rfc6962-bis section 4.2 discourages Mozilla from making externally-operated name-constrained certificates viable then please have somebody from Mozilla write to the TRANS list asking for section 4.2 to be removed from the draft. > why are they not a viable alternative > now, and why would restricting their capabilities make them _more_ viable? > Go out and try to find 3 different CAs that will sell you a name-constrained sub-CA certificate where you maintain control of the private key and with no strings attached (no requirement that you implement the same technical controls as root CAs or being audited to the same level as them). My understanding is that you won't be able to find any that will do so, because if you go off and issue a google.com certificate then Mozilla and others will then hold the issuing root CA responsible for that. My hypothesis is that CAs would be willing to start selling such certificates under reasonable terms if they weren't held responsible for the things signed by such sub-CAs. It would be good to hear from CAs who would be interested in that to see if that is true. To reiterate, I disagree that the name-constraint redaction is bad because the certificates issued by the externally-operated name-constrained CAs must be subject to all the terms of browsers' policies, including the BRs. That kind of thinking is 100% counter to the reason Mozilla created the exceptions for externally-operated name-constrained CAs in its policy in the first place. (Similarly, the requirements on externally-operated name-constrained CAs in the baseline requirements defeat the purpose of treating them specially.) However, i do agree that the technical details regarding (externally-operated) name-constrained CAs in Mozilla's policy and in draft-ietf-trans-rfc6962-bis are insufficient, and that's why I support (1) removing section 4.2 from draft-ietf-trans-rfc6962-bis-20, and (2) improving Mozilla's policy and the BRs so that the technical details do become sufficient. After that we can then see if it makes sense to revise rfc6962-bis to add redaction based on the revised details of how root stores treat name-constrained externally-operated sub-CAs. Cheers, Brian -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
