Symantec Issues Intermediate CA Certificate for Blue Coat Public Services

Even that is silly - they don't need to be an intermediate CA to do that. Just require that their customers install a custom certificate.

If you want to MITM traffic on your network, have clients install your MITM certificate, which gives them ample warning about what you're doing.

If they have clients on their network they want to MITM then that's not a legitimate use case for a CA at all. It doesn't matter if everything is on their network, it's unacceptable that my browser accepts their signature.

The most important thing to pay attention to here, with respect to Blue Coat, is the subscriber agreement they have signed with the CA AND the CPS that they write for their auditors. It'll dictate what they are and are not allowed to do with this subCA. If these are publicly trusted certificates, they will still need to pass—at minimum—domain control validation, e.g., can BC/their customers add an arbitrary DNS record or HTTP-accessible file for the zone being issued? If not, CA/B prohibits their issuance, so Symantec would get in huge trouble for allowing this. When you run your own subCA you are supposed to perform these checks yourself; it's up to their auditors (more in a sec) and Symantec to make sure they are performing these each and every time.

Additionally, Blue Coat will need to pass a WebTrust audit as mandated by the CA/B Forum. The thoroughness of this audit depends on how much Blue Coat is taking over from Symantec. If they're, e.g., handling key material, the audit will be much the same the CAs themselves must do. If doing considerably less, the scope of the audit is considerably more constrained. I think these audits are released to the public as I remember Let's Encrypt doing so, but that may just be because i) they aren't a full blown directly browser trusted CA or ii) LE just decided to do so as it fits their ethos.

You can find the relevant regulations that are imposed on public CAs here (look specifically for references to Subscriber Agreements): https://github.com/cabforum/documents/tree/master/docs. I'd start with the "BRs" (Baseline Requirements) doc; the other, EV Guidelines are irrelevant here, and Bylaws apply to CA/B itself.

Source: I manage CloudFlare's relationship with CAs and product manage our SSL/TLS related offerings.

EDIT: Added reference to CPS, the Certification Practice Statement. This document is written and provided to the auditors, and includes controls to test, etc. Here's Symantec's for example (as linked within X509v3 in crt.sh): https://www.symauth.com/cps.

My guess is they'd settle for blocking certs issued after a specific date, at least for a transition period. The alternative would block too much of the internet.

I suspect it will be less than 18 months. And 99% of the people will be 'shocked' :-)

Yes, this may be true, but the list is quite small. You may not be able to trick Chrome into connecting to a fake google.com certificate but there's lots other "high security site[s]" as Adam Langley suggests[1] should apply when they opened this up:

> Can I get this for my site? If you run a large, high security site and want Chrome to include pins, let me know.

The reason why this list is small is because key pinning in practice is difficult — and risky. Look to comments on Twitter from Sleevi et al. as to how easy it is to shoot yourself in the foot. HPKP is a terrific idea, but has complicated implementation challenges.

[1] https://www.imperialviolet.org/2011/05/04/pinning.html

Legitimate uses of this would be things like government or military departments intercepting traffic from their own network.

As explained elsewhere in this thread, they have a history of working with regimes where they want to intercept the traffic of the general public in countries.

A good number of employer or school-provider devices will have their own certificates preinstalled anyway.

Nobody ever said privacy was convenient.

Let's Encrypt's root is not trusted by any browser yet, so they got a cross-signature from IdenTrust. So far, basically everybody using Let's Encrypt chains to the IdenTrust root.

Given that IdenTrust grew from "<0.1%" to 5.6% since the launch of Let's Encrypt, and the shape is roughly the same as https://letsencrypt.org/stats/ , I strongly suspect that the 5.6% market share credited to IdenTrust actually belongs to Let's Encrypt.

As a check, we can divide 2/3 of the total unexpired Let's Encrypt certificates (~2.8M as of last week, 2/3 because standard practise is to renew a 90 day cert after 60 days, so 1/3 are probably overlapping = 1.86M) by the total number of https sites (I had a hard time finding this, but http://arstechnica.com/security/2016/03/more-than-13-million... claims that 5.9M is 17% of https servers, so 34.7M), and we get 5.4%, which is almost the same number as the IdenTrust number above.

That's still nowhere near Comodo, but it's not completely insignificant.

I'm not even convinced it would have performance limitations. Let's say Alice and Bob are communicating and Eve has the BlueCoat device in the middle. Alice sends the initial connection request to Bob, but Eve gets it instead. Eve then sends a new initial request to Bob AND a request to the BlueCoat server to get the fake cert in parallel. As long as the BlueCoat server responds with similar latency to Bob, Alice won't see any significant difference in latency as compared to Eve simply forwarding the requests.