Re: [cryptography] Auditable CAs
On Tue, Dec 6, 2011 at 10:48 AM, Florian Weimer fwei...@bfk.de 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. http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00 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
* 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. http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00 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 Weimerfwei...@bfk.de 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
On Wed, Nov 30, 2011 at 1:18 AM, Marsh Ray ma...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Auditable CAs
On 11/30/2011 05:24 AM, Ben Laurie wrote: On Wed, Nov 30, 2011 at 1:18 AM, Marsh Rayma...@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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Auditable CAs
On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray ma...@extendedsubset.com wrote: On 11/30/2011 05:24 AM, Ben Laurie wrote: On Wed, Nov 30, 2011 at 1:18 AM, Marsh Rayma...@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). 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
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
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
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 b...@links.org wrote: On Sun, Nov 27, 2011 at 10:54 PM, Tom Ritter t...@ritter.vg 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
On Mon, Nov 28, 2011 at 10:39 AM, Chris Richardson ch...@randomnonce.org 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
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 sch...@eff.org 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
On Mon, Nov 28, 2011 at 6:46 PM, Seth David Schoen sch...@eff.org 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
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 sch...@eff.org 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 sch...@eff.org 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
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
Re: [cryptography] Auditable CAs
On Sun, Nov 27, 2011 at 10:54 PM, Tom Ritter t...@ritter.vg 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
