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.


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*

  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.


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

Reply via email to