Symantec CA Response to Google Proposal and Community Feedback

> Embedded devices that are pinned to certificates issued by a Symantec public root to communicate to resources over the Internet or Intranet. Replacing these certificates would result in immediate failures and the need to recode and reimage the firmware for these devices.

> Mobile applications that have pinned certificates. Replacing server certificates would require these applications to be recoded, recompiled and redistributed.

Are either of these relevant? Isn't google's proposal to eventually have Chrome stop trusting the Symantec CA system? That change seems like it would have no effect on 1) embedded devices that aren't running Chrome 2) things that already are in place that trust the CA.

Ah, yes. If you didn't have a backup cert from another provider and missed your 60 day window. But what was your plan for any other incident that required revocation? I assume anyone turning on pinning hand wrings over it for a while first.

No, there's a huge difference. The difference here is that the Manufacturers and the Carriers are gatekeepers to the customer's phones.

The manufacturer made customizations to Android for their phone. Android isn't a cleanly-separated stack where the manufacturer modifies only a certain part of the stack for their phone but Google could go and update another part without risk of breaking anything (is any software project?)

Then, the manufacturers sell the phones to carriers, who usually request extra customizations to (at best) add their logo, or replace default apps with the carrier's own version. This means that any updates to Android likely require updates to this customization.

But even if that customization was free (from a development perspective), Carriers still have maintenance/service contracts with the manufacturers such that any manufacturer's updates must go through the carrier's "quality control" procedure. You wouldn't want an update to make the, say, LTE radio misbehave and break the carrier's network would you? Oh no... (and you certainly wouldn't want to "forget" to replace the good default app with the Carrier's crappy one)

So there you go, a quick glimpse into the complex economic/contractual obligations that delays or blocks Android updates. FWIW, Google has been working both technically and contractually to untangle this mess, and is one reason for the existence of their "own" line of Nexus and now Pixel phones.

This comment irritates me.

1) The point of the first part of their post is not "we're too big", it's "a move like this would disrupt the lives of an awful lot of people." Even more so, consider what would happen if Google were to update Chrome to not accept these certs. For internal applications, the IT departments of all these companies—which likely total a few hundreds of thousands of users in total—would simply mandate that Chrome is no longer an acceptable browser. For external applications, companies would have to engage in an enormous PR effort to communicate to customers that their product doesn't work with Chrome. These companies have done nothing wrong, but they're the one being punished, as customers don't know and don't care about cert issues.

2) "Updating" can be an enormous effort. As the blog post states explicitly, there are a lot of use cases where updating a deployed app is very difficult, almost impossible, or cost prohibitive. Again, remember that the person being punished here is not Symantec; you're publishing some poor development company who happened to use Symantec—one of the most popular cert providers on the planet—for an SSL cert. Not good.

I'm not taking sides on the issue, because I honestly don't know that much about it. But comments like the above really trivialize the huge impact that something like this will have.

For some reason, technical professionals associated with large organizations seem to actively enjoy pretending that basic upkeep is beyond the means of their organization (or has a poor value proposition). I suspect that it comes from a perverse enjoyment of being "pragmatic" in the face of "idealism" but really they're just saying "My org refuses to pay the costs associated with correctly operating the technologies it uses". If you're going to take that attitude, you need to expect that your bluff is going to be called from time to time and you'll have to do some large, unscheduled projects when it happens... that's what being pragmatic actually means: recognizing the positive and negative effects of your options and owning the whole package.