On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith <[email protected]> wrote: > 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.
I do hope you can expand upon the former as to what you see. As to the latter, key pinning is viable without the use of TCSCs. It's clear that you view there being a different risk/reward calculus for TCSCs, but I don't think I'd agree with that calculus. Many of the same considerations that exist with pinning EE certs still remain, and many of the same considerations that exist with pinning CA certs still remain. > 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, if it's completed WGLC, and describes a viable technical mechanism that may simply not be implemented via policy until sufficient policy controls exist? > 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). If you find a single one, do please report to this list - because that's not permitted under the Baseline Requirements today. > 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. That would require a change to the BRs, right? So far, no CAs have requested such a change, so why do you believe such CAs exist? > 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. Why should a technical document be blocked on the policy document? Shouldn't it be the other way around - or at least in parallel? 6962-bis describes a technical form, without making any statements on when that technical form may or may not be appropriate or suitable. That's a question of policy, much like the question of which CT logs to accept, or how many SCTs to require, isn't it? It's unclear what you see as technically deficient versus simply an incomplete policy requirement. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
