Steve, I am glad to see that Symantec is willing to continue public discussion on possible paths forward. But these responses still seem to continue to focus on the RA issue, and do not respond to or address all of the other serious issues identified here. For example, issue Y (Q9) -- un- or under- audited sub-CAs technically capable (even if administratively constrained) of issuing SSL/TLS certificates trusted by Mozilla (and others). Especially given that there are clearly still undislosed sub-CAs that Symantec is only now revealing (despite claims in 2014/2015 that all had been), at least one with a non-zero pathlen constraint (e.g. https://crt.sh/?sha256=68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798 ) and thus capable not only of issuing end-entity certs, but of having undisclosed sub-subCAs.
For reasons such as this, I am highly skeptical that Symantec [intentionally or not] appreciates the gravity of the issues raised here; had Symantec's current proposal been the response to the test certificate problems from a couple of years ago, I would have considered it an appropriate response. Now I view it as an untenable position that can be succinctly described as: too little, too late, to restore confidence in Symantec management and issuance practices. The argument against the new public PKI (making the existing symantec PKI a large private PKI) also seems quite weak, essentially boiling down to: Symantec thinks it is not a proportional response to the issues identified, implicitly acknowledging that it may mitigate many of the compatibility concerns of your customers as long as the new roots or subCAs are signed by the old roots as needed. I'd also be very curious to know the answer to Ryan's question about EV certificates and RAs (both now and in the past), as the answer to that seems germane to Mozilla's decision making process. Also, your reporting of the responses of your enterprise customers seems a bit incongruous: in the earlier response, you claimed many large enterprises would require months or years to plan a change of certificates -- but then claim here that should Symantec be restricted to 13 months, these customers will move to other CAs who can issue longer certs. But given the direction of travel in cert lifetimes (where 2 yr+renewal time begins in 2018 and it is plausible a 13 month lifetime may be required in 2-3 years), I don't understand how moving would be substantially advantageous to these customers (esp. since any of the proposals here would involve less compatability risks since chaining to the old symantec roots would be maintained). On Thursday, May 4, 2017 at 11:30:33 PM UTC-4, Steve Medin 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
