RE: [EXT] Symantec: Draft Proposal
Symantec logs TLS server certificates that are intended to be trusted by Chrome to Certificate Transparency logs. Symantec does not systematically log other certificate types to CT, including Class 1, Class 2 and other types of user certificates. The Adobe Approved Trust List intermediate CA does not issue TLS certificates. This subCA issues Adobe document digital signature certificates that identify people and organizations and as such they are not systematically included in CT logging. See also: https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html https://helpx.adobe.com/acrobat/kb/approved-trust-list2/_jcr_content/main-pars/download-section/download-1/file.res/aatl_technical_requirements_v14.pdf From: Alex Gaynor [mailto:agay...@mozilla.com] Sent: Friday, May 05, 2017 10:18 AM To: Steve Medin <steve_me...@symantec.com> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: [EXT] Symantec: Draft Proposal 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=mozilladisclosure<https://clicktime.symantec.com/a/1/DpMVeod7OdWoZrchhebweNegkGMPsUHp-1SWSqHLiWg=?d=Z1VSr8kRHw-swZNCE6n0F6PJqS6Dawy0ZRX24ox8r12BLpDUpmwr2X0yO-UqN1DccyjCinObo29F4evy4ZTl321EROz_CUwk2Ph-0yTAk7_QFo0UyMEIbnfZbjKKwoOKM57FZ2pYUpkFOpFhmST_wLeoBztL6ERQ3p_LHV3k2r7Zvwr0y4AMyFUV-bsZ4TcJ8IxShADpdauwBawRNGCpwxuCt2rPgjaoGvJ5MOiYZcwFM00xu7ZRLvkJ7o577ceGmn6MisHkhyHX_7MZqVMtpUVMwU5L_HfezBj76rliUXPk9o1HD_udc5oCBn2sSiOSGZGQznN6inakQDPVY3BqkLX-UvpTxecosycllppwkMG7_iMTqQOfAuKCDrxHzhWL000nMcOq-afUAfeaHNF_=https%3A%2F%2Fcrt.sh%2F%3Fsha256%3D68a9878d55ad42107cfeb758e34873686969b0a47c7468fb189991acb62da798%26amp%3Bopt%3Dmozilladisclosure>. Can you confirm that this CA has _never_ been used to issue a certificate? (There ar e several other similar Symantec intermediates for which there are no publicly logged certs about which I have the same question). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Symantec: Draft Proposal
On 05/05/17 04:30, Steve Medin wrote: > 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 It feels somewhat strange to have this disjointed blog-vs.forum conversation... Here are my initial reactions on reading it. It seems to me that Symantec's new statement says very little which has not been said before, and that Symantec continues to underestimate the perceived severity of the issues. An argument that "we have revalidated all of these certificates and we haven't found very many with problems" seems basically like "OK, we weren't paying attention to what was going on over there, but as far as we can tell now, turns out it was nothing bad, so that's all OK then, isn't it?" Well, no. Symantec makes much of their upcoming super-strict audit regime, but does not seem to address the concerns raised in my proposal about the limitations of audit as a mechanism for ensuring appropriate conduct. They also seem to have ceased engaging with the issues list entirely, despite the fact that issue Y, a very serious issue, seems to be developing new facets and ramifications daily. > This transparency effort included explicitly providing to Google for > whitelisting the certificates that were issued by Symantec prior to us > fully deploying CT support. I notice Chrome does not contain such a whitelist. Ryan: are you able to comment on this? > If this action is taken exclusively against Symantec, it will create > significant disruption for hundreds of thousands of customers / users > and will harm our CA business. Mozilla does not take the possible business harm to CAs into consideration - in either direction - when considering our appropriate response to a CA incident. It is unreasonable of Symantec to argue that Mozilla should only take actions which result in no harm to Symantec's business, just as it would be unreasonable for a community member to argue that Mozilla should take additional actions "because the harm isn't great enough yet to teach them a lesson" or somesuch. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Symantec: Draft Proposal
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=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 [1] 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 < dev-security-policy@lists.mozilla.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 > 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
Re: [EXT] Symantec: Draft Proposal
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
RE: [EXT] Symantec: Draft Proposal
> -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 . smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [EXT] Symantec: Draft Proposal
Hi Steve, On 02/05/17 18:39, Steve Medin wrote: > Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to > respond to your latest proposal shortly. Please understand that this is not (yet) Mozilla's response to Symantec. If we were a closed root program, this would be an internal discussion draft. As we do everything in the open you get to read it now, but it may change before we make a formal decision on our position. You are welcome to participate in the discussion, but it is probably too early for a formal response to the document as a whole. If there are errors of fact in it, I would particularly appreciate correction. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: [EXT] Symantec: Draft Proposal
Gerv- Thank you for the thoughtful analysis. We are reviewing and intend to respond to your latest proposal shortly. > -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. > > https://clicktime.symantec.com/a/1/embmpyHl0xYIotG8R33Pcl_WmrsRKtG6 > UZVWv_jadWg=?d=977fUDFLd45Mc01kdDpFIhp6BGh6E7vHhynhAdgYKc7LS5 > -IW4PMfwwNk44IWsf3kg5SL1bzVN- > 8qX842oWjKLUf2m0Opcf9ODVHP1yk400fxZY5ty4Y7BHrKRTStgnQaIyPPxl9e3l > AN- > M5fnM7v_3sviEmWrjTcLDXrkH6P3_FhoZEWwOu7_SX_QsCYpqcwNH3EeXWn > 8BVLk1qqeWV5Bif1bTaL7Tt5x_6O96V7wmSpo0fuZsKDynd5LRJ5avq6ktSx2zc6 > BxeiHPXpDkIDzTHojYMzatcb0laJUTi5E44JYuI814oUpBm5xZoXoYGsUEwyOjur > brIcHHkAb_putgEp4COnDlh3Hs74FPlR6WYnSOOiCdCydUdXVYLK3_OMlBomq > iTSb6W4q8rG_2GPMwHZCk0nBrDFZ0Ncr6WDZU%3D=https%3A%2F%2Fd > ocs.google.com%2Fdocument%2Fd%2F1RhDcwbMeqgE2Cb5e6xaPq- > lUPmatQZwx3Sn2NPz9jF8%2Fedit%23 > > 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 > ___ > 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
