[SSL Observatory] certificates for .local names [was: Re: DFN and subordinate CA domain-scoped whitelists]

[Daniel Kahn Gillmor]

On 11/09/2011 12:03 PM, Phillip Hallam-Baker wrote:
> If we have people misrepresenting results to make false claims then CAs
> have to think twice before they respond to anything knowing that it may be
> used for 'gotcha' purposes later on.

Thus far, the claim you've taken issue with appears to be:

 0) there are about 650 organizations that can sign an arbitrary
certificate that your browser would trust for any site on the network.

This is backed up by data gathered in the wild by the EFF.

If i understand your counterargument, it is:

 1) some large percentage of those organizations (400?) actually have
some boundaries that limit what they're allowed to issue.

This is backed up by a claim about the policies of the parent CAs and
their technical control over the secret key material for subordinate
CAs, not on any externally-explicit statements of scope like name
constraints.

In response to that, i did a bit of digging that turned up:

 2) some CAs were able to violate these constraints as recently as 19
months ago, to create certificates with a validity of at least 5 years.
 At least some of these certificates are still in use on the web today,
not revoked.


So the "false claim" you're concerned with seems to be that "can sign"
should be replaced with "could have recently signed", if we're willing
to believe that the subordinate CA controls are intact.  And we have
some evidence that points to the domain-scoping policies of the parent
CAs being suspect themselves.

Would you be satisfied if the EFF changed their messaging from:

  your web browsing could be compromised by errors or malice from any
  one of 650 CAs.

to:

  your web browsing could be compromised by errors or malice from any
  one of 650 CAs two years ago, and by current errors or malice from
  at least 250 of those organizations.

If not, can you propose a change in messaging that would satisfy you?

> Remember that currently there are no industry wide criteria for issue of DV
> certs. We should have some very soon, but for fifteen years it was left to
> individual CAs to make policy.

And i think it's fine for individual CAs to set policy;  that's their
job.  The problem is that X.509's single-issuer certification model
makes it difficult to eject CAs if users don't like their policies.  The
solution isn't to set "industry-wide criteria" -- it's to make it
possible and easy for users and admins and browser vendors to decide to
disregard a CA.  Good CAs should be encouraging this sort of
flexibility, so that people can leave their competitors.

> There are many CAs that share the same goal of making the Internet trust
> system more reliable and trustworthy. But don't present this as something
> that is exclusively the fault of CAs. It is not (just) the fault of the
> goalkeeper when the ball ends up in the back of the net.

I agree that there are more problems with online authentication than
just the CAs.  However, this list is about discussing problems with
X.509 in particular, and widespread CA malfeasance (or incompetence)
seems germane to the topic.

> I don't actually see any problem with .local domains using SSL. The real
> problem comes from browsers telling end users that this means a site is
> 'safe'. So one approach would be to tell browser providers that when SSL is
> used at .local sites that the user should never see a padlock icon or any
> other security indicator in primary chrome.

Sorry, but I don't think you can have this both ways.  I think you get
two choices:

 0) You can think cryptographic authentication is important on the LAN;
in this case you have to acknowledge that signing a .local certificate
by a global certificate authority really doesn't make any sense without
somehow forcing it to be scoped to a specific LAN.  i'm not convinced
that such a link-layer-scoping mechanism has ever been proposed for
X.509, much less implemented.  It's certainly not present in the
certificates gathered by the observatory project.

or

 1) you think that cryptographic authentication is *not* important for
the LAN.  In this case, there's no reason for *anyone* to create .local
certificates, let alone for a global certificate authority to do so.

It would be nice if someone from a responsible Certificate Authority
(even one that has made mistakes in the past) would stand up and say
"this doesn't make sense; good CAs won't do things this way".  It's a
little disheartening to hear consistent pushback that claims that things
are not as bad as we fear, that we just need to "trust" more in a system
that already appears to be failing in many ways, or that practices which
are pretty clearly a bad idea are actually somehow reasonable.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111109/2f2843d0/attachment.sig>