[cryptography] Auditable CAs

Marsh Ray marsh at extendedsubset.com
Tue Nov 29 20:18:39 EST 2011


On 11/27/2011 03:00 PM, Ben Laurie wrote:
> Given the recent discussion on Sovereign Keys I thought people might
>  be interested in a related, but less ambitious, idea Adam Langley
> and I have been kicking around:
> http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf.

Some questions and first impressions.

> Firstly, every publicly visible certificate should be published in a
> publicly auditable certificate log

Isn't this something of a truism?
What constitutes a "publicly visible" cert?

Certs that are on public servers today are likely to be logged in SSL
Observatory and by other crawlers. Certs that are not on servers can
still be used to attack secure communications without warning.

Perhaps the relevant property is "certs issued by a browser-trusted CA
or subordinate" regardless of their visibility.

Which brings us right to the goal:
> to make it impossible (or at least very difficult) for a Certificate
> Authority (CA) to issue a certificate for a domain without the
> knowledge of the owner of that domain.

Why would CAs sign up for this plan? Of what advantage is it for them?

CAs are currently engaged in the practice of selling sub-CAs. This plan
would require auditing of sub-CAs as well in order to be effective.

Yet CAs today refuse to disclose even *the number* of sub-CAs they have
issued, much less to whom they have issued them, much less the specific
certs that those sub-CAs have issued.

My impression is that some of the sub-CAs are used for purposes like
deep-inspecting firewalls around large corporate and governmental
networks. (At least, that's one of the few halfway-legitimate arguments
I can think of for their existence.) These systems issue new certs
on-the-fly as outgoing connections request new websites. In such a case
the firewall would have to updated to accommodate the audit log
requirement, but that's a solvable problem. The maybe-impossible problem
to solve is that this explicitly public audit log now represents a major
information leak from the company that's very concerned about its security.

If CAs were willing to give up the sub-CA business, they could do it
today and we'd all be much better off. On the other hand, if they are
unwilling to give it up or impose public log requirements upon it, it
represents a big challenge to this proposal.

Google/Mozilla could perhaps give the CAs an ultimatum: adopt this or we
de-list you (or equivocate about your sites' trustworthiness in our
browser UI). But what if the CAs in the CA/B Forum collectively decide
to call their bluff? Like in some European-style electoral process, the
minority browser vendors, (e.g. Microsoft), start to look pretty
important here.

And of course, not all of the trusted root CAs are in it for the money.
Some of them are self-declared (or thinly-veiled) government agencies.
They likely issue a lot of internal certs and would prefer not to share
their internal DNS with the world. But who knows? Maybe they'd be
willing, at this point, to trade some capabilities for better security
overall.

So I think the namespace scoping part of the proposal ("allow an
intermediate CA to create private certificates within a subdomain")
would be essential to its adoption. But, again, scoping could have been
implemented for CAs a long time ago if the will existed to do it.

Perhaps I'm just re-stating the obvious: change is likely to be opposed
by those who benefit from the status quo.

Distributing the log data in a way that is simultaneously authenticated, 
highly-available, bounded in its latency of updates, low-bandwidth, and 
does not represent a privacy leak is likely to be an interesting 
engineering challenge. (In comparison, consider the minor privacy leak 
caused by the much simpler HSTS scheme.)

But I would really like to see something like this adopted because I
think a public audit log would be a great improvement to security and
would go a long way toward restoring the public trust.

- Marsh



More information about the cryptography mailing list