[cryptography] Auditable CAs
ben at links.org
Wed Nov 30 13:01:09 EST 2011
On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
> 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>
>>> 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
Although I rather like your first definition, this one seems closer to
the truth: it may be that some sites which currently validate
correctly in default-configured browsers would choose not to in our
However, for this second class the certs are already public, and so
there does not seem a reason to choose not to participate, at least on
> 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".
CAs do not have to go along with anything, the log will accept a cert
from anyone - which obviously includes the owner of the cert.
>> 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?
Someone will, yes.
>>> 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.
No, but their certs are already publicly visible 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.
The obvious way to do it is to allow the setting of an alternate log
location in a CA cert installed into the trust store. Logs could also
be separately configured.
> I am liking this plan.
More information about the cryptography