On 01/05/2017 16:16, Gervase Markham wrote:
Here is my analysis and proposal for what actions the Mozilla CA
Certificates module owner should take in respect of Symantec.
https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit#
Please discuss the document here in mozilla.dev.security.policy. A good
timeframe for discussion would be one week; we would aim to finalise the
plan and pass it to the module owner for a decision next Monday, 8th
May. Note that Kathleen is not around until Wednesday, and may choose to
read rather than comment here. It is not a given that she will agree
with me, or the final form of the proposal :-)
Some notes on the text now in the document:
1. Issue D actually seems to conflate three *completely different*
issues:
D1) MisIssuance of actual test certificates for real world domains
that had not approved that issuance. I think this was mostly the
old issue involving a very small number of improper in-house test
certs by Symantec.
D2) Dubious / non-permitted substitution of the word "test" for the
organization name in otherwise fully validated OV certificates as
a service to legitimate domain holders wanting to test Symantec
certificates before paying for final issuance of certs with their
actual name. This was much less harmful, but was done in large
numbers by the CrossCert RA.
D3) Dubious and actual misussance of certificates for some domains
containing "test" as a substring under the direction of the
CrossCert RA. These vary in seriousness but I think their total
number is much smaller than those in category D2.
Splitting these three kinds of "test" certificates will properly give
a much clearer issue of what was going on and how serious it was.
2. If the remaining unconstrained SubCAs are operated by Symantec and
subject to (retroactive if necessary) compliance audits showing that
they don't issue certs that could not (under the BR and Mozilla
policies) be issued from a public Symantec CA by an "Enterprise RA"
(as defined in the BRs), could those SubCAs not simply be
reclassified as "public SubCAs" for Mozilla/BR policy purposes while
remaining further usage limited by actual Symantec practices and
contractual arrangements beyond the BR/Mozilla policies?
3. The plan involving a new hierarchy outsourced to a Symantec
competitor leaves some big questions when seen from outside the
Google perspective:
- Is it really necessary to outsource this to bring the Symantec PKI
under control? Or was this simply copy/pasted from the
WoSign/StartCom situation?
- If this is outsourced as suggested, how can/should Symantec
continue to serve customers wanting certificates that chain to
older CA certs in the old hierarchy. For example some brands of
Smartphones require that all apps installed are signed by specific
old Symantec hierarchies via exclusivity deals that were in place
when those Smartphones were manufactured, and no changes to that
requirement are feasible at this point for the already sold phones.
Similar issues may exist in the WebPKI for jobs such as providing
HTTPS downloads of Firefox to machines whose existing browser is
outdated and contains an outdated root store.
- Should Symantec be allowed to cross-sign SubCAs of the new roots
directly from the old roots, thus keeping the chain length to the
old roots short?
- Could some of the good SubCAs under the "Universal" and "Georoot"
program be salvaged by signing them from new roots and adding the
cross certs to default Mozilla and Chrome installations (so servers
don't need to install them)? For example, if the legit EV SubCAs
under "Universal" are cross-signed by a (new) "EV-only" root, could
Mozilla move the EV trust to that new root, thus removing the
risk of EV-trusting any other "Universal" subCAs.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
