[Cryptography] Google distrusts Symantec for mis-issuing 30, 000 HTTPS certs

[Florian Weimer]

* Ben Laurie:

> In what sense are you trusting Google? CT provides the evidence of
> whatever Symantec did. Google say exactly what they're doing about it.
> You can verify the code does that and build it yourself if you want.
>
> Where did trust come into this?

It's very difficult to tell what is actually going on because the
Chrome team posting only says:

| Since January 19, the Google Chrome team has been investigating a
| series of failures by Symantec Corporation to properly validate
| certificates. Over the course of this investigation, the
| explanations provided by Symantec have revealed a continually
| increasing scope of misissuance with each set of questions from
| members of the Google Chrome team; an initial set of reportedly 127
| certificates has expanded to include at least 30,000 certificates,
| issued over a period spanning several years.

My interpretation is that the 127 certificates which prompted the
investigation are identifiable using CT logs, but the large majority
of those 30,000 certificates discovered later are not.

It seems that more information what is actually going can be cleaned
from this mozilla.org (!) bug:

  <https://bugzilla.mozilla.org/show_bug.cgi?id=1334377>

Comment 10 includes audits from some CAs which I suspect are
affiliated in some way with the Symantec roots.  Several of these
documents describe organizations which failed audits.  Comment 8
contains fairly substantial comments from Symantec.

Based on reviewing this information, my best guess for what is
actually going is this:

Some functionally misissued certificates where detected (a subset of
the original 127).  With “functionally misissued” I mean that the
certificate contains domains for which the owner positively confirmed
that they did not request that the certificate.  Such certificates can
indeed be recovered from CT logs, with a bit of guesswork regarding
subscriber intentions.  (Although most large organizations face
challenges enforcing stringent certificate management practices, so it
can be very difficult to rule out that an organization did *not*
request specific certificates.)

On top of the functionally misissued certificates, there are
certificates which contain apparent violations of intended constraints
on certificate contents.  These constraints are not functionally
relevant for the browser PKI.  An example would be a subject DN such
as “C=KR, ST=1, L=1, O=12, OU=1”.  Many of the original 127
certificates are in this category.

On top of that, Symantec has identified about 30,000 certificates
which are problematic as well.  I'm sure some of them contain
violations of technical constraints, and a few probably are
functionally misissued as well (based on my definition above), but
based on the information in the mozilla.org bug, I think the majority
of those 30,000 certificates are defective because they were issued
based on a broken process.  In that sense, they were formally
misissued, but there are likely no traces in the certificates
themselves that the process was incorrect.  (In other words, had the
intended browser PKI processes been followed, the net effect would
have been the same.)  Those formally misissued certificates are under
Symantec roots also used by completely different processes, but there
is no way to tell which of the certificates used an affect process and
which did not, without relying on confidential Symantec business
information.  This information is not available from the CT logs,
either.

Without a way to tell the actually affected certificates apart, the
Chrome team decided to decommission several Symantec roots.  My
interpretation is that the impact of that change goes far beyond the
set of certificates known to be affected by the process failures
identified in the mozilla.org bug report.  As far as ensuring browser
PKI compliance goes, decommissioning these roots is a conservative
approximation (all known-to-be-problematic certificates will be phased
out), but it appears that many more Symantec certificates and
subscribers will be affected.

Regarding what caused the process failure, my speculation is that
while the browser PKI guidelines where increasingly tightened
regarding CA operations and delegating powers to sub-CAs, similar
controls have not been required explicitly for the delegation of
registration authority functions.  A reasonable interpretation of the
guidelines might have been that key process elements may not be
outsourced to unaudited contractors (such as strong domain name
ownership checks, to prevent functionally misissued certificates, and
enforcement of technical constraints on certificate contents).  But
apparently, this is not entirely explicit in the guidelines.  Symantec
accidentally ran into this loophole, and several of their
contractors/business partners seem to have followed processes which do
not match the browser PKI guidelines.

I do not have an opinion at this time whether the response outlined by
the Chrome team is warranted.  I also don't know if all the
certificate-related and process-related information they reviewed is
captured in the mozilla.org bug.