Re: [cryptography] Auditable CAs

[Florian Weimer]

* Ben Laurie:

> I don't know how to answer that without just regurgitating the
> document again. You have read it, right?

I don't think it adequately addresses the "too big to fail" problem
(that is, a compromised log which cannot be retired because too much
depends on it).

> Our proposal does not require CAs or third parties to publish
> anything.

Okay, the subscriber can submit the certificate to the applicable logs.
But it's still forced publication, isn't it?

Anyway, submission by the CA seems more desirable to me because there
are fewer of them, and all of them could be told to resubmit their
certificates to other logs if it turns out that a log has to be closed
down.  It is impossible to do that when subscriber action is required.

I stand by my initial statement that if publication is the goal, browser
vendors should simply demand it because it's a fairly auditable
requirement, as far as such things go.

> Interesting proposal: two comments immediately spring to mind:
>
> 1. You probably need to allow for sending more than one certificate
> chain.

More than chain in what sense?  The default is to send what the server
presented during the last successful handshake, completely unprocessed.
However, the size constraints for TLS extensions and server certificate
chains are different, so only a subset of the chain might fit into the
extension.

It seems that there are implementations which already impose a 63K limit
on server certificate chains, so they wouldn't even need to implement
chain subsetting.

> 2. What about server farms that have a different cert per machine? Or
> CDNs?

In those cases, operators will see several certificates reported back to
them.  I expect that this days is collected like any other event log
(probably both locally on the host and centrally on a dedicated log
server).  Then someone needs to know the complete set of valid
certificates for the organization.  For many folks, this will be a
challenge, but there's really no way around that.  (Your proposal is
exactly the same in this regard.)

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Tue, Dec 6, 2011 at 10:48 AM, Florian Weimer  wrote:
> * Ben Laurie:
>
>> 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.
>
> Why wouldn't the problem we have with CAs now resurface again with the
> entity which maintains the log?  And why is a new protocol needed?
> Couldn't you just treat certificates from existing browser CAs as
> signing requests for an uber-CA which issues traditional X.509
> certificates?

I don't know how to answer that without just regurgitating the
document again. You have read it, right?

> Viewed from another perspective, "The CA must publish a list of
> certificates it has issued" is a perfectly auditable requirement (in
> particular if you specify availability and format), so if this is what
> we want, browser vendors could just make it a requirement for being on
> the root list.  However, this seems rather unrealistic at this point.
>
> Therefore, I have written a proposal for TLS extension which adds some
> additional transparency regarding the certificates which are floating
> around, without mandatory publication by the CAs or a third party.


Our proposal does not require CAs or third parties to publish anything.

>  It
> relies on the phenomenon that nowadays, we have a fair number of mobile
> devices which migrate between networks with and without a clear path,
> and sufficient local storage capacity to keep track of the certificates
> they see.
>
> 
>
> I still think the concept is sound, and some discussion in this thread
> (on TLS-intercepting proxies) makes it clear why the complexity of
> sending the entire certificate chain is necessary.

Interesting proposal: two comments immediately spring to mind:

1. You probably need to allow for sending more than one certificate chain.

2. What about server farms that have a different cert per machine? Or CDNs?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Florian Weimer]

* Ben Laurie:

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

Why wouldn't the problem we have with CAs now resurface again with the
entity which maintains the log?  And why is a new protocol needed?
Couldn't you just treat certificates from existing browser CAs as
signing requests for an uber-CA which issues traditional X.509
certificates?

Viewed from another perspective, "The CA must publish a list of
certificates it has issued" is a perfectly auditable requirement (in
particular if you specify availability and format), so if this is what
we want, browser vendors could just make it a requirement for being on
the root list.  However, this seems rather unrealistic at this point.

Therefore, I have written a proposal for TLS extension which adds some
additional transparency regarding the certificates which are floating
around, without mandatory publication by the CAs or a third party.  It
relies on the phenomenon that nowadays, we have a fair number of mobile
devices which migrate between networks with and without a clear path,
and sufficient local storage capacity to keep track of the certificates
they see.



I still think the concept is sound, and some discussion in this thread
(on TLS-intercepting proxies) makes it clear why the complexity of
sending the entire certificate chain is necessary.

(Quite deliberately, this proposal matches my first rule for evaluating
improvements to the browser PKI: if more cryptography is proposed, it
unlikely to work.)

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Seth David Schoen]

ianG writes:

> 3.  the existance of a certificate in the log is acceptable proof of
> goodness for a browser.
> 
> Is that it, in minimalist form?
> 
> In analogous terms, is this like having the browser check EFF's
> repository for a second opinion?  Or, like OCSP but expanding the
> servers to cover all certs from all CAs, and test on the
> certificates not the serial numbers?

The browser still has to validate the certificate, so appearing
in the log doesn't directly prove that the certificate is valid.

The question that this system makes the browser answer before
accepting a cert is:

  Could the site operator know about the existence of this cert?

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Marsh Ray]

On 11/30/2011 12:01 PM, Ben Laurie wrote:

On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray  wrote:


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


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


The certs I am worried about though are the certs that were issued in 
secret (e.g. Comodo and friends) and are never "publicly visible" until 
they are used in an attack.


If the attack is sufficiently targeted, it may be the case that no one 
other than the victim ever sees the cert at all. In the event of a mass 
MitM attack (e.g. *.ir), the attacker would likely have free use of his 
previously-hidden cert for at least as long as the combined reporting, 
reaction, and revocation latency.


It's not clear how this proposal is actually an improvement on the 
current system in this regard.


On the other hand, if you *did* engage the CAs and get their buy-in, 
they could pledge to update the log promptly with every cert they 
issued. Specific CA certs could be configured with this flag in the 
browser's trusted store. This would allow a missing audit proof to be 
treated as a hard stop and would seem to be a more meaningful 
distinction among CAs than the current EV scheme. (The few CAs I've 
spoken were really grasping for ways with which the 'better' CAs could 
distinguish themselves in the industry.)


Additionally, such a flag could be added to HSTS. Rather than pinning to 
a specific CA ("I will only use this one CA ever"), a site could pin 
itself to the use of a CA that promised to participate in the auditing. 
This would reduce some of the DoS potential inherent in CA pinning yet 
still allow browsers to catch that critical transition from "provably 
logged cert" to "non-logged cert".



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.


There would need to be a way for end-users to report new certs via their 
browser, much like they report browser crashes today. Wouldn't some 
users want it? I think it would be good to involve the users in this 
process as much as is practical.



they'll have to put the certs they
issue in the logs too, right?


Someone will, yes.


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.


I don't believe this is the case. It's one of the big problems with the 
system we have today.


Consider a sub-CA which is issed for the purpose of a company's 
deep-inspecting firewall (e.g., a BlueCoat). The device will use the 
sub-CA to issue new certs on-the-fly for each new website that the 
internal network clients browse to. The rest of the world (hopefully) 
never sees those certs.


Yet this log of the certs that it has generated is highly confidential. 
It contains info about the browsing history of the entire company, e.g., 
parts suppliers, financial institutions, use your imagination.


The current crop of "trusted" CAs refuse to give the names or even the 
count of the sub-CAs they've sold. They only require that the party to 
which they sell them agree in a contract to use them accordingly.


I'm all for saying that these sub-CAs need to be put on the boat to the 
island of lost toys like the toxic plastic that they are. But I wouldn't 
expect the parties that currently enjoy this privilege to go quietly. :-)


- Marsh
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[ianG]

On 28/11/11 08:00 AM, 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.



I found this rather difficult to understand, it seemed bottom-up not 
top-down.  If one strips away the techno stuff, it seems to me to reduce 
to this:


1.  all valid certificates are to be published into a publically 
viewable reliable log.
2.  a subscriber has the responsibility of identifying improper 
certificates in that log.
3.  the existance of a certificate in the log is acceptable proof of 
goodness for a browser.


Is that it, in minimalist form?

In analogous terms, is this like having the browser check EFF's 
repository for a second opinion?  Or, like OCSP but expanding the 
servers to cover all certs from all CAs, and test on the certificates 
not the serial numbers?


iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray  wrote:
> On 11/30/2011 05:24 AM, Ben Laurie wrote:
>>
>> On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray
>>  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).

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

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

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

No.

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

Thankyou.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Marsh Ray]

On 11/30/2011 05:24 AM, Ben Laurie wrote:

On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray
 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
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray  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
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Marsh Ray]

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
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Mon, Nov 28, 2011 at 9:32 PM, Chris Richardson  wrote:
> Right.  Or to think about it a different way:
>
> Facebook uses a CA-signed cert.  Users connecting to Facebook get no
> errors/warnings (assuming no one mucks with the connection)
> If someone is mucking with my connection, I get a self-signed Facebook
> cert and the appropriate warning screen.
>
> In this case, I know that that my connection is being mucked with
> because I know (ahead-of-time/out-of-band) that Facebook uses a
> CA-signed cert.
>
> If in several years, I get a cert-does-not-have-audit-proof warning
> for Facebook, how will I know if that's because
> 1. Facebook has chosen a CA that does not use the audit system
> 2. Facebook has chosen a CA that uses the audit system, but Facebook
> chooses not to participate in the audit system
> 3. Someone is mucking with my connection.
>
> The current system is no stronger than the weakest CA.  I think this
> proposal is interesting, but I'm not certain it's any stronger than
> the systems that do not participate in it

Note that the CAs do not have to participate: the holders of the certs
can register them in the logs.

So, the question is: why would Facebook not want to participate in the audit?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Chris Richardson]

Right.  Or to think about it a different way:

Facebook uses a CA-signed cert.  Users connecting to Facebook get no
errors/warnings (assuming no one mucks with the connection)
If someone is mucking with my connection, I get a self-signed Facebook
cert and the appropriate warning screen.

In this case, I know that that my connection is being mucked with
because I know (ahead-of-time/out-of-band) that Facebook uses a
CA-signed cert.

If in several years, I get a cert-does-not-have-audit-proof warning
for Facebook, how will I know if that's because
1. Facebook has chosen a CA that does not use the audit system
2. Facebook has chosen a CA that uses the audit system, but Facebook
chooses not to participate in the audit system
3. Someone is mucking with my connection.

The current system is no stronger than the weakest CA.  I think this
proposal is interesting, but I'm not certain it's any stronger than
the systems that do not participate in it

 -- Chris.

On Mon, Nov 28, 2011 at 1:46 PM, Seth David Schoen  wrote:
> Ben Laurie writes:
>
>> > How will the opt-out mechanism work so that it is not degraded by uses
>> > clicking through a warning?
>>
>> Don't quite understand the question: if you have opted out you
>> shouldn't get a warning, surely?
>
> I think that question was about unilateral client-side opt-out (users
> ignoring security warnings) rather than the organized deployment of a
> non-public CA.
>
> --
> Seth Schoen  
> Senior Staff Technologist                       https://www.eff.org/
> Electronic Frontier Foundation                  https://www.eff.org/join
> 454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Mon, Nov 28, 2011 at 6:46 PM, Seth David Schoen  wrote:
> Ben Laurie writes:
>
>> > How will the opt-out mechanism work so that it is not degraded by uses
>> > clicking through a warning?
>>
>> Don't quite understand the question: if you have opted out you
>> shouldn't get a warning, surely?
>
> I think that question was about unilateral client-side opt-out (users
> ignoring security warnings) rather than the organized deployment of a
> non-public CA.

Ah, well, I agree that having a reliable certificate infrastructure is
not the only problem to be solved.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Seth David Schoen]

Ben Laurie writes:

> > How will the opt-out mechanism work so that it is not degraded by uses
> > clicking through a warning?
> 
> Don't quite understand the question: if you have opted out you
> shouldn't get a warning, surely?

I think that question was about unilateral client-side opt-out (users
ignoring security warnings) rather than the organized deployment of a
non-public CA.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Mon, Nov 28, 2011 at 10:39 AM, Chris Richardson
 wrote:
> Today, a site operator can opt-out of the CA system by using a
> self-signed certificate.  When users go to the site they get a warning
> that they blindly click-through.  This degrades one of the main
> benefits of the CA system.
>
>> Browsers will need to require (at some point in the future) that all public 
>> certificates are
> accompanied by an audit proof
>> CAs that are added to the trust root by users or administrators can opt out 
>> of public audit
>
> How will the opt-out mechanism work so that it is not degraded by uses
> clicking through a warning?

Don't quite understand the question: if you have opted out you
shouldn't get a warning, surely?
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Chris Richardson]

Today, a site operator can opt-out of the CA system by using a
self-signed certificate.  When users go to the site they get a warning
that they blindly click-through.  This degrades one of the main
benefits of the CA system.

> Browsers will need to require (at some point in the future) that all public 
> certificates are
accompanied by an audit proof
> CAs that are added to the trust root by users or administrators can opt out 
> of public audit

How will the opt-out mechanism work so that it is not degraded by uses
clicking through a warning?

 -- Chris

On Sun, Nov 27, 2011 at 6:09 PM, Ben Laurie  wrote:
> On Sun, Nov 27, 2011 at 10:54 PM, Tom Ritter  wrote:
>> So my biggest question is what defines a "publically visible
>> certificate"?  Of course every certificate gmail uses would be
>> public... but what about the cert that corresponds to the new product
>> google is launching that's in beta for a few users?  That cert should
>> be published... but then that lets the cat out of the bag.  (Isn't
>> this almost the same problem DNSSEC has?)  I'm confused about whether
>> people opt-in, or opt-out, or opt-anything.
>
> Google has two options, I think.
>
> 1. Tell the few users to ignore the scary warning.
>
> 2. Ask the few users to configure a secret log that validates the beta cert.
>
>>
>>> Similarly it might be> possible to allow an intermediate CA to create
>>> private certificates within a subdomain - in this case> the intermediate CA 
>>> certificate would have to be logged
>>> along with which domain it could create> subdomains in, so that mis-issues 
>>> can still be detected.
>>> For example, an X.509 extension specifying> the permitted domains could be 
>>> included in the certificate.
>>
>> Wouldn't this be easier done with NameConstraints?
>>
>> -tom
>> ___
>> cryptography mailing list
>> cryptography@randombit.net
>> http://lists.randombit.net/mailman/listinfo/cryptography
>>
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Ben Laurie]

On Sun, Nov 27, 2011 at 10:54 PM, Tom Ritter  wrote:
> So my biggest question is what defines a "publically visible
> certificate"?  Of course every certificate gmail uses would be
> public... but what about the cert that corresponds to the new product
> google is launching that's in beta for a few users?  That cert should
> be published... but then that lets the cat out of the bag.  (Isn't
> this almost the same problem DNSSEC has?)  I'm confused about whether
> people opt-in, or opt-out, or opt-anything.

Google has two options, I think.

1. Tell the few users to ignore the scary warning.

2. Ask the few users to configure a secret log that validates the beta cert.

>
>> Similarly it might be> possible to allow an intermediate CA to create
>> private certificates within a subdomain - in this case> the intermediate CA 
>> certificate would have to be logged
>> along with which domain it could create> subdomains in, so that mis-issues 
>> can still be detected.
>> For example, an X.509 extension specifying> the permitted domains could be 
>> included in the certificate.
>
> Wouldn't this be easier done with NameConstraints?
>
> -tom
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Auditable CAs

[Tom Ritter]

So my biggest question is what defines a "publically visible
certificate"?  Of course every certificate gmail uses would be
public... but what about the cert that corresponds to the new product
google is launching that's in beta for a few users?  That cert should
be published... but then that lets the cat out of the bag.  (Isn't
this almost the same problem DNSSEC has?)  I'm confused about whether
people opt-in, or opt-out, or opt-anything.

> Similarly it might be> possible to allow an intermediate CA to create
> private certificates within a subdomain - in this case> the intermediate CA 
> certificate would have to be logged
> along with which domain it could create> subdomains in, so that mis-issues 
> can still be detected.
> For example, an X.509 extension specifying> the permitted domains could be 
> included in the certificate.

Wouldn't this be easier done with NameConstraints?

-tom
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Auditable CAs

[Ben Laurie]

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.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography