[cryptography] Auditable CAs

Ben Laurie ben at links.org
Wed Nov 30 06:24:41 EST 2011


On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray <marsh at extendedsubset.com> wrote:
> 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.

If they are not visible, why would we care whether they are in the log or not?

> 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 do not need to sign up to the plan.

> 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.

What do you mean by "auditing of sub-CAs"?

> 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.

What information does it leak that is not already leaked?

> 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.

Internal certs are not a problem, as mentioned in the paper.

> 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