[cryptography] Auditable CAs

Marsh Ray marsh at extendedsubset.com
Wed Nov 30 12:16:06 EST 2011


On 11/30/2011 05:24 AM, Ben Laurie wrote:
> On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray<marsh at extendedsubset.com>
>  wrote:
>>
>> 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?

I guess I don't understand what you mean by 'publicly visible certs' in
the sentence:
> Firstly, every publicly visible certificate should be published in a
> publicly auditable certificate log.

Perhaps you define this category of "publicly visible certs" as "certs
which display without warnings on default-configured browsers when
presented by the correct site".

Which today is the same set as "certs issued by a browser-trusted CA or
sub-CA" and this set makes up the great majority of secure sites people
visit. Server operators generally don't buy certs from CAs for any
reason other than to ensure their site will display without cert errors
in default-configured browsers. (Of course they may have a deeper
appreciation for the security model as a whole).

So it basically amounts to "all certs that a default-configured browser
should accept" which is approximately "all certs issued by
browser-trusted CAs or sub-CAs today", i.e. "valid certs".

On the other hand, one could interpret this category of "publicly
visible certs" as "certs visible to the public", i.e., "certs served by
legitimate servers on routable IPs located via public DNS". But this
interpretation would be much weaker (and I don't think that's what you
mean).

Do I have this right?

> CAs do not need to sign up to the plan.

The title of the email is "Auditable CAs", so I started with the
impression that some part of this plan involved auditing as a property
of the CA itself. But this doesn't seem to be the right interpretation.

The goal is said 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" and "each certificate issued
must be accompanied by an audit proof".

But the proposal does nothing _directly_ to prevent a CA from issuing a
cert, right? And since browsers aren't logging the certs as they find
them, this doesn't inform the owner of the domain either.

Instead it seems to be a hoped-for effect of "default-configured
browsers will raise hell if they are presented with a non-logged cert
and CAs will feel compelled to go along with the audit logging".

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

If sub-CA-issued certs are to continue to display without warnings by
default-configured browsers, then they'll have to put the certs they
issue in the logs too, right?

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

Wouldn't they have to put the certs they sign in the public log? They
don't have to do this today.

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

It would probably be worth describing how internal logs for internal CAs
would work. It could be rather simple, like the audit proof identifies
the specific log in a manner that makes it straightforward to publish
via an internal network.

I am liking this plan.

- Marsh



More information about the cryptography mailing list