Hi all, This morning Symantec disclosed ~20 new intermediate certs. I went through these and identified 7 of them which are a) not revoked, b) not expired, c) lack a BR audit:
https://crt.sh/?q=54EFD2977D89EDE24DDC3797CEB5A80668B3905788B58FB1AC6893EF4B78A24A https://crt.sh/?q=D7D90D0FCFB5CDEC5754D663EEB3915D53703E1A29FAEEB398DCE0E22B5D4F9A https://crt.sh/?q=58FED89E47BC48DDC659419BB64BD0862A448FCB25842F8A3FA3671FF6468F42 https://crt.sh/?q=9127783BF5190D85BC5248364145AA683EC49CD63F344721B3914E2CAF61D7A0 https://crt.sh/?q=CC6D4E8FD20599A8CC23E739774EAFB70D03B24A824C0E05D94666F5E29FC5CA https://crt.sh/?q=DEEE5527B753A18D02BA2DAD6DFFB674CED0AF657BC0F430D4B32D97580F4D0E https://crt.sh/?q=BC983BE6435622EF64C8EFD23084D6F8E5DCFBE9D7BCFCE6A5E51C75A29D549A I believe this further underscores finding Y, and others related to lack of visibility into and BR-compliance of Symantec's intermediates. The fact that we can still be finding new intermediates leaves me to wonder if this is really the last of them, or there are still more. Personally, I think this highlights the value of my earlier proposal, and I think it's worth considering if, before any long term remediation strategies are considered, such a rule requiring full disclosure and CT submission of all Symantec CA certificates be implemented. Cheers, Alex On Thu, May 4, 2017 at 2:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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-lU >> PmatQZwx3Sn2NPz9jF8/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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
