On 09/05/2019 16:35, Ryan Sleevi wrote: > On Wed, May 8, 2019 at 10:36 PM Jakob Bohm via dev-security-policy < > [email protected]> wrote: > >> [ Note, I am arguing a neutral position on the specific proposal ] >> >> The common purpose of having an internally secured (managed or on-site) >> CA in a public hierarchy is to have end certificates which are >> simultaneously: >> > > Despite my years of close experience with the implementation and details of > the certificate verification engines within Google Chrome and Android, > Mozilla Firefox, Apple iOS and macOS, and Microsoft Windows, including > extensive work with Enterprise PKIs, I must admit, I have never heard of > the scenario you're describing or actually being supported. > > Given that the remark is that such a desire is common, perhaps you can > provide some external references documenting how one might go about > configuring such a set-up, particularly in the context of TLS trust? > Similarly, I'm not aware of any system that supports binding S/MIME > identities to a particularly CA (effectively, CA pinning) - perhaps you can > provide documentation and reference for systems that perform this? > > Thanks for helping me understand how this 'common' scenario is actually > implemented, especially given that the underlying codebases do not support > such distinctions. >
My description is based on readily available information from the following sources, that you should also have access to: 1. The high level documentation and feature lists for enterprise PKI suites (which are completely different from the software suites designed for running public CA companies, because templates, validation methods and policies tend to be completely different). 2. The user and configuration interfaces for common software that needs to hold certificates (web servers, mail clients etc.). Those tend to be harder to use if different relying parties need different certificates for the same certificate subject. For example it is difficult to make mail clients sign/encrypt all mails if you need different personal certificates for the same e-mail account depending on who the mail is sent to, while a setting to do the same thing every time is typically a builtin option. Now imagine the certificate and private key being embedded in an employee ID card, while company workstations don't have unlocked spare ports for plugging in two different card readers (one for the employee ID card containing the access certificate that keeps the machine logged in, another for a USB token from a public CA). Similarly, it can get very tricky to make a web server use different certificate settings for different visitor categories accessing the same DNS name. 3. The details of publicly trusted company SubCAs that emerge from time to time in compliance cases. The details revealed tend to only make sense in setups like the ones described. 4. The actual number of companies needing this is an unknown that I make no claims about, it's not my proposal. 5. Maybe look at how Google employees and internal servers used certificates before the formation of GTS as a public CA. I doubt all your internal operational certificates chained to your publicly trusted SubCAs, and I doubt that Google sensitive systems accepted purported "Google authorized" certificates issued by the 3rd party public CA that signed Google's SubCA. [ I am not asking you to reveal the information, just think about it when considering the needs of companies that are never going to become root program members ]. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
