[c3t0]

> This action was unexpected, and we believe the blog post was irresponsible.

Problems since Oct 2015 and the action unexpected? see 1)

> We hope it was not calculated to create uncertainty and doubt within the Internet community about our SSL/TLS certificates.

Symantec took no ownership of the issue. Snarky underhanded remarks are not a professional way to address shortcomings in managing their product.

> For example, Google’s claim that we have mis-issued 30,000 SSL/TLS certificates is not true. In the event Google is referring to, 127 certificates – not 30,000 – were identified as mis-issued, and they resulted in no consumer harm.

Per Chrome's team an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years see 2)

Summary: No ownership and no action plan conveyed in Symantec's 421 word message.

1) https://security.googleblog.com/2015/10/sustaining-digital-c...

2) https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

[tyingq]

From your 1) link...

"23 test certificates had been issued without the domain owner’s knowledge covering five organizations, including Google"

Guess that explains part of why this particular CA incident has Google's full attention.

[ballenf]

My take is this message was written by and for lawyers. As in, this is a coded message from Symantec to Google regarding the basis of damages upon which they will sue Google if Google doesn't backtrack.

The snarky comments were probably not meant as snarky, they just happen to be the basis upon which one can seek damages from a 3rd party for damaging your business or costing you customers.

I would guess that Symantec's lawyers and O-level execs are in deep discussions whether to sue regardless of Google's follow-up actions or retraction.

Not saying a lawsuit would help them, but they are laying the groundwork for it here to keep their options open. And send a message to Google's legal team.

Will be very interesting to see where this goes. Really hope for everyone's sake it doesn't go to court because it will just end up being a tax on users in the end (both Google's and Symantec's).

[bubblethink]

How would there be any grounds for a lawsuit ? The browser is free to implement whatever set of features it wants. Not trusting a specific CA is just a feature (or a bug), whichever way you look at it. A CA is just providing a service on the web. A service can't sue a browser for not supporting the service. Symantec is free to create its own browser that trusts its CA.

[otterley]

I could see a cause of action based on a libel theory or tortious interference with business affairs. Not sure it'd prevail, but there's possibly a prima facie case there.

[tankenmate]

The question is, was there a contract signed? A verbal contract? Is there an implied contract? Tortious interference?

[dadrian]

Antitrust

[rblatz]

Can Symantec really sue google for no longer trusting them after issuing fraudulent google certs? Additionally even if they didn't and google just didn't like Symantec and decided to no longer trust them, would Symantec have any real case if they sued? I'd think not, google owes Symantec nothing.

[lazulicurio]

IANAL, but it seems that one could make a passable argument for tortious interference[1]. Google isn't just affecting their B2B relationship with Symantec, they're using their share in the browser market to affect Symantec's relationship with Symantec's customers.

[1] https://en.m.wikipedia.org/wiki/Tortious_interference

[caf]

That cuts both ways, Symantec is using their share in the certificate market to affect Google's relationship with their customers.

[lazulicurio]

I'm supportive of Google in this fight, but I really don't think Google would have an argument to counter-sue. Tortious interference isn't just having an effect on the relationship, you also need to have an actual tort involved. In this case Symantec could argue that Google was exaggerating the negative PR, and Symantec would probably have an easier time proving damages (from customers leaving due to their certificates being phased out). I'm not sure what tort Google could claim in response that Symantec performed. Maybe issuing the unauthorized test certificates for Google's domains? (some sort of fraud?) But IM(NAL)O that's a tough sell.

[stordoff]

I'd argue that by advertising browser compatibility[1], meeting the browser trust requirements is implicitly part of the business relationship, thus Google enforcing them does not give rise to tortious interference. (FWIW, I studied English law, but that was some years ago and I am largely unfamiliar with tortious interference)

[1] "브라우저 호환성 99.9%" http://www.crosscert.com/symantec/02_0_00.jsp

[ryanmarsh]

If so I can't wait to see what comes out during discovery. My gut tells me Symantec will not come out smelling like roses.

[Manishearth]

It doesn't even really have to do with google certs per se, it has to do with certs in general and the situation probably would not be different if the bad certs had nothing to do with google.

There are rules for inclusion in Google's cert store, and those rules were broken IIRC.

[chillydawg]

Even if they sued and won, google could pay any damages out of petty cash. You'd have to be extremely sure of yourself to try and sue google.

[hackcasual]

I believe the 30,000 is from how many certificates 3rd parties validated for Symantec, without keeping adequate records or controls in place.

[ploxiln]

I think this is it. I think it needs to be worded: "There are 30,000 certificates which no one knows for sure the validity of, and thus need to be revalidated." The 127 merely proved that misissuance was quite possible, and did happen numerous times.

EDIT: I think that's really the crux of the issue. These 127 certs which Symantec claims are "harmless" are merely the ones which were stumbled across and obviously very "how is this even possible" wrong.

That's why the 30,000 is the "size of the risk". The big "Symantec" problem is that there's no good way to distinguish these 30,000 from the many more certificates issued by Symantec under different brands. For Google it's all-Symantec-or-nothing. So they're coming up with measures that apply to all-Symantec.

[richardwhiuk]

Any further detail from Ryan or anyone else involved here would be very helpful (their are plenty of other organizations who bootstrap based on Google/Mozilla/Microsoft/Apple's root CA program)

[ploxiln]

I think the best summary I can link to is here: https://groups.google.com/d/msg/mozilla.dev.security.policy/...

Though it doesn't mention the 30000 certs or 127 certs, it does say:

(long quote from Ryan Sleevi:)

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&Y’s audit work, including E&Y’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 were not.

It appears that, similar to the Testing Tool's failure to ensure that certificates were adhering to the fulsome standards of authentication, Symantec's newly established compliance team was failing to perform even a cursory review of the CP, CPS, and audit statements presented - despite Symantec having found it necessary in that introspective process themselves in response to [3], as noted above.

Symantec's also stated that, in response to the past misissuance, it deployed a compliance assessment tool, which functionally serves a role similar to a Validation Specialist. However, such compliance assessment was designed in a way that it could be bypassed or overridden without following appropriate policies.

[tptacek]

The short summary of what's going on here:

The major CAs outsource to partner companies called Registration Authorities (RAs) to perform the task of verifying that people requesting certs are who they say they are --- this is especially important for markets where the company running the CA is has thin on-the-ground support. Such is the case with Symantec/Verisign and CrossCert, their partner RA in Korea.

The technical relationship between the RA and the CA probably varies a lot from firm to firm, but generally the RA has some ability to cause issuance of certificates through automated requests to the CA's infrastructure.

What Ryan and others discovered in repeated rounds of questioning to Symantec was that Symantec had been relying entirely on 3rd party WebTrust audits (these are technical and process audits for CAs conducted by Big 5 accounting firms) without doing any of its own technical due diligence. But the WebTrust audits Symantec's RA's had been doing were delivered by auditors nobody has any faith in, including (as it turns out) Symantec.

Further, Symantec was required to have technical and process controls for specific kinds of issuance requests from their RAs. And it did. But it turned out those controls were designed so that the RAs could override them on their own recognizance. Which is basically the same as running process controls on the honor system --- not OK in this environment.

[bigiain]

Didn't E&Y feature as auditors in the WoSign/StartCom incident as well? Perhaps that decision to only refuse to accept audits from the Hong Kong branch of E&Y wasn't such a great idea...

[tialaramex]

_Some_ major CAs outsource like this. You need this sort of on-the-ground stuff, particularly human employees who can speak the local language and understand local culture, to validate certain subject details, it's not important for the domain validation that most of us care about most of the time. Knowing if the subscriber is really Foo Corp of Shanghai, requires local knowledge, but checking foo-corp-shanghai.example is controlled by the subscriber needs, at the very most, a translated web page of instructions which you can out-source.

It is likely Mozilla policy (or the BRs) will forbid letting the local RA do the domain validation. So, a future CrossCert could lie about whether their subscriber is really Foo Corp, but not about whether they control foo-corp.example

Oh, and it's not the Big Five any more, one of the Five collapsed in scandal because it happily signed off on Enron's obviously bogus accounts. So now we have a Big Four, until another one blows up. For those taking bets, the RA was audited by a local EY, whereas Symantec are audited by a KPMG.