7 ms·

Turkish government agency spoofed Google certificate “accidentally”

104 points by 6thSigma 14y ago

sc68cal 14y ago
In previous instances (like Comodo), I can recall discussions on the Mozilla mailing lists about the so called "death penalty" of revocation for CAs who have demonstrated serious lapses. I think this situation is even worse. Forgive me for sounding paranoid but this sounds like collusion between the government of Turkey and Turktrust, to intercept communications. I believe that the harshest penalty should be pursued, which is removal of the Turktrust root certificate from all trust databases. They cannot be trusted. EDIT: It appears that Mozilla is on the same page as I am. https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/ https://blog.mozilla.org/security/2013/01/03/revoking-trust-... https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/aqn0Zm-KxQ0 https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... Another good idea mentioned on the mailing list was to blacklist the auditor: https://groups.google.com/d/msg/mozilla.dev.security.policy/aqn0Zm-KxQ0/OOMOOFBKXoAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...
- cheald 14y ago
  I'd agree. We have plenty of CAs - killing a few off here and there isn't going to harm our ability to manage certificates, and those that make these kinds of mistakes - intentionally or otherwise - aren't worth the trouble of having them around. A couple of CAs being revoked for slipping the wrong certs to the wrong parties is only going to make other CAs triple check their work before handing out the keys to the kingdom.
  - tptacek 14y ago
    No, it won't harm our ability to manage certificates. What it will do instead is create a point in time where suddenly a whole mess of websites that used to be protected with HTTPS are now no longer protected with HTTPS. If there's a graceful and safe way to provide effective advance notice for this, I haven't heard it yet. I agree in spirit; I'd like to see more CA's get the death penalty. But the pragmatic argument against it is convincing.
    - cheald 14y ago
      This seems like a problem that could be pretty easily solved by the browser vendors, similar to how they do malware checks. Throw up a "this site's security certificate was issued by a compromised authority, and will no longer be valid in <x time at y date>. If this is your website, click here for more information." Run that for a sufficiently long period of time, then kill the CA. It's not perfect, but we have a huge web of people using these affected sites on a daily basis who can serve as a very powerful driving force to spur change when necessary to minimize fallout.
    - sc68cal 14y ago
      While I agree with you about pulling the rug out from users - if the CA is already forging certificates for important domains, then how much security do they really have?
      - dustingetz 14y ago
        right now only the turkish government can do MITM - other parties can't.
        jacquesm 14y ago
        > right now only the turkish government can do MITM - other parties can't. First, if true that's a small comfort. Second, how do you know that is true?
        danielweber 14y ago
        It's in the Turkish government's to use these invalid certs as little as possible, so they are probably going to use them against people like Turkish dissidents. (I don't mean to dismiss their interests, but they are distinct from other people's interests.)
      - tptacek 14y ago
        More than they do if the whole CA is removed. Sorry, annoying but true. Promote TACK!
- biturd 14y ago
  I don't think you are paranoid. They went from a "mistake" in issuing a "testing" certificate that managed to propagate through their system that just "happened" to be sitting around and configured in a way to be ready to execute a MITM configuration. To me, the chances of that happening seem challenging at best. To have it happen automatically and without hitch or fail, seems highly improbable.
meaty 14y ago
Doesn't surprise me. Even if it was an accident, it's improbable. Then again, back in the dark ages, we found that if NT3.51 was under heavy load, it was possible to generate two identical guids in under 2 hours of wall time.
- ommunist 14y ago
  It is probable. Just the probability is low. But it could happen.
- GIFtheory 14y ago
  It's also worth noting that Turkey's government routinely blocks Google services (especially youtube) for hosting "offensive" content (e.g.: http://www.huffingtonpost.com/2010/06/08/turkey-blocks-google-serv_n_604148.html http://www.huffingtonpost.com/2010/06/08/turkey-blocks-googl...). So, a sinister explanation is even less far-fetched for Turkey in particular.
deleted 14y ago
[deleted]
tptacek 14y ago
I believe them. If you're going to use a malicious certificate to spoof traffic, you'd be pretty dumb to start by targeting Google, since all their properties are pinned in Chrome. You'll just get caught. Also, using X.509 CA=YES certificates to mint new certificates on the fly is a standard and legitimate feature of corporate network hardware. In virtually every large enterprise network, employees don't have direct access to the Internet; they bounce through proxy servers. The middleboxes that make this work all have "upload a root CA cert here" features to make this work. That they accidentally issued a malicious certificate, I think, makes things a little worse from my vantage point. There are a million ways to get hacked, but not as many excuses for just being sloppy.
- revelation 14y ago
  I'm fairly confused by your stance here. I was expecting you to tell us that a) security with backdoors is worthless (intermediate CAs, for use in packet inspection devices, not merely proxies) and b) security without control (and repercussions) for those that guarantee the security. It's not exactly a "standard and legitimate feature" either; there were lengthy discussions this very year [1]. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929
  - schoen 14y ago
    The distinction is presumably about whether clients have to be modified to accept a particular (organizational) root or whether someone gets access to a root CA that will work with unmodified mainstream browsers. The "standard" way of doing enterprise network surveillance and censorship is by getting end-users to use client software with a modified configuration that (unlike the general public's browsers) accepts the surveillance and censorship without generating a browser warning. In the Trustwave case, it was done with unmodified software and hence could have been done against the general public, or unsuspecting corporate users. There have been interesting policy discussions about the fact that HTTPS site operators may not "consent" to this surveillance, even if some end users are considered to have done so. For example, PayPal might not want corporate network operators to have access to employees' PayPal credentials or financial transaction data. Hence PayPal's preferences might be something like employee doesn't use PayPal at work > employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer while the employee's preferences might be employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer > employee doesn't use PayPal at work and the employer's preferences might be employee doesn't use PayPal at work > employee uses PayPal at work with interception by employer > employee uses PayPal at work without interception by employer
enraged_camel 14y ago
It's worth noting that Turktrust is not a government agency, and ego.gov.tr is simply the website of the municipal department that controls traffic and public transportation in the capitol city of Ankara. The likelihood that they would use these certificates for malicious purposes is virtually zero.
- bcoates 14y ago
  It's a fraudulent certificate; why should we believe anything in it?
- darkhorn 14y ago
  Turktrust is part of "Hant-to-hand With Turkish Military Force" and EGO operates Electricity-Gas-otoBus in the capital city, Ankara.
- adulau 14y ago
  Why ego.gov.tr would need to have a certificate with *.google.com? I don't see any legitimate use case...
- michaelt 14y ago
  I'm not an expert on how spy agencies operate, but if they were buying a certificate like this to spy on people I don't think they'd ask to have their own name put on it? Turkey often blocks websites [1] so they obviously have a problem with some of Google's operations, and have the capability to mess with regular citizens' internet connections. [1] http://www.edri.org/edrigram/number10.24/ecthr-google-blocking-decision-foe http://www.edri.org/edrigram/number10.24/ecthr-google-blocki... http://www.bbc.co.uk/news/technology-11659816 http://www.bbc.co.uk/news/technology-11659816
alpb 14y ago
Wrong, it is not a government agency. It is privately held and run as CA with the permission given by the government.
- geofft 14y ago
  Read the article (or any of the other ones). TURKTRUST did not spoof the .google.com certificate. They accidentally issued an intermediate (chained CA) certificate to a user, who happened to be a government agency, and that user accidentally spoofed .google.com.
  - alpb 14y ago
    Title says government agency did, not the user. The problem is with the title.
    - deleted 14y ago
      [deleted]
    - pyre 14y ago
      Re-read that sentence. The government agency is the user in this case, not the CA. | TURKTRUST [a private company] did not spoof the | .google.com certificate. They accidentally issued | an intermediate (chained CA) certificate to a user | [a government agency], who happened to be a | government agency, and that user [a government | agency] accidentally spoofed | .google.com.
rdl 14y ago
Only somewhat joking: maybe there should be a rule that CAs are only allowed to issue to entities in foreign countries, outside traditional alliances, to ensure independence. I'm pretty confident Iranian intelligence couldn't pressure a major US CA to issue a cert for Iranian intelligence gathering; I'm pretty confident Turkish intelligence couldn't pressure a Japanese CA to issue for intelligence purposes. The problem is then US sites would need to get their certs from (at best) Russian or maybe Chinese CAs, and possibly only North Korean CAs. This still doesn't prevent the "evil CA issues something covertly to do evil", but it at least leaves an audit trail in that legit, widely-used certs aren't likely to be issued to illegitimate parties.
- darkhorn 14y ago
  I was thinking this for few months.
- michaelt 14y ago
  Many companies nowerdays are registered in tax havens. Wouldn't US CAs just get registered as Cayman Islands CAs?
- alanctgardner2 14y ago
  The problems are mostly in business administration. A Japanese CA would need staff who can communicate in every foreign language that could be encountered in a 'hostile' nation. And they'd presumably have to get those employees from the Japanese population, because otherwise if you hire all Turkisk nationals at a Japanese CA, what's the point? Then they'd have to be willing to accept payment in the currency of all the hostile nations, etc. Not to mention the difficulties of defining hostile nations. That would just further encourage countries like China and the US, which both want to intercept traffic, to negotiate with each other to get mutual access.
biturd 14y ago
Why are there intermediary CA's? They seem to hold the same power as a CA but little of the responsibility. It would be similar to allowing a secondary DNS provider to hold primary powers. I could start big-huge-secondary-dns-provider.example.com and edit my zones locally. The master could pick them up, and serve them out. DNS was not made that way, so why is the chain of command in a CA made that way? * I understand you can edit a secondary and if people are using it as a recursive DNS provider, you will in fact get back "lame" data, but that is almost never the case where a secondary is used as recessive recursive. At least not in any of the setups I have seen, deployed, or administered. [edit: spelling]
ekurutepe 14y ago
It might be plausible that the CA issued the subsidiary CA cert to a government agency due to incompetency, it is very hard to chalk it up to a 'mistake', if that said government agency uses the accidentally issued CA cert on their SSL intercepting firewall. What a convenient accident...
alanctgardner2 14y ago
I like TACK as a technical solution to this problem, but there is also the possibility of improved regulatory oversight. My question is why there isn't a stronger, official governing body for inclusion of certs in browsers. Right now it looks like MS, Mozilla and Google are the de facto deciders of whose certificates can be bundled by default in a browser. This basically decides who can be a root CA. The problem is, as three un-coordinated entities with no formal relationship, they have no procedure for putting the toothpaste back in the tube - they can't revoke a certificate, because there's no procedure. Personally, I would promote the creation of a separate body for managing root CA certificates, in which any browser vendor could participate. Members would agree to bundle only the certs approved by the body. The body would collect from participating CAs a certain portion of the monies paid for certificates - somewhere between 25% and 50%, to be released when the certificate expires. This serves as a sort of escrow for services rendered - customers can be confident they will get n years of use out of a certificate, even if the CA vanishes. Top level CAs would be responsible for remitting payments from intermediates they authorized. This would form a fund to facilitate the movement of customers, in the event a CA became illiquid or was deauthorized - sort of an FDIC for SSL certs. If a breach of trust occurred, or a CA went bankrupt, had its assets seized by a corrupt government, etc. this body would have the authority to blacklist the CAs certs after a window - 30 to 60 days. They would notify all of the CA's customers that they were being issued new, free certificates from a still-authorized CA of their choosing, with the payment for the new CA to be issued ( at a lower than market, but not insubstantial ) from the depository insurance fund. The body would provide customers with a list of approved CAs by country, and while the remitting process would likely be a nightmare the first time, at least people would have a timely way to get new, valid certs. Customers would complain a bit about the work to deploy new certs, but that's the cost of running (actually) secure infrastructure. This would achieve a few goals: - browsers would be obligated to bundle a common set of certs, with a common approval and audit process. This should be less work for new CAs to get approved - CAs would have a financial incentive to stay secure - a breach means we can legitimately revoke your authority, and you no longer own the cash we held in escrow - browsers would have teeth to create a 'death penalty' like Mozilla proposes, and better yet, they would all have the same criteria - certificate owners would be less conflicted between user security and their financial interests - the escrow would reduce their losses if a CA became insolvent

104 points by 6thSigma 14y ago

In previous instances (like Comodo), I can recall discussions on the Mozilla mailing lists about the so called "death penalty" of revocation for CAs who have demonstrated serious lapses. I think this situation is even worse. Forgive me for sounding paranoid but this sounds like collusion between the government of Turkey and Turktrust, to intercept communications. I believe that the harshest penalty should be pursued, which is removal of the Turktrust root certificate from all trust databases. They cannot be trusted. EDIT: It appears that Mozilla is on the same page as I am. https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/ https://blog.mozilla.org/security/2013/01/03/revoking-trust-... https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/aqn0Zm-KxQ0 https://groups.google.com/forum/?fromgroups=#!topic/mozilla.... Another good idea mentioned on the mailing list was to blacklist the auditor: https://groups.google.com/d/msg/mozilla.dev.security.policy/aqn0Zm-KxQ0/OOMOOFBKXoAJ https://groups.google.com/d/msg/mozilla.dev.security.policy/...

cheald 14y ago
I'd agree. We have plenty of CAs - killing a few off here and there isn't going to harm our ability to manage certificates, and those that make these kinds of mistakes - intentionally or otherwise - aren't worth the trouble of having them around. A couple of CAs being revoked for slipping the wrong certs to the wrong parties is only going to make other CAs triple check their work before handing out the keys to the kingdom.
- tptacek 14y ago
  No, it won't harm our ability to manage certificates. What it will do instead is create a point in time where suddenly a whole mess of websites that used to be protected with HTTPS are now no longer protected with HTTPS. If there's a graceful and safe way to provide effective advance notice for this, I haven't heard it yet. I agree in spirit; I'd like to see more CA's get the death penalty. But the pragmatic argument against it is convincing.
  - cheald 14y ago
    This seems like a problem that could be pretty easily solved by the browser vendors, similar to how they do malware checks. Throw up a "this site's security certificate was issued by a compromised authority, and will no longer be valid in <x time at y date>. If this is your website, click here for more information." Run that for a sufficiently long period of time, then kill the CA. It's not perfect, but we have a huge web of people using these affected sites on a daily basis who can serve as a very powerful driving force to spur change when necessary to minimize fallout.
  - sc68cal 14y ago
    While I agree with you about pulling the rug out from users - if the CA is already forging certificates for important domains, then how much security do they really have?
    - dustingetz 14y ago
      right now only the turkish government can do MITM - other parties can't.
      - jacquesm 14y ago
        > right now only the turkish government can do MITM - other parties can't. First, if true that's a small comfort. Second, how do you know that is true?
        danielweber 14y ago
        It's in the Turkish government's to use these invalid certs as little as possible, so they are probably going to use them against people like Turkish dissidents. (I don't mean to dismiss their interests, but they are distinct from other people's interests.)
    - tptacek 14y ago
      More than they do if the whole CA is removed. Sorry, annoying but true. Promote TACK!
biturd 14y ago
I don't think you are paranoid. They went from a "mistake" in issuing a "testing" certificate that managed to propagate through their system that just "happened" to be sitting around and configured in a way to be ready to execute a MITM configuration. To me, the chances of that happening seem challenging at best. To have it happen automatically and without hitch or fail, seems highly improbable.

meaty 14y ago

Doesn't surprise me. Even if it was an accident, it's improbable. Then again, back in the dark ages, we found that if NT3.51 was under heavy load, it was possible to generate two identical guids in under 2 hours of wall time.

ommunist 14y ago
It is probable. Just the probability is low. But it could happen.
GIFtheory 14y ago
It's also worth noting that Turkey's government routinely blocks Google services (especially youtube) for hosting "offensive" content (e.g.: http://www.huffingtonpost.com/2010/06/08/turkey-blocks-google-serv_n_604148.html http://www.huffingtonpost.com/2010/06/08/turkey-blocks-googl...). So, a sinister explanation is even less far-fetched for Turkey in particular.

deleted 14y ago

[deleted]

tptacek 14y ago

I believe them. If you're going to use a malicious certificate to spoof traffic, you'd be pretty dumb to start by targeting Google, since all their properties are pinned in Chrome. You'll just get caught. Also, using X.509 CA=YES certificates to mint new certificates on the fly is a standard and legitimate feature of corporate network hardware. In virtually every large enterprise network, employees don't have direct access to the Internet; they bounce through proxy servers. The middleboxes that make this work all have "upload a root CA cert here" features to make this work. That they accidentally issued a malicious certificate, I think, makes things a little worse from my vantage point. There are a million ways to get hacked, but not as many excuses for just being sloppy.

revelation 14y ago
I'm fairly confused by your stance here. I was expecting you to tell us that a) security with backdoors is worthless (intermediate CAs, for use in packet inspection devices, not merely proxies) and b) security without control (and repercussions) for those that guarantee the security. It's not exactly a "standard and legitimate feature" either; there were lengthy discussions this very year [1]. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=724929 https://bugzilla.mozilla.org/show_bug.cgi?id=724929
- schoen 14y ago
  The distinction is presumably about whether clients have to be modified to accept a particular (organizational) root or whether someone gets access to a root CA that will work with unmodified mainstream browsers. The "standard" way of doing enterprise network surveillance and censorship is by getting end-users to use client software with a modified configuration that (unlike the general public's browsers) accepts the surveillance and censorship without generating a browser warning. In the Trustwave case, it was done with unmodified software and hence could have been done against the general public, or unsuspecting corporate users. There have been interesting policy discussions about the fact that HTTPS site operators may not "consent" to this surveillance, even if some end users are considered to have done so. For example, PayPal might not want corporate network operators to have access to employees' PayPal credentials or financial transaction data. Hence PayPal's preferences might be something like employee doesn't use PayPal at work > employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer while the employee's preferences might be employee uses PayPal at work without interception by employer > employee uses PayPal at work with interception by employer > employee doesn't use PayPal at work and the employer's preferences might be employee doesn't use PayPal at work > employee uses PayPal at work with interception by employer > employee uses PayPal at work without interception by employer

enraged_camel 14y ago

It's worth noting that Turktrust is not a government agency, and ego.gov.tr is simply the website of the municipal department that controls traffic and public transportation in the capitol city of Ankara. The likelihood that they would use these certificates for malicious purposes is virtually zero.

bcoates 14y ago
It's a fraudulent certificate; why should we believe anything in it?
darkhorn 14y ago
Turktrust is part of "Hant-to-hand With Turkish Military Force" and EGO operates Electricity-Gas-otoBus in the capital city, Ankara.
adulau 14y ago
Why ego.gov.tr would need to have a certificate with *.google.com? I don't see any legitimate use case...
michaelt 14y ago
I'm not an expert on how spy agencies operate, but if they were buying a certificate like this to spy on people I don't think they'd ask to have their own name put on it? Turkey often blocks websites [1] so they obviously have a problem with some of Google's operations, and have the capability to mess with regular citizens' internet connections. [1] http://www.edri.org/edrigram/number10.24/ecthr-google-blocking-decision-foe http://www.edri.org/edrigram/number10.24/ecthr-google-blocki... http://www.bbc.co.uk/news/technology-11659816 http://www.bbc.co.uk/news/technology-11659816

alpb 14y ago

Wrong, it is not a government agency. It is privately held and run as CA with the permission given by the government.

geofft 14y ago
Read the article (or any of the other ones). TURKTRUST did not spoof the .google.com certificate. They accidentally issued an intermediate (chained CA) certificate to a user, who happened to be a government agency, and that user accidentally spoofed .google.com.
- alpb 14y ago
  Title says government agency did, not the user. The problem is with the title.
  - deleted 14y ago
    [deleted]
  - pyre 14y ago
    Re-read that sentence. The government agency is the user in this case, not the CA. | TURKTRUST [a private company] did not spoof the | .google.com certificate. They accidentally issued | an intermediate (chained CA) certificate to a user | [a government agency], who happened to be a | government agency, and that user [a government | agency] accidentally spoofed | .google.com.

rdl 14y ago

Only somewhat joking: maybe there should be a rule that CAs are only allowed to issue to entities in foreign countries, outside traditional alliances, to ensure independence. I'm pretty confident Iranian intelligence couldn't pressure a major US CA to issue a cert for Iranian intelligence gathering; I'm pretty confident Turkish intelligence couldn't pressure a Japanese CA to issue for intelligence purposes. The problem is then US sites would need to get their certs from (at best) Russian or maybe Chinese CAs, and possibly only North Korean CAs. This still doesn't prevent the "evil CA issues something covertly to do evil", but it at least leaves an audit trail in that legit, widely-used certs aren't likely to be issued to illegitimate parties.

darkhorn 14y ago
I was thinking this for few months.
michaelt 14y ago
Many companies nowerdays are registered in tax havens. Wouldn't US CAs just get registered as Cayman Islands CAs?
alanctgardner2 14y ago
The problems are mostly in business administration. A Japanese CA would need staff who can communicate in every foreign language that could be encountered in a 'hostile' nation. And they'd presumably have to get those employees from the Japanese population, because otherwise if you hire all Turkisk nationals at a Japanese CA, what's the point? Then they'd have to be willing to accept payment in the currency of all the hostile nations, etc. Not to mention the difficulties of defining hostile nations. That would just further encourage countries like China and the US, which both want to intercept traffic, to negotiate with each other to get mutual access.

biturd 14y ago

Why are there intermediary CA's? They seem to hold the same power as a CA but little of the responsibility. It would be similar to allowing a secondary DNS provider to hold primary powers. I could start big-huge-secondary-dns-provider.example.com and edit my zones locally. The master could pick them up, and serve them out. DNS was not made that way, so why is the chain of command in a CA made that way? * I understand you can edit a secondary and if people are using it as a recursive DNS provider, you will in fact get back "lame" data, but that is almost never the case where a secondary is used as recessive recursive. At least not in any of the setups I have seen, deployed, or administered. [edit: spelling]

ekurutepe 14y ago

It might be plausible that the CA issued the subsidiary CA cert to a government agency due to incompetency, it is very hard to chalk it up to a 'mistake', if that said government agency uses the accidentally issued CA cert on their SSL intercepting firewall. What a convenient accident...

alanctgardner2 14y ago

I like TACK as a technical solution to this problem, but there is also the possibility of improved regulatory oversight. My question is why there isn't a stronger, official governing body for inclusion of certs in browsers. Right now it looks like MS, Mozilla and Google are the de facto deciders of whose certificates can be bundled by default in a browser. This basically decides who can be a root CA. The problem is, as three un-coordinated entities with no formal relationship, they have no procedure for putting the toothpaste back in the tube - they can't revoke a certificate, because there's no procedure. Personally, I would promote the creation of a separate body for managing root CA certificates, in which any browser vendor could participate. Members would agree to bundle only the certs approved by the body. The body would collect from participating CAs a certain portion of the monies paid for certificates - somewhere between 25% and 50%, to be released when the certificate expires. This serves as a sort of escrow for services rendered - customers can be confident they will get n years of use out of a certificate, even if the CA vanishes. Top level CAs would be responsible for remitting payments from intermediates they authorized. This would form a fund to facilitate the movement of customers, in the event a CA became illiquid or was deauthorized - sort of an FDIC for SSL certs. If a breach of trust occurred, or a CA went bankrupt, had its assets seized by a corrupt government, etc. this body would have the authority to blacklist the CAs certs after a window - 30 to 60 days. They would notify all of the CA's customers that they were being issued new, free certificates from a still-authorized CA of their choosing, with the payment for the new CA to be issued ( at a lower than market, but not insubstantial ) from the depository insurance fund. The body would provide customers with a list of approved CAs by country, and while the remitting process would likely be a nightmare the first time, at least people would have a timely way to get new, valid certs. Customers would complain a bit about the work to deploy new certs, but that's the cost of running (actually) secure infrastructure. This would achieve a few goals: - browsers would be obligated to bundle a common set of certs, with a common approval and audit process. This should be less work for new CAs to get approved - CAs would have a financial incentive to stay secure - a breach means we can legitimately revoke your authority, and you no longer own the cash we held in escrow - browsers would have teeth to create a 'death penalty' like Mozilla proposes, and better yet, they would all have the same criteria - certificate owners would be less conflicted between user security and their financial interests - the escrow would reduce their losses if a CA became insolvent