It is clear to me from reading this that there is a significant gap between Symantec's perspective on the severity of the issues discussed and the perspective of many m.d.s.p. participants. Hopefully this email will serve to highlight some specific areas that contribute to this gap, and which leads many of us to find Symantec's proposal insufficient.
Quoting: > Moreover, the additional transparency we are already providing by logging all certificates issued to Certificate Transparency logs – including DV and OV – is a practice that the rest of the industry has yet to adopt. Given that Symantec's CT logging was imposed as a requirement for continued trust in Chrome, it is misleading to state that this reflects an effort by Symantec to go above and beyond (particularly given that some other CAs _voluntarily_ log all certs to CT). That is, however, a question of style. To ask a substantive question, you have asserted that all certificates issued have been logged to CT; this Symantec CA currently has no publicly logged issued certificates: https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798&opt=mozilladisclosure. Can you confirm that this CA has _never_ been used to issue a certificate? (There are several other similar Symantec intermediates for which there are no publicly logged certs about which I have the same question). Some of Symantec's assertions (particularly those about re-auditing issued certificates) seem to largely revolve around distinguishing the level to which their practices resulted in mis-issuance and the level of risk they represented for relying parties. To use an analogy, if I have a publicly trusted CA certificate and private key on a USB stick in my apartment, this represents a _massive_ risk for relying parties everywhere, even I never issue a single certificate from it. I would expect the WebPKI community to treat this with the utmost severity, even if I never (mis-)issued a single a certificate! Finally, Symantec states "we have put forward a proposal  that provides the highest level of transparency and reassurance of trust in active SSL/TLS certificates available in the industry" and "we believe our proposal provides the most open and transparent posture of any CA in the industry and reassures trust in active Symantec certificates and our current issuance practice". To help bridge the gap between Symantec and many other participants understanding, if Symantec were to propose an _even more_ aggressive remediation plan, aiming to achieve even higher levels of reassurance, what is the next additional change you would propose? Alex On Thu, May 4, 2017 at 11:30 PM, Steve Medin via dev-security-policy < firstname.lastname@example.org> wrote: > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+steve_medin=symantec....@lists.mozilla.org] On Behalf Of > > Gervase Markham via dev-security-policy > > Sent: Monday, May 01, 2017 10:16 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: [EXT] Symantec: Draft Proposal > > > > Here is my analysis and proposal for what actions the Mozilla CA > Certificates > > module owner should take in respect of Symantec. > > > [snip] > > > 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 :-) > > > > Gerv > > Gerv, thank you for your draft proposal under consideration. We have posted > our comments and detailed information at: > https://www.symantec.com/connect/blogs/symantec-ca-continues > -public-dialogue > . > > > > _______________________________________________ > dev-security-policy mailing list > email@example.com > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list firstname.lastname@example.org https://lists.mozilla.org/listinfo/dev-security-policy