With the vast number of private PKIs created by the CA service included in Windows Server, the enterprise market tends to rely on Active Directory-based distribution within the forests it controls. This leads to an IE mandate, within a network that the owner/operator of the PKI controls.
When a private PKI attempts to cross outside its territory and unconsciously or subconsciously affect individuals through modification of how a browser operates, that crosses a line into warranting browser enforcement of constraint on what that PKI can do because it is no longer private once it reaches beyond its arm. This is what this discussion has mainly touched so far, and I don't contest that one bit, rather I'm interested in the opportunity in this situation. Poles defined, that leaves the grey area. Mozilla policy might wish to encourage and enable distribution of enterprise roots with the simplicity of AD group policy push. This supports an enterprise alternative, however it isn't easy to draw the boundary when you don't have a central repository that distinguishes a target device as subscribed to the enterprise network or not. Certainly there is plenty of genius among the dev community to overcome that with something more flexible than name constraints that become huge for large companies and change with every acquisition or brand launch requiring re-issuance. The problem needs dynamic data because the corporate name space is not static. Create membership in and enrollment to the influence of a private PKI not only from an end user pull but also a central corporate authority push and we solve the realm of authority issue. PrivDog and Superfish affect beyond their realm. OK, so create realm. Create a market for scoped buy in where the systems touched and people affected are wholly within the authority of the PKI injected into their browser. When the scope of interception is within a network that the PKI owner controls and the humans on that network are subject to its policy of interception as a condition of employment and they agree by remaining employed, then the interception is a controlled implementation of policy across an owned private scope. Even in the case where consent is not very conscious, attempts to suppress entirely rather than scope private-root-based interception will result in IE mandates. The root can be GPO-pushed silently, and either the proxy servers or the desktop management software can disable non-IE use. Kind regards, Steven Medin Product Manager, Identity and Access Management Verizon Enterprise Solutions -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness....@lists.mo zilla.org] On Behalf Of Clint Wilson Sent: Monday, February 23, 2015 5:14 PM To: [email protected] Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates. Lots of Enterprises and organizations have very legitimate requirements to add their own internal root CA to the NSS store. In fact, Mozilla even answers the question of how to do this: https://wiki.mozilla.org/CA:FAQ#How_do_I_import_a_root_cert_into_NSS_on_our_ organization.27s_internal_servers.3F What type of "signing" of these internal Root certificates should be required? On Monday, February 23, 2015 at 2:40:15 PM UTC-7, John Nagle wrote: > With the Lenovo and Comodo disclosures, the restrictions on loading > new certificates into Firefox clients need to be tightened. > > Add-on policy is moving to a new system where add-ons cannot be > added to a production version of Firefox without approval from AMO. > SSL certificates should get the same treatment. If you can't install > a new add-on unless it's been signed by AMO, why should you be able to > install a new SSL certificate without having it signed? > > John Nagle > SiteTruth _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
