On Fri, 4 Nov 2016 14:09:55 +0100 Jakob Bohm <[email protected]> wrote:
> * How do we allow organization internal non-public CAs to not reveal > their secret membership/server lists to public CT systems or > otherwise run the (administratively and technically) expensive > processes required of public CAs. For example many medium or large > companies have in-house CAs issuing certificates for communicating > with their internal servers, VPNs, extranets etc. Such internal CAs > may very from primitive off-line CAs (no online active components > such as OCSP responders or CT loggers) to off-the-shelf enterprise CA > packages such as Microsoft Windows Server Certificate Services, xca > or EJBCA. > > * How do we prevent public CAs from misusing the exceptions for > private CAs? Isn't that already solved? Browsers already treat manually installed roots differently, e.g. bypassing key pinning. Chrome's CT requirements don't apply to locally installed roots. This seems to be the obvious solution. CT is there to have transparency of certificates by the browser-accepted CAs. If you have your own CA that souldn't be touched by that at all. (By the way I always found the "secret server name" idea wrong and I would generally recommend against local CAs in almost all cases. It adds a lot of complexity and I assume it often creates more problems than it solves.) -- Hanno Böck https://hboeck.de/ mail/jabber: [email protected] GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
