Also relevant are Symantec's statements about two E&Y regional auditors.
One section describes contradictions from E&Y 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&Y KR as the scope to audit. It was not given to E&Y by Symantec. • E&Y KR initially stated that CrossCert did not fully disclose the list of CAs. E&Y 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&Y KR. And a second section is about contradictions and delays in describing the scope of an audit that E&Y BR (Brazil) performed on Certisign: E&Y 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&Y BR does not meet our requirements for RA audit quality, timeliness, and responsiveness to our demands. Symantec will no longer accept audits from E&Y BR should we have a future need for in-market audit support. On Sun, Feb 12, 2017 at 2:11 PM, Eric Mill <e...@konklone.com> wrote: > 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 them each being validated separately. >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
