RE: Misissued/Suspicious Symantec Certificates
Our fourth response to questions is posted at Bugzilla, https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. It includes two attachments at that bug: https://bugzilla.mozilla.org/attachment.cgi?id=8843448 https://bugzilla.mozilla.org/attachment.cgi?id=8843449 From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, February 22, 2017 11:33 PM To: Steve Medin <steve_me...@symantec.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com; Gervase Markham <g...@mozilla.org> Subject: Re: Misissued/Suspicious Symantec Certificates Hi Steve, Thanks for your continued attention to this matter. Your responses open many new and important questions and which give serious question as to whether the proposed remediations are sufficient. To keep this short, and thereby allow Symantec a more rapid response: 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner since the acquisition by Symantec of the VeriSign Trust Services business in 2010. On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Our third response to questions, including these two below, is posted at Bugzilla, and directly at https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825<https://clicktime.symantec.com/a/1/maIs7jXt0tqwnz1Jx0AxZjkA8GILUQI09uuEhZICWEQ=?d=7ylIQcW9MI3sm23dlF9kH0iQJbyD55FBGhRKwcFXib_4hIAJwQhgd3_24qB0coAv-SdkMKlUr1dYe3ULlJgm969yhZKu4ZLoTqyM3AhvyrmRjBijxx3oSZPweXl_MrKyswyJA1YgFpcKGlUTjUSxotLtqPMZn4tj-_2nsHC7tdtHzA9HmVLZRFXR2Ty6fDlHgYxN5haET45fGSzWiPA8P-VLtfS-ypJqHrmea4f-tKogptm9DGWQ3s-zZjo7FB1wGZL29RK8Xht9YbsSKN7HoJ0DcrJCTqWKwAapOYXopyC1Pf6hUe049AYjSS_wYcu7YAYcbfx2aEyndOFglqSVO7862-3Ny98IiKnskPeYE4pqtE1wHuEAeXC4OopLbVI1LP28GRXPjy8GPSImqgPdjyvD-hmSUJJt=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8838825>. From: Ryan Sleevi [mailto:r...@sleevi.com<mailto:r...@sleevi.com>] Sent: Friday, February 17, 2017 6:54 PM To: Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> Cc: Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>; Steve Medin <steve_me...@symantec.com<mailto:steve_me...@symantec.com>> Subject: Re: Misissued/Suspicious Symantec Certificates Hi Steve, Two more question to add to the list which is already pending: In [1], in response to question 5, Symantec indicated that Certisign was a WebTrust audited partner RA, with [2] provided as evidence to this fact. While we discussed the concerns with respect to the audit letter, specifically in [3], questions 3 - 6, and while Symantec noted that it would case to accept future EY Brazil audits, I have confirmed with CPA Canada that at during the 2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as indicated at [4]. Given that EY Brazil was not a licensed WebTrust auditor, it appears that Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], namely, that "(For audits conducted in accordance with the WebTrust standard) licensed by WebTrust", which is a requirement clearly articulated in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, ..." 1) Was Symantec's compliance team involved in the review of Certisign's audit? 2) Does Symantec agree with the conclusion that, on the basis of this evidence, Symantec failed to uphold the Baseline Requirements, independent of any action by a Delegated Third Party? [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<https://clicktime.symantec.com/a/1/vG4MDB3hNsGYUc24ZpW7pdrPIan-c_b-D8RRJ1NfRP4=?d=7ylIQcW9MI3sm23dlF9kH0iQJbyD55FBGhRKwcFXib_4hIAJwQhgd3_24qB0coAv-SdkMKlUr1dYe3ULlJgm969yhZKu4ZLoTqyM3AhvyrmRjBijxx3oSZPweXl_MrKyswyJA1YgFpcKGlUTjUSxotLtqPMZn4tj-_2nsHC7tdtHzA9HmVLZRFXR2Ty6fDlHgYxN5haET45fGSzWiPA8P-VLtfS-ypJqHrmea4f-tKogptm9DGWQ3s-zZjo7FB1wGZL29RK8Xht9YbsSKN7HoJ0DcrJCTqWKwAapOYXopyC1Pf6hUe049AYjSS_wYcu7YAYcbfx2aEyndOFglqSVO7862-3Ny98IiKnskPeYE4pqtE1wHuEAeXC4OopLbVI1LP28GRXPjy8GPSImqgPdjyvD-hmSUJJt=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831933><https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1LRVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8c WaB75e0ZDlR_f
Re: Misissued/Suspicious Symantec Certificates
On Tuesday, 28 February 2017 17:45:19 UTC, Santhan Raj wrote: > WebTrust for Certification Authorities , SSL > BaselinewithNetwork Security, Version 2.0,available > at > http://www.webtrust.org/homepage‐documents/item79806.pdf. 404 - File or directory not found. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 24, 2017 at 5:12:43 PM UTC-8, Peter Bowen wrote: > "auditing standards that underlie the accepted audit schemes found in > Section 8.1" > > This is obviously a error in the BRs. That language is taken from > Section 8.1 and there is no list of schemes in 8.1. > > 8.4 does have a list of schemes: > 1. WebTrust for Certification Authorities v2.0; > 2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI > EN 319 411-1; > 3. A scheme that audits conformance to ISO 21188:2006; or > 4. If a Government CA is required by its Certificate Policy to use a > different internal audit scheme, it MAY use such scheme provided that > the audit either (a) encompasses all requirements of one of the above > schemes or (b) consists of comparable criteria that are available for > public review. > > 1. is slight problematic as no scheme exists by that name, but "Trust > Service Principles and Criteria for Certification Authorities Version > 2.0" does exist, which is what I assume is meant. > This is something that should be fixed in the BR and in fact both the audit schemes (WTCA & WTBR) should be listed in Section 8.4 (obviously WTCA by itself doesn't cover all BR requirements, only WTBR does). While your assumption is just, Section 1.6.3 has the following reference, so its hard to tell what the intent is. WebTrustfor Certification Authorities , SSL BaselinewithNetwork Security, Version 2.0,available at http://www.webtrust.org/homepage‐documents/item79806.pdf. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Fri, Feb 24, 2017 at 4:51 PM, Ryan Sleeviwrote: > > > On Wed, Feb 22, 2017 at 8:32 PM, Ryan Sleevi wrote: > >> Hi Steve, >> >> Thanks for your continued attention to this matter. Your responses open >> many new and important questions and which give serious question as to >> whether the proposed remediations are sufficient. To keep this short, and >> thereby allow Symantec a more rapid response: >> >> 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA >> partner since the acquisition by Symantec of the VeriSign Trust Services >> business in 2010. >> > > Hi Steve, > > Have you had the opportunity to review and complete this? This is > hopefully a simple task for your compliance team, given the critical > necessity of maintaining of records, so I'm hoping that you can post within > the next business day. > Hi Steve, I think we would have expected this would be fairly easy to obtain, given the record keeping requirements and the fact that these were relationships pre-existing to the Symantec acquisition. Can you speak to more about why the delay, and when Symantec expects this information to be available? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
"auditing standards that underlie the accepted audit schemes found in Section 8.1" This is obviously a error in the BRs. That language is taken from Section 8.1 and there is no list of schemes in 8.1. 8.4 does have a list of schemes: 1. WebTrust for Certification Authorities v2.0; 2. A national scheme that audits conformance to ETSI TS 102 042/ ETSI EN 319 411-1; 3. A scheme that audits conformance to ISO 21188:2006; or 4. If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either (a) encompasses all requirements of one of the above schemes or (b) consists of comparable criteria that are available for public review. 1. is slight problematic as no scheme exists by that name, but "Trust Service Principles and Criteria for Certification Authorities Version 2.0" does exist, which is what I assume is meant. If we assume that audit scheme, my understanding is that the "auditing standards that underlie" the scheme is one of the following (which one depends on the date of the audit and the licensure of the auditor): (1) AT sec. 101 from SSAE No. 10/11/12 (AICPA) (2) AT-C sec. 205 from SSAE No. 18 (AICPA) (3) Section 5025 (CPA Canada) (4) CSAE 3000 (CPA Canada) (5) ISAE 3000 (IFAC) There should be no lack of auditing standards that underlie the Trust Service Principles and Criteria for Certification Authorities Version 2.0 audit scheme found in section 8.4. Thanks, Peter On Thu, Feb 23, 2017 at 1:19 AM, Ryan Sleevi via dev-security-policywrote: > I'm sorry, I'm still a little confused about how to understand your > response. > > I can't tell if you're discussing in the abstract - as in, you don't know > how an Delegated Third Party would ever meet that definition, due to the > absence of "auditing standards that underlie the accepted audit schemes > found in Section 8.1" therefore you don't think what Symantec has been > doing since 2010 is permitted by the Baseline Requirements at all, and they > should have stopped five years ago. That implies you read through the links > provided by Symantec so far of the four RAs that they assert were operating > as Delegated Third Parties (which is the only way this could have been > acceptable to begin with), but that you disagree that they're evidence of > compliance with the restrictions on the Delegated Third Parties. Is this > what you meant? > > Or if you mean something concrete - that is, that you literally are > interested and curious, without any subtext. In that case, it implies you > may not have checked the links in the message you were replying to yet, and > this was more of an aside, rather than a direct question. If this was the > case, do you think it's reasonably clear the question I'd asked of Steve? > > Or am I completely off the mark? I just want to make sure that the question > I asked is clear and unambiguous, as well as making sure I'm not > misunderstanding anything. > > On Wed, Feb 22, 2017 at 9:21 PM, Jeremy Rowley > wrote: > >> I am aware of the requirements but am interested in seeing how an RA that >> doesn't have their own issuing cert structures the audit report. It >> probably looks the same, but I've never seen one (unless that is the case >> with the previously provided audit report). >> >> On Feb 22, 2017, at 8:48 PM, Ryan Sleevi wrote: >> >> >> >> On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley > > wrote: >> >>> Webtrust doesn't have audit criteria for RAs so the audit request may >>> produce interesting results. Or are you asking for the audit statement >>> covering the root that the RA used to issue from? That should all be public >>> in the Mozilla database at this point. >> >> >> Hi Jeremy, >> >> I believe the previous questions already addressed this, but perhaps I've >> misunderstood your concern. >> >> "Webtrust doesn't have audit criteria for RAs so the audit request may >> produce interesting results." >> >> Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4 >> "If the CA is not using one of the above procedures and the Delegated >> Third Party is not an Enterprise RA, then the >> CA SHALL obtain an audit report, issued under the auditing standards that >> underlie the accepted audit schemes >> found in Section 8.1, that provides an opinion whether the Delegated Third >> Party’s performance complies with >> either the Delegated Third Party’s practice statement or the CA’s >> Certificate Policy and/or Certification Practice >> Statement. If the opinion is that the Delegated Third Party does not >> comply, then the CA SHALL not allow the >> Delegated Third Party to continue performing delegated functions. " >> >> Note that Symantec has already provided this data for the four RA partners >> involved for the 2015/2016 (varies) period, at [2]. Specifically, see the >> response to Question 5 at [3]. >> >> "Or are
Re: Misissued/Suspicious Symantec Certificates
On Wed, Feb 22, 2017 at 8:32 PM, Ryan Sleeviwrote: > Hi Steve, > > Thanks for your continued attention to this matter. Your responses open > many new and important questions and which give serious question as to > whether the proposed remediations are sufficient. To keep this short, and > thereby allow Symantec a more rapid response: > > 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA > partner since the acquisition by Symantec of the VeriSign Trust Services > business in 2010. > Hi Steve, Have you had the opportunity to review and complete this? This is hopefully a simple task for your compliance team, given the critical necessity of maintaining of records, so I'm hoping that you can post within the next business day. Regards, Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
I am aware of the requirements but am interested in seeing how an RA that doesn't have their own issuing cert structures the audit report. It probably looks the same, but I've never seen one (unless that is the case with the previously provided audit report). On Feb 22, 2017, at 8:48 PM, Ryan Sleevi> wrote: On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowley > wrote: Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results. Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point. Hi Jeremy, I believe the previous questions already addressed this, but perhaps I've misunderstood your concern. "Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results." Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4 "If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions. " Note that Symantec has already provided this data for the four RA partners involved for the 2015/2016 (varies) period, at [2]. Specifically, see the response to Question 5 at [3]. "Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point." Again, referencing Question 5 at [3], and the overall topic of the thread, no, I am not asking for the audit statement covering the root that the RA used to issue from. I'm asking for the audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Wed, Feb 22, 2017 at 8:36 PM, Jeremy Rowleywrote: > Webtrust doesn't have audit criteria for RAs so the audit request may > produce interesting results. Or are you asking for the audit statement > covering the root that the RA used to issue from? That should all be public > in the Mozilla database at this point. Hi Jeremy, I believe the previous questions already addressed this, but perhaps I've misunderstood your concern. "Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results." Quoting the Baseline Requirements, v.1.4.2 [1] , Section 8.4 "If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party’s performance complies with either the Delegated Third Party’s practice statement or the CA’s Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions. " Note that Symantec has already provided this data for the four RA partners involved for the 2015/2016 (varies) period, at [2]. Specifically, see the response to Question 5 at [3]. "Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point." Again, referencing Question 5 at [3], and the overall topic of the thread, no, I am not asking for the audit statement covering the root that the RA used to issue from. I'm asking for the audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.2.pdf [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Webtrust doesn't have audit criteria for RAs so the audit request may produce interesting results. Or are you asking for the audit statement covering the root that the RA used to issue from? That should all be public in the Mozilla database at this point. > On Feb 22, 2017, at 8:33 PM, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > Hi Steve, > > Thanks for your continued attention to this matter. Your responses open > many new and important questions and which give serious question as to > whether the proposed remediations are sufficient. To keep this short, and > thereby allow Symantec a more rapid response: > > 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner > since the acquisition by Symantec of the VeriSign Trust Services business > in 2010. > > > > On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Our third response to questions, including these two below, is posted at >> Bugzilla, and directly at https://bug1334377. >> bmoattachments.org/attachment.cgi?id=8838825. >> >> >> >> >> >> From: Ryan Sleevi [mailto:r...@sleevi.com] >> Sent: Friday, February 17, 2017 6:54 PM >> To: Ryan Sleevi <r...@sleevi.com> >> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-policy@ >> lists.mozilla.org; Steve Medin <steve_me...@symantec.com> >> Subject: Re: Misissued/Suspicious Symantec Certificates >> >> >> >> Hi Steve, >> >> >> >> Two more question to add to the list which is already pending: >> >> >> >> In [1], in response to question 5, Symantec indicated that Certisign was a >> WebTrust audited partner RA, with [2] provided as evidence to this fact. >> While we discussed the concerns with respect to the audit letter, >> specifically in [3], questions 3 - 6, and while Symantec noted that it >> would case to accept future EY Brazil audits, I have confirmed with CPA >> Canada that at during the 2016 and 2017 periods, EY Brazil was not a >> licensed WebTrust practitioner, as indicated at [4]. >> >> >> >> Given that EY Brazil was not a licensed WebTrust auditor, it appears that >> Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 >> [5], namely, that "(For audits conducted in accordance with the WebTrust >> standard) licensed by WebTrust", which is a requirement clearly articulated >> in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not >> using one of the above procedures and the Delegated Third Party is not an >> Enterprise RA, then the CA SHALL obtain an audit report, issued under the >> auditing standards that underlie the accepted audit schemes found in >> Section 8.1, ..." >> >> >> >> 1) Was Symantec's compliance team involved in the review of Certisign's >> audit? >> >> 2) Does Symantec agree with the conclusion that, on the basis of this >> evidence, Symantec failed to uphold the Baseline Requirements, independent >> of any action by a Delegated Third Party? >> >> >> >> [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933< >> https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1L >> RVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w >> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA >> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT >> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK- >> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK >> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7- >> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8% >> 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid% >> 3D8831933> >> >> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929< >> https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC >> 72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w >> d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA >> Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT >> 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK- >> 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK >> sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7- >> kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8% >> 3D=https%3A%2F%2Fbug1334377.bmoattachments.or
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, Thanks for your continued attention to this matter. Your responses open many new and important questions and which give serious question as to whether the proposed remediations are sufficient. To keep this short, and thereby allow Symantec a more rapid response: 1) Please provide the CP, CPS, and Audit Letter(s) used for each RA partner since the acquisition by Symantec of the VeriSign Trust Services business in 2010. On Fri, Feb 17, 2017 at 8:32 PM, Steve Medin via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Our third response to questions, including these two below, is posted at > Bugzilla, and directly at https://bug1334377. > bmoattachments.org/attachment.cgi?id=8838825. > > > > > > From: Ryan Sleevi [mailto:r...@sleevi.com] > Sent: Friday, February 17, 2017 6:54 PM > To: Ryan Sleevi <r...@sleevi.com> > Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-policy@ > lists.mozilla.org; Steve Medin <steve_me...@symantec.com> > Subject: Re: Misissued/Suspicious Symantec Certificates > > > > Hi Steve, > > > > Two more question to add to the list which is already pending: > > > > In [1], in response to question 5, Symantec indicated that Certisign was a > WebTrust audited partner RA, with [2] provided as evidence to this fact. > While we discussed the concerns with respect to the audit letter, > specifically in [3], questions 3 - 6, and while Symantec noted that it > would case to accept future EY Brazil audits, I have confirmed with CPA > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > licensed WebTrust practitioner, as indicated at [4]. > > > > Given that EY Brazil was not a licensed WebTrust auditor, it appears that > Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 > [5], namely, that "(For audits conducted in accordance with the WebTrust > standard) licensed by WebTrust", which is a requirement clearly articulated > in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not > using one of the above procedures and the Delegated Third Party is not an > Enterprise RA, then the CA SHALL obtain an audit report, issued under the > auditing standards that underlie the accepted audit schemes found in > Section 8.1, ..." > > > > 1) Was Symantec's compliance team involved in the review of Certisign's > audit? > > 2) Does Symantec agree with the conclusion that, on the basis of this > evidence, Symantec failed to uphold the Baseline Requirements, independent > of any action by a Delegated Third Party? > > > > [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933< > https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1L > RVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w > d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA > Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT > 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK- > 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK > sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7- > kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8% > 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid% > 3D8831933> > > [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929< > https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC > 72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w > d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA > Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT > 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK- > 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK > sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7- > kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8% > 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid% > 3D8831929> > > [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487< > https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tv > wuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9w > d5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntA > Wmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT > 1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK- > 4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvK > sUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7- > kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8% > 3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid% > 3D8836487> > > [4] http://www.webtrust.
RE: Misissued/Suspicious Symantec Certificates
Our third response to questions, including these two below, is posted at Bugzilla, and directly at https://bug1334377.bmoattachments.org/attachment.cgi?id=8838825. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Friday, February 17, 2017 6:54 PM To: Ryan Sleevi <r...@sleevi.com> Cc: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org; Steve Medin <steve_me...@symantec.com> Subject: Re: Misissued/Suspicious Symantec Certificates Hi Steve, Two more question to add to the list which is already pending: In [1], in response to question 5, Symantec indicated that Certisign was a WebTrust audited partner RA, with [2] provided as evidence to this fact. While we discussed the concerns with respect to the audit letter, specifically in [3], questions 3 - 6, and while Symantec noted that it would case to accept future EY Brazil audits, I have confirmed with CPA Canada that at during the 2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as indicated at [4]. Given that EY Brazil was not a licensed WebTrust auditor, it appears that Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], namely, that "(For audits conducted in accordance with the WebTrust standard) licensed by WebTrust", which is a requirement clearly articulated in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, ..." 1) Was Symantec's compliance team involved in the review of Certisign's audit? 2) Does Symantec agree with the conclusion that, on the basis of this evidence, Symantec failed to uphold the Baseline Requirements, independent of any action by a Delegated Third Party? [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933<https://clicktime.symantec.com/a/1/6wJmuz5H2ktURSIGjev34ZuuQTad1LRVz1nIlADR7XE=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831933> [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929<https://clicktime.symantec.com/a/1/pfZiLBH0rxpzxfeiB5YSfvWdOjwpHC72M_rUahZJxKQ=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8831929> [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487<https://clicktime.symantec.com/a/1/80dDdC7HC5yMdzxfwRS0saqQ2kS5Tvwuo_kNWaXWLCI=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D=https%3A%2F%2Fbug1334377.bmoattachments.org%2Fattachment.cgi%3Fid%3D8836487> [4] http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx [5] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf<https://clicktime.symantec.com/a/1/7AUAkdAzUJ1un022RuP_TfjD3UiY12QGLjanVeGgxhk=?d=EzdV7X-pe5sih3AYTnIMlzBIT3AaPBWIYQF9wd5LbpGrImaYYowG0inKiozTFwfAeJMk8B2dt_4yENjH4IaBlGSfv3Nbn8GMpSPDtntAWmyx8q3PfDYHHU_bDfrHZGtmC5XInqf0-ck-FF9e6SGtIxb23Mc2kGZNy8eGAG1jAT1TAe21ybqhXxIvmlxFXmTHtVMR3YXXvHPdAlcwv8e83_rm24C4_wUeNtE5oJFsBljHikK-4oZ1OAUbs4kCgGUxt8cWaB75e0ZDlR_fb71_91rphEjG44uTwcWMGyYK07gsGTyfvKsUrvka6LTCQoX9d09q2fHeLb5TL3SPWUKa6B9_V5GfWubr-0rIMxR7-kT2QzmMrkTgl2YGGDT-rtrKWSZ_xCOsOuU3sp_ARcYoRPNHR1FUGD8%3D=https%3A%2F%2Fcabforum.org%2Fwp-content%2Fuploads%2FCA-Browser-Forum-BR-1.4.1.pdf> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 10:19:06 PM UTC-5, Ryan Sleevi wrote: > On Fri, Feb 17, 2017 at 5:17 PM, urijah--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > > > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > > > I have confirmed with CPA > > > > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > > > > licensed WebTrust practitioner, as indicated at [4]. > > > > > > > > [4] > > > > http://www.webtrust.org/licensed-webtrust-practitioners-international/ > > item64419.aspx > > > > > > > > > The footnote at the above makes that a little hard to understand-- > > > > > > "EY refers to a member firm of Ernst & Young Global Limited. Through a > > license with Ernst & Young Global Limited all EY members are licensed to > > provide WebTrust for Certification Authorities services." > > > > Thanks for highlighting this. Indeed, while confirming the list was up to > date, I had missed the footnote. > > > > Additionally "Ernst Young Brazil" was listed as late as March 20, 2016 > > apparently. > > > > https://web-beta.archive.org/web/20160320161225/http://www. > > webtrust.org/licensed-webtrust-practitions-international/item64419.aspx > > > > > The audit was dated 2017/01/24, so the historic status would be irrelevant. Sure. The strange thing to me (and possibly not relevant to this thread) is how both can be true--all E members worldwide are licensed to do WebTrust audits, yet E Brazil was taken *off* the WebTrust list in the latest update. I think http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx and https://web-beta.archive.org/web/20160320161225/http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx are possibly intended to be read differently. The old list giving specific named firms (or branches), by country (but saying it is a list of "global practitioners") the new list giving many fewer firms, but the country listing meaning...where they are active? If WebTrust revamped their approach to licensing, it might be good to know why/how and when. (And I don't see anywhere on their site where they discuss how they license auditors at all.) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Fri, Feb 17, 2017 at 5:17 PM, urijah--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > > I have confirmed with CPA > > > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > > > licensed WebTrust practitioner, as indicated at [4]. > > > > > > [4] > > > http://www.webtrust.org/licensed-webtrust-practitioners-international/ > item64419.aspx > > > > > > The footnote at the above makes that a little hard to understand-- > > > > "EY refers to a member firm of Ernst & Young Global Limited. Through a > license with Ernst & Young Global Limited all EY members are licensed to > provide WebTrust for Certification Authorities services." > Thanks for highlighting this. Indeed, while confirming the list was up to date, I had missed the footnote. > Additionally "Ernst Young Brazil" was listed as late as March 20, 2016 > apparently. > > https://web-beta.archive.org/web/20160320161225/http://www. > webtrust.org/licensed-webtrust-practitions-international/item64419.aspx > > The audit was dated 2017/01/24, so the historic status would be irrelevant. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 7:50:31 PM UTC-5, uri...@gmail.com wrote: > On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > > I have confirmed with CPA > > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > > licensed WebTrust practitioner, as indicated at [4]. > > > > [4] > > http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx > > > The footnote at the above makes that a little hard to understand-- > > "EY refers to a member firm of Ernst & Young Global Limited. Through a > license with Ernst & Young Global Limited all EY members are licensed to > provide WebTrust for Certification Authorities services." Additionally "Ernst Young Brazil" was listed as late as March 20, 2016 apparently. https://web-beta.archive.org/web/20160320161225/http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Friday, February 17, 2017 at 7:23:54 PM UTC-5, Ryan Sleevi wrote: > I have confirmed with CPA > Canada that at during the 2016 and 2017 periods, EY Brazil was not a > licensed WebTrust practitioner, as indicated at [4]. > > [4] > http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx The footnote at the above makes that a little hard to understand-- "EY refers to a member firm of Ernst & Young Global Limited. Through a license with Ernst & Young Global Limited all EY members are licensed to provide WebTrust for Certification Authorities services." ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, Two more question to add to the list which is already pending: In [1], in response to question 5, Symantec indicated that Certisign was a WebTrust audited partner RA, with [2] provided as evidence to this fact. While we discussed the concerns with respect to the audit letter, specifically in [3], questions 3 - 6, and while Symantec noted that it would case to accept future EY Brazil audits, I have confirmed with CPA Canada that at during the 2016 and 2017 periods, EY Brazil was not a licensed WebTrust practitioner, as indicated at [4]. Given that EY Brazil was not a licensed WebTrust auditor, it appears that Symantec failed to uphold Section 8.2 of the Baseline Requirements, v1.4.1 [5], namely, that "(For audits conducted in accordance with the WebTrust standard) licensed by WebTrust", which is a requirement clearly articulated in Section 8.4 of the Baseline Requirements, namely, that "If the CA is not using one of the above procedures and the Delegated Third Party is not an Enterprise RA, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.1, ..." 1) Was Symantec's compliance team involved in the review of Certisign's audit? 2) Does Symantec agree with the conclusion that, on the basis of this evidence, Symantec failed to uphold the Baseline Requirements, independent of any action by a Delegated Third Party? [1] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831933 [2] https://bug1334377.bmoattachments.org/attachment.cgi?id=8831929 [3] https://bug1334377.bmoattachments.org/attachment.cgi?id=8836487 [4] http://www.webtrust.org/licensed-webtrust-practitioners-international/item64419.aspx [5] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Steve, > > On 12/02/17 15:27, Steve Medin wrote: > > A response is now available in Bugzilla 1334377 and directly at: > > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 > > Thank you for this timely response. Mozilla continues to expect answers > to all reasonable and polite questions posed in our forum, and is happy > that Symantec is taking this approach. Indeed Steve, thank you for your continued attention as we try to gain the information and understanding necessary to determine how best to protect users from misissued certificates. I note that Symantec's answer to question 1 in [1] reiterates that, in Symantec's view, the set of misissuance previously was solely related to a specific internal tool, and as such, the remediation steps Symantec engaged in focused on the process and controls related to that tool. I highlight this because it seems difficult to understand the distinction between the previous event and this current event, and understanding that distinction seems relevant to understanding whether the steps Symantec took previously were reasonable and complete to address this set of issues and the community trust, as well as understanding the steps Symantec is proposing or has taken in response to this current set of issues. In the previous misissuance event, my understanding is that Symantec asserts that the whole totality of the misissuance was related to a single, specific tool. Symantec's initial response [2] was to assert that the issue was limited to rogue actions of a few individuals contrary to Symantec's policies and procedures. The proposed remediation of this was a termination of relationship with those specific individuals. However, it was pointed out by browsers based on a simple cursory examination that such a statement was not consistent with the data - that the full set of issues were not identified by Symantec in their initial investigation, and only upon prompting by Browsers with a specific deadline did Symantec later recognize the scope of the issues. In recognizing the scope, it was clear that the issues did not simply relate to the use of a particular tool, but also to the practices of employees with respect to asserting that things were correct when they were not. A specific example is that the role of Validation Specialist - which is tasked with independently reviewing the certificate request for non-compliance - was designed in such a way that it could be bypassed or overridden without following the appropriate policies. These were actions independent of any particular tooling. These issues were then amplified by the fact that Symantec was failing to ensure that its policies and practices adhered to the appropriate version of the Baseline Requirements, and that employees and staff were trained on the appropriateness of ensuring the appropriate policies were followed, regardless of the tools being employed. In response to this issue, Symantec took a series of corrective steps, such as: - A comprehensive review of its Policies and Practices to ensure compliance with the Baseline Requirements, as requested in [3] (and available at [4]) - The establishment of a centralized Compliance team to ensure compliance across Symantec branded-CAs - Internal training, which on the basis of [1] appears to have been limited to a specific tool, rather than to the overall auditable criteria or policies In the current misissuance, my understanding is that Symantec asserts that the totality of the misissuance was related to RAs. Symantec's initial response to the set of questions posed by Google [5] indicated that " At this time we do not have evidence that warrants suspension of privileges granted to any other RA besides CrossCert" in the same message that provided the CP/CPS for other RAs besides CrossCert, and itself a follow-up to Symantec's initial response to the Mozilla community, [6], which acknowledged for the potential of audit issues in the statement "We are reviewing E’s audit work, including E’s detailed approach to ascertaining how CrossCert met the required control objectives.". This appears to be similar to the previous event, in that the proposed remediation was first a termination of relationship with specific individuals. However, in Symantec's most recently reply, [1], it seems that again, on the basis of browser questions from a simple cursory examination that such a statement was not consistent with the data - that is, that the full set of issues were not identified by Symantec in their initial investigation, and only upon prompting by Browsers with a specific deadline did Symantec later recognize the scope of the issues. In recognizing the scope, it was clear that the issues did not simply relate to the use of a particular RA or auditor, but also to the practices of RAs with respect to asserting things were correct when they
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, On 12/02/17 15:27, Steve Medin wrote: > A response is now available in Bugzilla 1334377 and directly at: > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thank you for this timely response. Mozilla continues to expect answers to all reasonable and polite questions posed in our forum, and is happy that Symantec is taking this approach. Here are some additional questions, although Mozilla as always reserves the right to ask more later. Some of my questions may be similar to those posed by other group participants. * What criteria are Symantec using to judge whether the validation of a particular certificate was deficient and needs redoing? Does this process rely on an assumption that any work logs kept by the RAs are accurate records of work actually done? * When you say "Symantec authorized CrossCert to issue certificates from each of the identified CAs", do you mean all five separate certificates listed to the left of this answer in the document? Or do you mean the top list? Or the bottom list? Or something else? * When the revalidation process is complete, will Symantec be reporting on how many certificates were unable to be revalidated? * Further to your third response, can you provide a list of the certificate fields which CrossCert did or did not have control over, and whether those fields had Symantec-side validation with compliance flagging, and whether those flags could be overridden? To show what I am after, such a list might hypothetically begin: - notBefore/notAfter: no direct control - Certificate duration: control, minimum 12 months, maximum 39 months - Hash algorithm: no control - Domain name: full control, Symantec-side validation, overrideable * You write: "Further, we have deployed support for, and honor Certification Authority Authorization across all systems to put control of authorized CA’s in the hands of customers". This is great news :-) From what date has this been true? Can you confirm that CAA checking applies to all Symantec-owned brands? * Further to your answer about sampling sizes, what (in Symantec's experience) normally defines the sample size an auditor will use when sampling issued certificates during an audit? Is it a fixed number, or defined by the auditor, the issuer, or a dialogue between the two, or some other method? * http://vtn.certisign.com.br/repositorio/politicas/DPC_da_Cert isign.pdf is dated 2012. BRs section 2 say that the CP and CPS need to be annually updated. Do we understand that this did not happen in the case of Certisign? * Same question for CrossCert. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
So after reading this, the following auditors aren't trusted by Symantec anymore: - E Korea - E Brazil The following isn't trusted by Mozilla anymore: - E Hong Kong This seems to be a worrying trend to me. Kurt On 2017-02-12 20:25, Eric Mill wrote: Also relevant are Symantec's statements about two E regional auditors. One section describes contradictions from E KR (Korea) in describing why some CrossCert issuing CAs were not in scope: • The list of CAs in the audit was produced by CrossCert and given to E KR as the scope to audit. It was not given to E by Symantec. • E KR initially stated that CrossCert did not fully disclose the list of CAs. E KR later stated that CrossCert provided a list of all their issuing CAs but reduced the list of issuing CAs in scope of sampling for budgetary reasons. • Due to these conflicting statements and further discoveries explained below, Symantec will no longer accept audits from E KR. And a second section is about contradictions and delays in describing the scope of an audit that E BR (Brazil) performed on Certisign: E BR produced two deficient letters regarding the 2014 and 2015 Certisign audits. Initially we received a letter that stated a January 1, 2014 to December 31, 2014 audit period in its introduction and a January 1, 2014 to December 31, 2015 audit period in its conclusion. The letter appeared to cover a two year period. We asked for clarification multiple times. That clarifying letter stated a 2015 audit period. E BR does not meet our requirements for RA audit quality, timeliness, and responsiveness to our demands. Symantec will no longer accept audits from E BR should we have a future need for in-market audit support. On Sun, Feb 12, 2017 at 2:11 PM, Eric Millwrote: Though Nick's email implies the announcement, for the benefit of the list, here's Symantec's introduction at the top of their response: Based on our investigation of CrossCert, we have concerns due to (1) demonstrated non-compliance with processes and controls, (2) assertions of third party auditors that need far greater oversight than we previously expected, and (3) the fact that these issues have enabled cases of certificate mis-issuance. As a result, we have made the decision to terminate our partner RA program. We will continue to work with select partners that have local market contacts and expertise to facilitate an interface with customers and collection of relevant documentation, however Symantec personnel will validate 100% of all asserted identity data and control certificate issuance going forward. We have communicated this change to each of our RA partners, we are finalizing a transition plan, and intend to implement that transition quickly. In addition, to alleviate any concern by customers or relying parties on the integrity of the certificates issued by these RA partners, Symantec will review the validation work of 100% of issued certificates and revalidate any where we identify any deficiency. Certificates issued with deficient validation will be replaced and revoked. Our work will be included in scope of our next WebTrust audits. On Sun, Feb 12, 2017 at 1:02 PM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote: A response is now available in Bugzilla 1334377 and directly at: https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thanks for these responses Steve, I believe that Symantec's decision to terminate the RA Partner programme was a good one, not only in light of what's been found during this specific investigation, but also because it makes the CA function within Symantec simpler. It definitely feels as though some of the issues (big and small) with Symantec's CA function in the past few years grew out of complexity. Simpler systems are easier to correctly reason about and thus to manage properly. Simpler systems are also easier for the Root Programmes to oversee and for the Relying Parties to put their trust in. This group has fought against the presumption that "foreign" CAs are necessarily less trustworthy, but the fact is that a person who was happy with a Symantec certificate on the basis that it was issued by a famous US Corporation might have been very surprised to learn the decision to issue was actually taken by a company they've never heard of in Korea, or Brazil. Given Symantec's experiences here, I would recommend that Mozilla's routine letter to CAs might ask them if they have any similar programme and if so what measures they have in place to ensure their RAs or similar Third Parties are really living up to the standards Mozilla requires. Depending on the responses this might need further action from Mozilla. It would also make sense to ask about this during new CA enrollment. There's maybe a small piece of work here to figure out what sort of characteristics best distinguish something like Symantec's
Re: Misissued/Suspicious Symantec Certificates
Also relevant are Symantec's statements about two E regional auditors. One section describes contradictions from E KR (Korea) in describing why some CrossCert issuing CAs were not in scope: • The list of CAs in the audit was produced by CrossCert and given to E KR as the scope to audit. It was not given to E by Symantec. • E KR initially stated that CrossCert did not fully disclose the list of CAs. E KR later stated that CrossCert provided a list of all their issuing CAs but reduced the list of issuing CAs in scope of sampling for budgetary reasons. • Due to these conflicting statements and further discoveries explained below, Symantec will no longer accept audits from E KR. And a second section is about contradictions and delays in describing the scope of an audit that E BR (Brazil) performed on Certisign: E BR produced two deficient letters regarding the 2014 and 2015 Certisign audits. Initially we received a letter that stated a January 1, 2014 to December 31, 2014 audit period in its introduction and a January 1, 2014 to December 31, 2015 audit period in its conclusion. The letter appeared to cover a two year period. We asked for clarification multiple times. That clarifying letter stated a 2015 audit period. E BR does not meet our requirements for RA audit quality, timeliness, and responsiveness to our demands. Symantec will no longer accept audits from E BR should we have a future need for in-market audit support. On Sun, Feb 12, 2017 at 2:11 PM, Eric Millwrote: > Though Nick's email implies the announcement, for the benefit of the list, > here's Symantec's introduction at the top of their response: > > Based on our investigation of CrossCert, we have concerns due to (1) > demonstrated non-compliance with processes and controls, (2) assertions of > third party auditors that need far greater oversight than we previously > expected, and (3) the fact that these issues have enabled cases of > certificate mis-issuance. As a result, we have made the decision to > terminate our partner RA program. > > We will continue to work with select partners that have local market > contacts and expertise to facilitate an interface with customers and > collection of relevant documentation, however Symantec personnel will > validate 100% of all asserted identity data and control certificate > issuance going forward. We have communicated this change to each of our RA > partners, we are finalizing a transition plan, and intend to implement that > transition quickly. > > In addition, to alleviate any concern by customers or relying parties on > the integrity of the certificates issued by these RA partners, Symantec > will review the validation work of 100% of issued certificates and > revalidate any where we identify any deficiency. Certificates issued with > deficient validation will be replaced and revoked. Our work will be > included in scope of our next WebTrust audits. > > > On Sun, Feb 12, 2017 at 1:02 PM, Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote: >> > A response is now available in Bugzilla 1334377 and directly at: >> > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 >> >> Thanks for these responses Steve, >> >> I believe that Symantec's decision to terminate the RA Partner programme >> was a good one, not only in light of what's been found during this specific >> investigation, but also because it makes the CA function within Symantec >> simpler. It definitely feels as though some of the issues (big and small) >> with Symantec's CA function in the past few years grew out of complexity. >> Simpler systems are easier to correctly reason about and thus to manage >> properly. >> >> Simpler systems are also easier for the Root Programmes to oversee and >> for the Relying Parties to put their trust in. This group has fought >> against the presumption that "foreign" CAs are necessarily less >> trustworthy, but the fact is that a person who was happy with a Symantec >> certificate on the basis that it was issued by a famous US Corporation >> might have been very surprised to learn the decision to issue was actually >> taken by a company they've never heard of in Korea, or Brazil. >> >> Given Symantec's experiences here, I would recommend that Mozilla's >> routine letter to CAs might ask them if they have any similar programme and >> if so what measures they have in place to ensure their RAs or similar Third >> Parties are really living up to the standards Mozilla requires. Depending >> on the responses this might need further action from Mozilla. It would also >> make sense to ask about this during new CA enrollment. There's maybe a >> small piece of work here to figure out what sort of characteristics best >> distinguish something like Symantec's relationship with Crosscert from >> unremarkable business practices like corporate accounts to issue many >> certificates without
Re: Misissued/Suspicious Symantec Certificates
On Sunday, 12 February 2017 15:28:26 UTC, Steve Medin wrote: > A response is now available in Bugzilla 1334377 and directly at: > https://bugzilla.mozilla.org/attachment.cgi?id=8836487 Thanks for these responses Steve, I believe that Symantec's decision to terminate the RA Partner programme was a good one, not only in light of what's been found during this specific investigation, but also because it makes the CA function within Symantec simpler. It definitely feels as though some of the issues (big and small) with Symantec's CA function in the past few years grew out of complexity. Simpler systems are easier to correctly reason about and thus to manage properly. Simpler systems are also easier for the Root Programmes to oversee and for the Relying Parties to put their trust in. This group has fought against the presumption that "foreign" CAs are necessarily less trustworthy, but the fact is that a person who was happy with a Symantec certificate on the basis that it was issued by a famous US Corporation might have been very surprised to learn the decision to issue was actually taken by a company they've never heard of in Korea, or Brazil. Given Symantec's experiences here, I would recommend that Mozilla's routine letter to CAs might ask them if they have any similar programme and if so what measures they have in place to ensure their RAs or similar Third Parties are really living up to the standards Mozilla requires. Depending on the responses this might need further action from Mozilla. It would also make sense to ask about this during new CA enrollment. There's maybe a small piece of work here to figure out what sort of characteristics best distinguish something like Symantec's relationship with Crosscert from unremarkable business practices like corporate accounts to issue many certificates without them each being validated separately. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
A response is now available in Bugzilla 1334377 and directly at: https://bugzilla.mozilla.org/attachment.cgi?id=8836487 > -Original Message- > From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Thursday, February 09, 2017 4:56 AM > To: Steve Medin <steve_me...@symantec.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Cc: r...@sleevi.com > Subject: Re: Misissued/Suspicious Symantec Certificates > > On 09/02/17 03:07, Ryan Sleevi wrote: > > We appreciate your attention to these questions and will thoughtfully > > consider a response to these questions if received no later than > > 2017-02-13 > > 00:00:00 UTC. > > Mozilla also requests answers to these excellent questions under the same > terms and, for the avoidance of doubt, interprets the above as the point in > time between Sun 2017-02-12 and Mon 2017-02-13, rather than the point in > time between Mon 2017-02-13 and Tue 2017-02-14. > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Thursday, 9 February 2017 03:08:14 UTC, Ryan Sleevi wrote: > 19) Can you confirm that Certsuperior, Certisign, CrossCert, and Certisur > are the only Delegated Third Parties utilized by Symantec, across all > Symantec operated CAs that are trusted by Mozilla products? Maybe Ryan has better information than me, but I had assumed that in practice all the companies identified on their site as Symantec "Affiliates" offering SSL are or have been Delegated Third Parties under the BRs. https://forms.ws.symantec.com/verisign-worldwide/index.html I confess that I reached this supposition by Googling "Symantec Crosscert" and thinking about what I found, rather than through deep knowledge of Symantec's business or direct personal information. Symantec provides the following links for "affiliates" offering SSL https://www.acs.altech.co.za/symantec-pki https://www.egypttrust.com/ http://www.comsign.co.il/ http://www.verisign.co.jp/ http://www.crosscert.com/ http://www.itrus.com.cn/ http://www.msctrustgate.com/ http://www.mysecuresign.com/ http://www.niftetrust.com/ http://www.safescrypt.com/ http://www.adacom.com/ http://www.skyrr.is/ http://www.telefonica.es/ http://www.trustitalia.it/ http://www.certsuperior.com/ http://www.certisign.com.br/ http://www.certisur.com/ http://www.e-sign.cl/ Some of those were on Ryan's list above already, and some are defunct, but despite language barriers I think I was able to determine that some of the others are selling Symantec certificates. I suppose it's possible that they're merely acting as resellers and all validation etc. is done by Symantec, but I wanted to flag it up. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Sat, Feb 4, 2017 at 3:10 AM, Gervase Markhamwrote: > On 31/01/17 04:51, Steve Medin wrote: > > Our response to questions up to January 27, 2017 has been posted as an > > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. > > Quoting that document: > > "Q: 4) In response to the previous incident, Symantec indicated it > updated its internal policies and procedures for test certificates as > used for commercial certificates. Further, it indicated that QA > engineers and authentication personnel were trained on updated practices > for test certificates. a) Did Symantec include Registration Authorities > in the scope of that training? > > A: We did not train partners on an issue that pertained to a tool they > could not access." > > -- That seems to miss the point of the question somewhat. The problem in > the previous incident was poor practices surrounding the issuance of > test certificates, not simply the tool that was used to issue them. > > 1) Did Symantec do any additional training for RAs regarding the > issuance of test certificates after the last incident? If not, why not? > Did Symantec believe that it was very unlikely for RA personnel to make > the same mistakes or have the same misunderstandings of what was > appropriate as Symantec's personnel? > > You also write: "Category C concluded prior to that last audit’s review > period." Steve, To echo Gerv's remarks, the statement Symantec issued for the previous misissuance [1] stated: "Symantec has updated its internal policies and procedures to strongly reinforce that all test certificates must follow the same fulsome authentication procedures as commercial certificates." Section 9.8 of the Baseline Requirements, v1.4.2 states "For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated. " 1) Does Symantec believe that the original statement is sufficiently clear that it was limited solely to Symantec's role in validating, and did not extend to that of Delegated Third Parties? 2) Did Symantec management believe it was not necessary to notify and inform its Delegated Third Parties about the need and significance to conform to Symantec's CP and CPS, and of the necessity of ensuring that all issued certificates - regardless of mechanism - must follow the same fulsome authentication procedures? Similarly, the statement Symantec issued for the previous misissuance [1] stated: "Symantec updated its internal policies, procedures, and trainings to clarify the April 2014 change in the Baseline Requirements that removed authorization to issue certificates to unregistered domains." Your most recent response, [2], notes that: "RAs are required to follow the same policies as set forth in Symantec’s CP and CPS documents." Regarding Certisign: 3) The most recent version of Certisign's CP/CPS that I'm able to publicly confirm is http://vtn.certisign.com.br/repositorio/politicas/DPC_ da_Certisign.pdf , which is dated 2012. Is this the correct CP/CPS? 4) Can Symantec confirm that this is the CP/CPS that was audited? 5) Does Symantec believe that this CP/CPS is consistent with Symantec's update CP and CPS documents updated in response to the previous misissuance? 6) Does Symantec believe that the audit letter, indicated in [2], which clearly indicates that the effective criteria were based on "SSL Baseline Requirements Audit Criteria, Version 1.1", available at [3], represents a sufficient demonstration of conformance to Symantec's CP/CPS? 7) Does Symantec believe that the audit letter, indicated in [2], conducted by Ernst and Young Brazil, conforms with the professional obligations with respect to WebTrust licensing, and Symantec's obligation to ensure said compliance as part of its Delegated Third Party conformance to the Baseline Requirements' audit standards? Specifically, the requirement to use "WebTrust for CA - SSL Baseline with Network Security 2.0" for all audits whose periods begin after 1-Jul-14, which EY Brazil demonstrably did not follow? Regarding Certsuperior: Symantec has indicated that the 2016 audit of Certsuperior was qualified, as demonstrated in [4]. During Symantec's previous misissuance event, Symantec noted that: "We have also enhanced our compliance function by consolidating all compliance activities into a single group reporting directly to the head of our Website Security business unit. This change was made in January 2016; this new compliance structure includes enhanced identification, tracking, prioritization and resolution of compliance-related updates, which will help ensure that CA/Browser Forum rule changes are effectively implemented." 8) Was Symantec's compliance group involved in reviewing the qualified audit report findings? 9) Did Symantec's management
Re: Misissued/Suspicious Symantec Certificates
On 05/02/17 09:47, Gervase Markham wrote: > On 05/02/17 06:20, Peter Gutmann wrote: >> That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the >> server is advertising. Hey, it would be pretty funny if the cert auditors' >> certs were broken, but it's just the browser complaining about something >> else. > > That machine definitely needs a webserver upgrade. I contacted CPA Canada and got the following response: "Thanks for your kindly worded note. We are aware of the deficiencies and have handed the issue over to the IT group at CPA Canada. They are in the process of making changes but there have been some other issues exposed in the process, for example, getting the program to operate on a new server. The IT group is working on this project currently but at the moment I don’t have a time frame for when changes can be made." Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, On 31/01/17 03:51, Steve Medin wrote: > Our response to questions up to January 27, 2017 has been posted as an > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. It's now ten days later; are Symantec in a position to answer the next batch of questions, and also give us an update on the general progress of your investigation into CrossCert and any other RA difficulties you may have discovered? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 05/02/17 06:20, Peter Gutmann wrote: > That's not a cert issue, it's Firefox objecting to the version of SSL/TLS the > server is advertising. Hey, it would be pretty funny if the cert auditors' > certs were broken, but it's just the browser complaining about something else. That machine definitely needs a webserver upgrade. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
As a side note to the main topic, I find it curious and a little disconcerting that the referred link to the E assessement of CrossCert, (outlined in Point 2 of "Additional Follow-ups") found on the document linked by Steve (here : https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 ) uses this web address for accessing the E assessment: https://cert.webtrust.org/SealFile?seal=2168=pdf and that access this address gives a > Secured Connection Failure: SSL_ERROR_UNSAFE_NEGOTIATION status. This (webtrust) organisation which seems to run the role of certifying PKI distributing authorities (such as CrossCert, Symantec, etc) can't use a half decent security certificate for their own sites! Disappointing. p.s> Aferwards, running the address through SSLLabs Test it get's an F. See: https://www.ssllabs.com/ssltest/analyze.html?d=cert.webtrust.org Very Disappointing. Further information (you probably already know but just for competeness sake. >From their website: - What is the purpose of the WebTrust for CAs program The WebTrust for CAs program helps to ensure that proper procedures are followed in activities involving e-commerce transactions, public key infrastructure (PKI), and cryptography. In online trust and e-commerce transactions, confidentiality, authentication, integrity, and nonrepudiation are vitally important. These requirements are satisfied using PKI and SSL Certificates. A certification authority verifies the identity of an organization/entity and issues a certificate that the organization can use to prove their identity. CAs are taking an increasingly important role in the security of e-commerce. Although there are many national, international, and proprietary standards and guidelines for the use of cryptography, the management of digital certificates, and the policies and practices of CAs, these standards have not been applied uniformly. The AICPA/CICA WebTrust Program for Certification Authorities ensures that specific policies are implemented and enforced. - And this organisation can't supply valid TLS certificates for their own websites? J ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 04/02/17 14:32, Ryan Sleevi wrote: > Gerv, as the information Steve shared about their other RAs show, their > issues with RAs are not limited to CrossCert, unfortunately. Check out the > rest of the details included. Ouch. Thank you for drawing these to my attention; I had neglected to read them. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Sat, Feb 4, 2017 at 3:10 AM, Gervase Markhamwrote: > > 4) Is there any reliable programmatic way of determining, looking only > at the contents of the certificate or certificate chain, that a > certificate was issued by CrossCert personnel using their processes, as > opposed to by Symantec personnel or by another RA? > > We look forward to hearing the answers to these questions and further > updates on the situation with CrossCert. Gerv, as the information Steve shared about their other RAs show, their issues with RAs are not limited to CrossCert, unfortunately. Check out the rest of the details included. Steve: Given the many issues very clear from CrossCert's CP/CPS, and the many audit issues disclosed in CertSuperior's report, I'd like to request that you also disclose the CP/CPS for these CAs. For example, CertiSign's CP/CPS is not immediately obvious to me as to what Symantec was relying on EY to audit. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 31/01/17 04:51, Steve Medin wrote: > Our response to questions up to January 27, 2017 has been posted as an > attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. Quoting that document: "Q: 4) In response to the previous incident, Symantec indicated it updated its internal policies and procedures for test certificates as used for commercial certificates. Further, it indicated that QA engineers and authentication personnel were trained on updated practices for test certificates. a) Did Symantec include Registration Authorities in the scope of that training? A: We did not train partners on an issue that pertained to a tool they could not access." -- That seems to miss the point of the question somewhat. The problem in the previous incident was poor practices surrounding the issuance of test certificates, not simply the tool that was used to issue them. 1) Did Symantec do any additional training for RAs regarding the issuance of test certificates after the last incident? If not, why not? Did Symantec believe that it was very unlikely for RA personnel to make the same mistakes or have the same misunderstandings of what was appropriate as Symantec's personnel? You also write: "Category C concluded prior to that last audit’s review period." 2) Is your understanding that, when WebTrust audits are sampling, they sample only certificates issued during the review period? Or should they be sampling certificates issued during the entire period covered by the audit? If the latter, did their sampling (3%, isn't it?) hit any Category C certificates? How many certificates were in the sample pool? 3) To be totally clear: would it be correct to say that up until this point, examining WebTrust audits was the only mechanism that Symantec used to _check_ the conformance of their RAs to Symantec's CP/CPS and other requirements? (I see you give them software, and docs, and training, but was this the only _checking_ mechanism?) New question: 4) Is there any reliable programmatic way of determining, looking only at the contents of the certificate or certificate chain, that a certificate was issued by CrossCert personnel using their processes, as opposed to by Symantec personnel or by another RA? We look forward to hearing the answers to these questions and further updates on the situation with CrossCert. Thanks, Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
Our response to questions up to January 27, 2017 has been posted as an attachment to bug https://bugzilla.mozilla.org/show_bug.cgi?id=1334377. The direct attachment link is: https://bugzilla.mozilla.org/attachment.cgi?id=8831933. The bug report contains additional documentation supporting our response. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, January 30, 2017 12:36 PM To: Ryan Sleevi <r...@sleevi.com> Cc: Steve Medin <steve_me...@symantec.com>; Andrew Ayer <a...@andrewayer.name>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Misissued/Suspicious Symantec Certificates Steve, As captured in our private mail exchange last week, Symantec's report fails to meaningfully address each or any of the questions I raised. Google considers it of utmost urgency that Symantec share the answers to these questions, posed a week ago, and based on Symantec's multiple public statements regarding the previous misissuance. Please confirm your receipt of these questions and your intent to provide an answer to the community by end of day, so that we can consider Symantec's answers when considering appropriate next steps to protect our users. In the absence of timely information from a CA following a misissuance, it's both necessary and reasonable to consider the worst as plausible. For your reference, https://groups.google.com/d/msg/mozilla.dev.security.policy/fyJ3EK2YOP8/chC7tXDgCQAJ 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: Misissued/Suspicious Symantec Certificates
On Monday, 30 January 2017 17:52:34 UTC, Andrew Ayer wrote: > I would appreciate confirmation from Steve, but note that dev119money.com > is not currently a registered domain name. Ah yes, none of the names on that certificate currently exist in the Internet DNS: devhkhouse.co.kr and devhkautoloan.co.kr don't match anything either. Thank you for spotting this Andrew. However the names hkhouse.co.kr and hkautoloan.co.kr do exist, they are both currently registered to HK savings bank in the wealthy (and now internationally famous) Gangnam district of Seoul. 911money.com also exists, but appears to be owned by a sketchy US outfit, possibly just harvesting vaguely finance-related domains for re-sale. However, m911money.com is owned by HK savings bank too. HK Savings Bank has certificates from Symantec today, I do not know if CrossCert acted as RA for these certificates. So, I suppose that this certificate is essentially a typographical error on an enormous scale, like the (fictitious but popular) story that the UK's Guardian newspaper once managed to spell its own name in the masthead "Grauniad". On this basis I think it's reasonably likely that CrossCert is merely spectacularly incompetent, it (at least sometimes and perhaps always) did not validate DNS names before causing Symantec to issue a certificate and so as a result instead of typo-ridden applications being rejected because they wouldn't validate, bogus certificates were issued. Detecting such incompetence was Symantec's responsibility and we await any real information about why they failed to do that. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Fri, 27 Jan 2017 09:43:00 -0800 (PST) Nick Lambwrote: > On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote: > > * It's not clear what the problem is with the issuance in category > > F. I don't see any mention of "dev119money.com" in Andrew's initial > > report. Can you explain (and provide a crt.sh link)? > > https://crt.sh/?id=48539119 appears to be the certificate in question. > > The certificate is clearly bogus in that it identifies the Subject > O=test, OU=test, etc. yet real DNS names are included in the SANs. It > is not clear to me either why this is different from Category D and > so I too would appreciate more information from Steven about that. I would appreciate confirmation from Steve, but note that dev119money.com is not currently a registered domain name. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 30/01/17 12:51, Nick Lamb wrote: > CrossCert Certification Practice Statement Version 3.8.8 Effective > Date: JUNE 29, 2012 That date is interesting. The BRs require CPSes to be revised yearly. > "End-user Subscriber Certificates contain an X.501 distinguished name > in the Subject name field and consist of the components specified in > Table 5 below." > > Table 5 in CPS 3.8.8 says that the attribute Country (C) shall have > the value “KR” or not used. That seems reasonably conclusive on the face of it. I'm sure Steve will have noted this point and I hope he will address it in any further update on the CrossCert situation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Monday, 30 January 2017 11:10:00 UTC, Gervase Markham wrote: > Could you point is at the parts of the CPS or other documents which led > you to that belief? I examined a great many documents since Andrew's initial report. I think the document which originally caused me to form this incorrect assumption was CrossCert Certification Practice Statement Version 3.8.8 Effective Date: JUNE 29, 2012 this file was available from http://www.crosscert.com/symantec/certificationeng.pdf and is linked from the 2016 WebTrust audit report for CrossCert This document (which I will call CPS 3.8.8) contains a section 3.1.1 Type of Names which asserts "End-user Subscriber Certificates contain an X.501 distinguished name in the Subject name field and consist of the components specified in Table 5 below." Table 5 in CPS 3.8.8 says that the attribute Country (C) shall have the value “KR” or not used. It seemed to me that this document established that as a Relying Party I should conclude an end entity certificate with C=BD is not from CrossCert. Perhaps there's _another_ CPS somewhere else that says otherwise ? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hi Nick, On 29/01/17 12:39, Nick Lamb wrote: > 2. It had been my assumption, based on the CPS and other documents, > that CrossCert was restricted in their use of Symantec's issuance > function to C=KR Could you point is at the parts of the CPS or other documents which led you to that belief? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Sunday, 29 January 2017 02:28:53 UTC, Steve Medin wrote: > We completed our investigation of these 12 certificates by requesting > archived documentation. CrossCert was unable to produce documentation to > prove their validation as required under BR 5.4.1. We revoked all 12 > certificates within 24 hours of becoming aware of CrossCert's BR 5.4.1 > non-compliance. Our investigation continues. Several of these certificates appear, on any surface inspection, to be legitimate certificates issued to real subscribers and yet presumably CrossCert was not able to document validation. So several thoughts arise, I appreciate that you might want to do more investigation before replying Steve, not least because there are quite a few questions here - and as always I welcome feedback from other participants meanwhile. 1. The six "false positive" certificates appear unremarkable except for the coincidence of including the word "test". If CrossCert can't produce documentation to show these were validated properly, it seems likely that many or even all certificates which Symantec had believed were validated by CrossCert in fact lack such documentation. Is that not so? 2. It had been my assumption, based on the CPS and other documents, that CrossCert was restricted in their use of Symantec's issuance function to C=KR, this is cold comfort for practical purposes in the Web PKI, but it would at least help us to scope any damage. The existence of certificates with C=BD in this list shows my assumption was wrong. How (if at all) can an outsider determine if in fact CrossCert caused issuance of a Symantec certificate ? Prior to Andrew's report what _mechanical_ constraints on CrossCert's issuance were in place, in particular any beyond those which were applied to Symantec's own issuances? For example, would it have been possible for them to cause issuance of a 5-year cert? A SHA-1 certificate? To choose specific serial numbers? 3. Since we have every reason to imagine that some (or even all) of the affected certificates were issued in good faith to legitimate subscribers, it would have been nice for Symantec to alert the subscribers when their certificates were revoked. Did Symantec do this? If not does Symantec have the capability to contact these subscribers itself (e.g. email addresses, phone numbers)? If not, does Symantec contractually require of RA partners that they provide a capability for Symantec to contact their subscribers, or relay a message chosen by Symantec on their behalf ? 4. Although BR 5.4.1 says that these records are to be kept by the CA and each Delegated Third Party the obligation is on the CA (here, Symantec) to make the records available to their auditors. Is it in fact the case that this investigation is the first time Symantec has asked Crosscert for such records ? Wasn't Symantec concerned that KPMG (in a routine audit) might ask to see these records but they didn't have them ? Might not other RA partners be affected similarly ? 5. As Symantec will know from its own experience, audits have not proved to be sufficient for detecting systematic non-compliance by CAs. What measures _beyond_ the Webtrust audit did Symantec have in place to detect non-compliance by an RA partner ? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
Symantec's auditors, KPMG, completed a scan of CrossCert certificates to detect potential mis-issuance. On Thursday, January 26, 2017 at 4:08pm PST, KPMG provided a report that listed 12 problem certificates that were not in Andrew Ayer's report. We began an investigation into that certificate problem report at 6:30pm PST Thursday. Six of the certificates contained numbers in the locality, two were street addresses and four were Bangladeshi postal codes appended to the city name. Six contained the word "test" in the organization, but were false positives for legitimate organization names. We completed our investigation of these 12 certificates by requesting archived documentation. CrossCert was unable to produce documentation to prove their validation as required under BR 5.4.1. We revoked all 12 certificates within 24 hours of becoming aware of CrossCert's BR 5.4.1 non-compliance. Our investigation continues. Links: https://crt.sh/?id=16869385 https://crt.sh/?id=11199825 https://crt.sh/?id=11633501 https://crt.sh/?id=11281299 https://crt.sh/?id=11283579 https://crt.sh/?id=12504637 https://crt.sh/?id=42016028 https://crt.sh/?id=13161832 https://crt.sh/?id=13161834 https://crt.sh/?id=13161835 https://crt.sh/?id=25211067 https://crt.sh/?id=47456180 Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation 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: Misissued/Suspicious Symantec Certificates
On Friday, 27 January 2017 12:11:06 UTC, Gervase Markham wrote: > * It's not clear what the problem is with the issuance in category F. I > don't see any mention of "dev119money.com" in Andrew's initial report. > Can you explain (and provide a crt.sh link)? https://crt.sh/?id=48539119 appears to be the certificate in question. The certificate is clearly bogus in that it identifies the Subject O=test, OU=test, etc. yet real DNS names are included in the SANs. It is not clear to me either why this is different from Category D and so I too would appreciate more information from Steven about that. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hi Steve, On 27/01/17 01:30, Steve Medin wrote: > Here is an attached PDF update regarding this certificate problem report. Thanks for the update. Here are some questions: * It's not clear what the problem is with the issuance in category F. I don't see any mention of "dev119money.com" in Andrew's initial report. Can you explain (and provide a crt.sh link)? * Root Cause, bullet 2 refers to "certificates issued between July 2016 and January 2017"; is it correct that this corresponds to categories A (one of four certificates), B, D, E and F? * What processes, other than requiring and inspecting a WebTrust report, does Symantec have in place to ensure that its RAs behave in accordance with the CP and CPS of the Symantec-owned roots under which they are issuing? (Perhaps this will be covered in the report you will issue after the "additional follow-up" steps are completed?) * Do such processes include regular, occasional or any review of the audit logs which show the overriding of compliance failure flags? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
(continuing top posting for consistency) In order to clarify the potential risk/damage to the Web PKI, it would be useful to clarify the following in a later report (since this would require additional investigation): Were the web identities (DNS names etc.) in the category C, D, E and F certificates properly vetted as per the CP/CPS etc., the certificates simply replaced the vetted organization name with "test" in the X.500 distinguished name? Or were some of those issued for insufficiently (or actually incorrect) web identities? To the safety of the web PKI this makes a big difference, since if the web identities were properly and correctly vetted, then the only real danger was relying parties seeing the word "test" in some user interfaces instead of the real organization name, thus conferring less trust (failing closed). If on the other hand the web identities were insufficiently vetted, then the certificates conferred a security claim to relying parties not being shown or otherwise inspecting the O= field (failing open). On 27/01/2017 02:30, Steve Medin wrote: Here is an attached PDF update regarding this certificate problem report. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve Medin Sent: Saturday, January 21, 2017 9:35 AM To: Andrew Ayer <a...@andrewayer.name>; mozilla-dev-security- pol...@lists.mozilla.org Subject: RE: Misissued/Suspicious Symantec Certificates The listed Symantec certificates were issued by one of our WebTrust audited partners. We have reduced this partner's privileges to restrict further issuance while we review this matter. We revoked all reported certificates which were still valid that had not previously been revoked within the 24 hour CA/B Forum guideline - these certificates each had "O=test". Our investigation is continuing. 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
Re: Misissued/Suspicious Symantec Certificates
(continuing top post for consistency) For the certificates that are noted as "revoked on the day of issuance", it would (both in this and the general case), be more informative to state the revocation delay in a smaller unit of measure, such as hours (or even smaller if less than an hour). It is of cause noted, that most of the relevant timestamps are (or were at the time) recorded with a precision of 1s in published PKI objects, although parties outside the CA not have an easy way to obtain reliable copies of the revocation responses that the CA would have issued, and thus the timestamps of revocation becoming known to revocation-checking relying parties (which is different from the time that the revocation may have been also communicated to independent logging systems). On 27/01/2017 06:36, Ryan Sleevi wrote: The PDF that was stripped is available at https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 On Thu, Jan 26, 2017 at 5:30 PM, Steve Medin <steve_me...@symantec.com> wrote: Here is an attached PDF update regarding this certificate problem report. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve Medin Sent: Saturday, January 21, 2017 9:35 AM To: Andrew Ayer <a...@andrewayer.name>; mozilla-dev-security- pol...@lists.mozilla.org Subject: RE: Misissued/Suspicious Symantec Certificates The listed Symantec certificates were issued by one of our WebTrust audited partners. We have reduced this partner's privileges to restrict further issuance while we review this matter. We revoked all reported certificates which were still valid that had not previously been revoked within the 24 hour CA/B Forum guideline - these certificates each had "O=test". Our investigation is continuing. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy 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
Re: Misissued/Suspicious Symantec Certificates
The PDF that was stripped is available at https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 On Thu, Jan 26, 2017 at 5:30 PM, Steve Medin <steve_me...@symantec.com> wrote: > Here is an attached PDF update regarding this certificate problem report. > > Kind regards, > Steven Medin > PKI Policy Manager, Symantec Corporation > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve > > Medin > > Sent: Saturday, January 21, 2017 9:35 AM > > To: Andrew Ayer <a...@andrewayer.name>; mozilla-dev-security- > > pol...@lists.mozilla.org > > Subject: RE: Misissued/Suspicious Symantec Certificates > > > > The listed Symantec certificates were issued by one of our WebTrust > audited > > partners. We have reduced this partner's privileges to restrict further > > issuance while we review this matter. We revoked all reported > certificates > > which were still valid that had not previously been revoked within the 24 > > hour CA/B Forum guideline - these certificates each had "O=test". Our > > investigation is continuing. > > > > ___ > 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: Misissued/Suspicious Symantec Certificates
On Thursday, January 26, 2017 at 9:27:52 PM UTC-8, Steve Medin wrote: > Here is an attached PDF update regarding this certificate problem report. > > Kind regards, > Steven Medin > PKI Policy Manager, Symantec Corporation > The PDF file provided by Steven has been attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1334377 Direct link to pdf file: https://bug1334377.bmoattachments.org/attachment.cgi?id=8831038 Cheers, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
Here is an attached PDF update regarding this certificate problem report. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Steve > Medin > Sent: Saturday, January 21, 2017 9:35 AM > To: Andrew Ayer <a...@andrewayer.name>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: RE: Misissued/Suspicious Symantec Certificates > > The listed Symantec certificates were issued by one of our WebTrust audited > partners. We have reduced this partner's privileges to restrict further > issuance while we review this matter. We revoked all reported certificates > which were still valid that had not previously been revoked within the 24 > hour CA/B Forum guideline - these certificates each had "O=test". Our > investigation is continuing. > 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: Misissued/Suspicious Symantec Certificates
Steve, Have you had a chance to review these questions? Considering that these are all about existing practices, and as a CA should be readily available and easy to answer, I'm hoping you can reply by end of day. Please consider this a formal request from Google as part of investigating this incident. On Mon, Jan 23, 2017 at 5:58 PM, Ryan Sleeviwrote: > Steve, > > While I understand that your investigation is ongoing, this does seem > extremely similar, if not identical, to Symantec's previous misissuance. > > In that previous incident, Symantec took a number of steps - beginning > with reportedly immediately terminating the employees responsible and then > continuing to a comprehensive system overhaul, as detailed at > https://www.symantec.com/page.jsp?id=test-certs-update# > > What is particularly concerning here is that your current explanations > suggest that either they are incomplete, or that Symantec's previous > answers were either misleading or incorrect. This is extremely concerning, > and I'm hoping you can clarify with answers to the following questions, > independent of your ongoing investigation and as soon as possible: > > 1) In response to the previous incident, Symantec indicated they hold a > "no compromise" bar for such breaches in the post titled "A tough day as > leaders". [1] > a) Do you believe that the steps to "reduce privileges" represent a > consistent application of that standard? > b) If not, what additional steps are you taking, consistent with your > "no compromise" standard? > > 2) In response to the previous incident, Symantec indicated that the use > of any privileged test tool would require senior leader justification from > both QA and Production Operations teams and approvals from the heads of > Engineering and Policy Compliance. [2] > a) Did Symantec mean that this was limited to validations performed by > Symantec, and not that of Registration Authorities fulfilling the duties > pursuant to Section 1.3.2 of the Baseline Requirements? > b) At the time Symantec made this statement, did Symantec have any > Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of > the Baseline Requirements? > c) If such a statement was meant to be limited to Symantec, and not that > of Registration Authorities, why did Symantec not feel it was appropriate > to highlight that it did not extend to activities performed by Registration > Authorities? > d) If such a statement was not meant to be limited to Symantec, was such > a justification provided, and approvals granted, for the tool that allowed > such Registration Authorities to issue these certificates? > > 3) In response to the previous incident, Symantec indicated a > comprehensive review of issuance privileges was conducted to ensure only > authorized personnel have the ability to issue certificates, and that a > quarterly access review would be conducted to ensure this. [2] > a) Did such comprehensive review include that of Registration > Authorities? > b) If not, why did Symantec not disclose that Registration Authorities > were excluded? > c) Is Symantec currently performing access reviews of Registration > Authorities? > d) If so, when does Symantec expect this to be completed? > > 4) In response to the previous incident, Symantec indicated it updated its > internal policies and procedures for test certificates as used for > commercial certificates. Further, it indicated that QA engineers and > authentication personnel were trained on updated practices for test > certificates. [2] > a) Did Symantec include Registration Authorities in the scope of that > training? > b) If not, why did Symantec not disclose that Registration Authorities > were excluded? > c) If so, why did Symantec's corrective actions for the previous > misissuance fail to prevent this continued misissuance? > > 5) You have indicated that you have at least one WebTrust audited partner > capable of causing issuance using Symantec-operated CAs. > a) Please provide a link to the audit results for each of these WebTrust > audited partners. > b) Have you suspended the capabilities of these partners until Symantec > completes its investigation? > c) If not, why not, and when do you expect to do so? > > 6) Does Symantec allow is Registration Authorities to deviate from the > policies and standards set forth by its CP, CPS, and internal policies and > controls? > a) If not, why did Symantec fail to detect that its Registration > Authorities were deviating from its policies for this long? > b) If so, where does Symantec disclose this deviation within its CP > and/or CPS? > > 7) When do you expect to provide the next update as to the ongoing > investigation? If it is not within the next three days, why? > > > Thank you for your time in answering each and every one of these questions > and providing further details, so as to help inform the broader community > as to the steps Symantec has taken
Re: Misissued/Suspicious Symantec Certificates
Hi Hanno, On Tue, 24 Jan 2017 10:38:01 +0100 Hanno B__ckwrote: > Hello, > > I have a few observations to share about this incident, not sure how > relevant they are. Thanks for sharing these. I found them interesting. > There are 4 "example.com" certificates related to this incident. > > There are 114 "O=test" certificates that I assume are related to this > incident. This includes all certificates with a "Not Before" date of > 2016-10 and later. crt.sh finds various older certificates with O=test > from various CAs, but I guess they are unrelated. I count 101 distinct O=test certificates with a notBefore date of 2016-10 or later (of these, 2 also have DNS name for *test*.com; also, there are 3 certs for *test*.com without O=Test). Might you be double-counting certs and their corresponding pre-certs? Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Hello, I have a few observations to share about this incident, not sure how relevant they are. There are 4 "example.com" certificates related to this incident. There are 114 "O=test" certificates that I assume are related to this incident. This includes all certificates with a "Not Before" date of 2016-10 and later. crt.sh finds various older certificates with O=test from various CAs, but I guess they are unrelated. Issuers === The affected certificates were issued by three different intermediates owned by Symantec: Symantec Class 3 Secure Server CA - G4 thawte SSL CA - GeoTrust SSL CA - G3 Now Symantec told us these certificates were issued by one of their WebTrust partners. This got me curious if it's usual that Symantec gives their partners access to their systems in a way that they can use various different intermediates related to different brand names. This document here https://cert.webtrust.org/SealFile?seal=2168=pdf indicates that Korea Electronic Certification Authority Inc. ("CrossCert"), which is probably the partner Symantec is talking about, is allowed to issue certificates with these intermediates VeriSign Class 3 Secure Server CA - G3 VeriSign Class 3 International Server CA - G3 Symantec Class 3 Secure Server CA - G4 Which - as can be obviously seen - don't match. (nitpick: It seems the PDF doc has a bogus document title which looks like some changelog entry) Revocations === The 4 example certs were already revoked when Andrew Ayer made this incident public. From the 114 "O=test" certificates 62 were revoked at some point in 2016, so before the incident became public. 52 were revoked at some point in 2017. 37 of those were revoked on 2017-01-20, so directly afterthe incident got public. (I've counted this because in a statement sent to the media Symantec said that when they learned about this incident "most" certificates were already revoked. I feel I have a different definition of the word "most".) Other O=test certificates = A quick run through other "O=test" certs: * "Cybertrust Japan Co.. Ltd." seems to have issued a large number of them, but a few checks indicate they are issued to domains they own. Not sure if that's still considered a problem, as "O=test" is obviously a bogus org, but at least they seem to not issue certs for other people's domains. * There's one cert issued by "SHECA" which is itself an intermediate signed by "UniTrust". It's issued for a public IP. UniTrust seems to be accepted by Apple+Microsoft, but not by Mozilla+Chrome. https://crt.sh/?id=32335050 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
Steve, While I understand that your investigation is ongoing, this does seem extremely similar, if not identical, to Symantec's previous misissuance. In that previous incident, Symantec took a number of steps - beginning with reportedly immediately terminating the employees responsible and then continuing to a comprehensive system overhaul, as detailed at https://www.symantec.com/page.jsp?id=test-certs-update# What is particularly concerning here is that your current explanations suggest that either they are incomplete, or that Symantec's previous answers were either misleading or incorrect. This is extremely concerning, and I'm hoping you can clarify with answers to the following questions, independent of your ongoing investigation and as soon as possible: 1) In response to the previous incident, Symantec indicated they hold a "no compromise" bar for such breaches in the post titled "A tough day as leaders". [1] a) Do you believe that the steps to "reduce privileges" represent a consistent application of that standard? b) If not, what additional steps are you taking, consistent with your "no compromise" standard? 2) In response to the previous incident, Symantec indicated that the use of any privileged test tool would require senior leader justification from both QA and Production Operations teams and approvals from the heads of Engineering and Policy Compliance. [2] a) Did Symantec mean that this was limited to validations performed by Symantec, and not that of Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of the Baseline Requirements? b) At the time Symantec made this statement, did Symantec have any Registration Authorities fulfilling the duties pursuant to Section 1.3.2 of the Baseline Requirements? c) If such a statement was meant to be limited to Symantec, and not that of Registration Authorities, why did Symantec not feel it was appropriate to highlight that it did not extend to activities performed by Registration Authorities? d) If such a statement was not meant to be limited to Symantec, was such a justification provided, and approvals granted, for the tool that allowed such Registration Authorities to issue these certificates? 3) In response to the previous incident, Symantec indicated a comprehensive review of issuance privileges was conducted to ensure only authorized personnel have the ability to issue certificates, and that a quarterly access review would be conducted to ensure this. [2] a) Did such comprehensive review include that of Registration Authorities? b) If not, why did Symantec not disclose that Registration Authorities were excluded? c) Is Symantec currently performing access reviews of Registration Authorities? d) If so, when does Symantec expect this to be completed? 4) In response to the previous incident, Symantec indicated it updated its internal policies and procedures for test certificates as used for commercial certificates. Further, it indicated that QA engineers and authentication personnel were trained on updated practices for test certificates. [2] a) Did Symantec include Registration Authorities in the scope of that training? b) If not, why did Symantec not disclose that Registration Authorities were excluded? c) If so, why did Symantec's corrective actions for the previous misissuance fail to prevent this continued misissuance? 5) You have indicated that you have at least one WebTrust audited partner capable of causing issuance using Symantec-operated CAs. a) Please provide a link to the audit results for each of these WebTrust audited partners. b) Have you suspended the capabilities of these partners until Symantec completes its investigation? c) If not, why not, and when do you expect to do so? 6) Does Symantec allow is Registration Authorities to deviate from the policies and standards set forth by its CP, CPS, and internal policies and controls? a) If not, why did Symantec fail to detect that its Registration Authorities were deviating from its policies for this long? b) If so, where does Symantec disclose this deviation within its CP and/or CPS? 7) When do you expect to provide the next update as to the ongoing investigation? If it is not within the next three days, why? Thank you for your time in answering each and every one of these questions and providing further details, so as to help inform the broader community as to the steps Symantec has taken and is taking to prevent continued misissuance contrary to the Baseline Requirements and the Mozilla CA Certificate Policy. [1] http://archive.is/Ro70U [2] https://www.symantec.com/page.jsp?id=test-certs-update ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
The listed Symantec certificates were issued by one of our WebTrust audited partners. We have reduced this partner's privileges to restrict further issuance while we review this matter. We revoked all reported certificates which were still valid that had not previously been revoked within the 24 hour CA/B Forum guideline - these certificates each had "O=test". Our investigation is continuing. > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer > Sent: Thursday, January 19, 2017 4:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Misissued/Suspicious Symantec Certificates > > I. Misissued certificates for example.com > > On 2016-07-14, Symantec misissued the following certificates for > example.com: > > https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6 > TPEC_N7jOPRSjGhkA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902 > 4A9B9DC3C4C6 > https://clicktime.symantec.com/a/1/_X1- > P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C > F48A6117BFBFA > https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550 > RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E > 78B5679EAF48 > https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA > Ep4LXe40icNc0DLwUA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311 > C2D2794BFCD11 > > I confirmed with ICANN, the owner of example.com, that they did not > authorize these certificates. These certificates were already revoked at the > time I found them. > > > II. Suspicious certificates for domains containing the word "test" > > On 2016-11-15 and 2016-10-26, Symantec issued certificates for various > domains containing the word "test" which I strongly suspect were > misissued: > > https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r > qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0 > d416bbd21 > https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK > AfWPKKNmpvo_prjlE3Y=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 >
Re: Misissued/Suspicious Symantec Certificates
On Thursday, 19 January 2017 21:46:38 UTC, Andrew Ayer wrote: > 2. The third certificate in the list above contains a SAN for > DNS:*.crosscert.com - note that three of the misissued example.com > certificates contain "Crosscert" in their Subject Organization. Crosscert aka Korea Electronic Certification Authority, Inc. has applied to the Mozilla root programme and was identified as a "Super CA" which I understand to mean that they themselves just sign other CA certificates for third parties. Of course these certificates were issued by Symantec as a member of Mozilla's root programme, all responsibility for ensuring their CA doesn't issue bogus certificates lies with Symantec, not with Crosscert. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Misissued/Suspicious Symantec Certificates
Andrew, thank you for your efforts to report this issue. We are investigating and will report our resolution, cause analysis, and corrective actions once complete. Kind regards, Steven Medin PKI Policy Manager, Symantec Corporation > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of > Andrew Ayer > Sent: Thursday, January 19, 2017 4:46 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Misissued/Suspicious Symantec Certificates > > I. Misissued certificates for example.com > > On 2016-07-14, Symantec misissued the following certificates for > example.com: > > https://clicktime.symantec.com/a/1/LyhH99FiQBwyOqKcts8QGJ75k6 > TPEC_N7jOPRSjGhkA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DA8F14F52CC1282D7153A13316E7DA39E6AE37B1A10C16288B902 > 4A9B9DC3C4C6 > https://clicktime.symantec.com/a/1/_X1- > P9bvSq0r_QG43YQ6BwhHeeRl4IrY8ebwWh9HWiQ=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D8B5956C57FDCF720B6907A4B1BC8CA2E46CD90EAD5C061A426C > F48A6117BFBFA > https://clicktime.symantec.com/a/1/1ux2sxPZpTNuRjN4JV5qOj0550 > RDi16i7NLrqi0eFaY=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3D94482136A1400BC3A1136FECA3E79D4D200E03DD20B245D19F0E > 78B5679EAF48 > https://clicktime.symantec.com/a/1/YT02EQBzJ13G0VwF_VLruHbKA > Ep4LXe40icNc0DLwUA=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3DC69AB04C1B20E6FC7861C67476CADDA1DAE7A8DCF6E23E15311 > C2D2794BFCD11 > > I confirmed with ICANN, the owner of example.com, that they did not > authorize these certificates. These certificates were already revoked at the > time I found them. > > > II. Suspicious certificates for domains containing the word "test" > > On 2016-11-15 and 2016-10-26, Symantec issued certificates for various > domains containing the word "test" which I strongly suspect were > misissued: > > https://clicktime.symantec.com/a/1/_0lsjfT3DHqxu1QJl2eBU5zx948r > qJmGy-bHkTlww3c=?d=6VMu_T-sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- > 044fxL0XE8xRruYOPBELAZNVU7IzdE2id8hrzrFn7l2jmuWLTxkW- > AQ15CZUebkaGsbll_tyh8jDt08gBNpnPtXVKTMbDEYJw- > p1P3j3Zh6JpKCiC3jVpJ69E80VUm5h1S79Gwhy6xG1BYx6pTfwpQ3h1_jVWXz3 > NLXmybP77Lu56CC_6htKsu1YTZVPIbw%3D=https%3A%2F%2Fcrt.sh%2F% > 3Fsha256%3Db81f339b971eb763cfc686adbac5c164b89ad03f8afb55da9604fd0 > d416bbd21 > https://clicktime.symantec.com/a/1/uF90PPzN7N3_lTMmPb8YzXKK > AfWPKKNmpvo_prjlE3Y=?d=6VMu_T- > sR5eKmPW2WR2IXMmMu2l3NuU1xwSCzx- > S8H67_QVReqcePQ_O3DgBf_CHNp7acC3LqzelBaMae64LokDHJrk3XCy9cJBj7 > mWmiY1RlN6aQDk-q60Cy76Au0CHjeYa4qo0N7e7Pbcw_OwHSJmMQEw- > s1RBUJ4y6oFf9cEpLQYDcTs0wQjUve2_zzbI9paFZA- > 4MBZn0OAqSr0fdyihKQa3NGk1XSLahRHT9H7YKUQRhaX3y6FotZjUaGOWboG > oYn8PQTT6koyyBuC- >