4 ms·

DigiNotar should never have been a top-level CA. They should have been a third-party CA underneath Verisign or somebody similar, with only a right to sign and v

by nikcub 15y ago

DigiNotar should never have been a top-level CA. They should have been a third-party CA underneath Verisign or somebody similar, with only a right to sign and verify certain certificates. This is how most banks are setup. There are far, far too many trusted top-level cert CA's now. The list was 3-4 long years ago, and was designed with third-party CA's just for this reason. Today you have a huge list and it changes every month

tptacek 15y ago
You probably know something about certificates I don't, but as I understand the code that handles this stuff, your certificate either has CA=YES or CA=NO in its basicConstraints; if it's CA=YES, you're a CA full stop. It's the combination of having that bit -- err, DER boolean -- set and chaining to browser root cert that makes you a CA. There isn't a provision in the scheme for them to do less than be able to sign Google, which is why the CA system is so brittle and broken. What is the bank setup that you're thinking about? I didn't think that BankOfAmerica.com could sign its own certs for CNs under BankOfAmerica.com. Our customers include large banks and they bitch about having to work with Verisign just like everyone else.
- nikcub 15y ago
  My experience is from 10 years ago, where I set this up for a startup I worked at. This was the situation: we had built a platform for trade finance. It was like eBay but for trade paper. eg. somebody is exporting $80M worth of oil, and they need a bank to finance it. We had 500+ banks from around the world on the platform, and they would all bid for the business. Because we were dealing with hundreds of millions of dollars worth of commitments, we needed a certificate architecture that would verify the seller, the buyer, and for each of those parties to verify the site. I went to Verisign and asked them for the best solution, and this is what they setup: - we had a Verisign terminal setup in the office. This was a normal computer, but locked down to only run Verisign software. It was a flavor of UNIX - the terminal had a smart-card reader on it, and a private net connection that went only back to Verisign. - the authentication to login to the computer was two passwords, both with secure tokens, and two smart cards - when you login, you do the ID shuffle, which involved two people who had background checks conducted on them etc. - we generate a certificate, which is then signed using a sub-CA certificate that Verisign issues to us - Our certificate thus acted as a CA, but it was authorized by Verisign, so the certs that we signed would then check out using the built-in browser CA certs This cost us hundreds of thousands of dollars to setup, and cost us hundreds of dollars for each cert we signed. When I did the due dilligence on the solution, I visited 3 london-based banks who had implemented the same system. The selling point was that we could act as a CA, but without really being a CA. Verisign's sales pitch was that you could never become the root CA because of the stringent policies that had to be put in place (isolated networks, key generation, etc.), but for the fraction of the cost, we could sign certs using our cert which would be verified up the chain to the root CA which was Verisign I can't stress how secure this whole procedure was. The root CA store was the holy grail - nobody that did't have the infrastructure or procedures like Verisign would get anywhere near it. I now read stories 10 years later of dodgy dutch companies with no budgets being given root CA privileges, and I am just blown away. If these guys needed a solution to sign certs, they should have been setup with what we had, and what the other banks had, not just given placement in the root cert store. Verisign would check and double-check everything we did, and would frequently revert certs we signed where they suspected something was wrong. With this story it seems there was a completely amateur operation given privileges to sign certs as part of a root CA. I have 163 root CA certs on my OS X machine. 10 years ago I am certain the number was 4 or 5 note: this was so long ago that I probably have some of my terminology mixed up, but what we bought was the right to sign certs as a sub-CA of Verisign, a privileged root CA. I also got a very cool tour of Verisign which is another story.
  - tptacek 15y ago
    So the only thing that kept your startup from being able to mint a certificate for *.GOOGLE.COM was the physical security of a single Unix box? The setup you describe is actually worse than what happened with Diginotar. There's a public record of Diginotar being added to the browser roots, complete with audit statements tying PwC to attestations that Diginotar was ready to be a CA. Nobody in hindsight agrees that a good decision was made there, but at least we know it was made. There is no way to account for Verisign signing CA=YES keys for private companies as a convenience; we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet". Well, I don't want to pin the safety of the entire Internet on Verisign's ability to secure a Unix box they don't even have physical custody over. Diginotar isn't what upsets me about the browser CA situation. Subordinate CAs are.
    - VladRussian 15y ago
      >we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet". like we trust with the same to any other CA in the browser trusted root store.
      - tptacek 15y ago
        Exactly. We could with the flip of a switch ban intermediate CAs; the browser's TLS library sees the chain of intermediate CA=YES certs.
    - dopo 15y ago
      The way I read his tale, it sounds like VeriSign may have kept the signing keys for his intermediate CA, and their onsite secure terminal just submitted CSRs back to VeriSign and got the signed certificates back. VeriSign was then in a position to enforce the policy that no certs get signed for anything outside of the domains that should be signed.
      - tptacek 15y ago
speleding 15y ago
"DigiNotar should never have been a top-level CA. They should have been a third-party CA underneath Verisign or somebody similar" Look at it from the position of the Dutch government (or any other government): Who would you trust to digitally sign passports and crucial government communications? (Which is what the Diginotar certificates are being used for). No government would like the idea of being at the mercy of a foreign entity they cannot control.
- icebraining 15y ago
  >Who would you trust to digitally sign passports and crucial government communications? Myself. I don't understand why governments don't become their own CAs, limited to issuing certificates for official websites and documents. Of course, it would be better if browsers could limit CA trust to certain domains and subdomains (for example, the Portuguese govt CA should only be trusted for .gov.pt domains) to prevent abuse, but on the other hand we all know that if a govt is dirty enough to abuse that they'd be able to pressure some national CA into issuing it.
darklajid 15y ago
I'm torn. Should everyone and his mom be allowed to create certificates? No. Should we limit ourselves to 'the big players' in the US? No. That would drastically reduce the competition and make certificates far more expensive again. One could claim that quality has it's price, cheap competition probably cuts costs in the process, yadda yadda. I don't buy it. Give me a list of 20-30 CAs over 3 every day. I don't care about the number that much. What I would like to see is - a site where I can get information on the usage, origin and track record of CAs - a site where I can see where a a CA is based. A lot of people are already removing CAs from China. Different places of the world have different trust values already (and, frankly, the US is not high on my list of 'trusted' places. I very much know that we're discussing a big failure of a dutch CA here, but I'd usually prefer to trust a CA from the EU or Switzerland instead of an US one).

by nikcub 15y ago

tptacek 15y ago

You probably know something about certificates I don't, but as I understand the code that handles this stuff, your certificate either has CA=YES or CA=NO in its basicConstraints; if it's CA=YES, you're a CA full stop. It's the combination of having that bit -- err, DER boolean -- set and chaining to browser root cert that makes you a CA. There isn't a provision in the scheme for them to do less than be able to sign Google, which is why the CA system is so brittle and broken. What is the bank setup that you're thinking about? I didn't think that BankOfAmerica.com could sign its own certs for CNs under BankOfAmerica.com. Our customers include large banks and they bitch about having to work with Verisign just like everyone else.

nikcub 15y ago
My experience is from 10 years ago, where I set this up for a startup I worked at. This was the situation: we had built a platform for trade finance. It was like eBay but for trade paper. eg. somebody is exporting $80M worth of oil, and they need a bank to finance it. We had 500+ banks from around the world on the platform, and they would all bid for the business. Because we were dealing with hundreds of millions of dollars worth of commitments, we needed a certificate architecture that would verify the seller, the buyer, and for each of those parties to verify the site. I went to Verisign and asked them for the best solution, and this is what they setup: - we had a Verisign terminal setup in the office. This was a normal computer, but locked down to only run Verisign software. It was a flavor of UNIX - the terminal had a smart-card reader on it, and a private net connection that went only back to Verisign. - the authentication to login to the computer was two passwords, both with secure tokens, and two smart cards - when you login, you do the ID shuffle, which involved two people who had background checks conducted on them etc. - we generate a certificate, which is then signed using a sub-CA certificate that Verisign issues to us - Our certificate thus acted as a CA, but it was authorized by Verisign, so the certs that we signed would then check out using the built-in browser CA certs This cost us hundreds of thousands of dollars to setup, and cost us hundreds of dollars for each cert we signed. When I did the due dilligence on the solution, I visited 3 london-based banks who had implemented the same system. The selling point was that we could act as a CA, but without really being a CA. Verisign's sales pitch was that you could never become the root CA because of the stringent policies that had to be put in place (isolated networks, key generation, etc.), but for the fraction of the cost, we could sign certs using our cert which would be verified up the chain to the root CA which was Verisign I can't stress how secure this whole procedure was. The root CA store was the holy grail - nobody that did't have the infrastructure or procedures like Verisign would get anywhere near it. I now read stories 10 years later of dodgy dutch companies with no budgets being given root CA privileges, and I am just blown away. If these guys needed a solution to sign certs, they should have been setup with what we had, and what the other banks had, not just given placement in the root cert store. Verisign would check and double-check everything we did, and would frequently revert certs we signed where they suspected something was wrong. With this story it seems there was a completely amateur operation given privileges to sign certs as part of a root CA. I have 163 root CA certs on my OS X machine. 10 years ago I am certain the number was 4 or 5 note: this was so long ago that I probably have some of my terminology mixed up, but what we bought was the right to sign certs as a sub-CA of Verisign, a privileged root CA. I also got a very cool tour of Verisign which is another story.
- tptacek 15y ago
  So the only thing that kept your startup from being able to mint a certificate for *.GOOGLE.COM was the physical security of a single Unix box? The setup you describe is actually worse than what happened with Diginotar. There's a public record of Diginotar being added to the browser roots, complete with audit statements tying PwC to attestations that Diginotar was ready to be a CA. Nobody in hindsight agrees that a good decision was made there, but at least we know it was made. There is no way to account for Verisign signing CA=YES keys for private companies as a convenience; we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet". Well, I don't want to pin the safety of the entire Internet on Verisign's ability to secure a Unix box they don't even have physical custody over. Diginotar isn't what upsets me about the browser CA situation. Subordinate CAs are.
  - VladRussian 15y ago
    >we can only trust Verisign when it says "anything we do with our private key we do with security measures adequate to the task of protecting the entire Internet". like we trust with the same to any other CA in the browser trusted root store.
    - tptacek 15y ago
      Exactly. We could with the flip of a switch ban intermediate CAs; the browser's TLS library sees the chain of intermediate CA=YES certs.
  - dopo 15y ago
    The way I read his tale, it sounds like VeriSign may have kept the signing keys for his intermediate CA, and their onsite secure terminal just submitted CSRs back to VeriSign and got the signed certificates back. VeriSign was then in a position to enforce the policy that no certs get signed for anything outside of the domains that should be signed.
    - tptacek 15y ago

speleding 15y ago

"DigiNotar should never have been a top-level CA. They should have been a third-party CA underneath Verisign or somebody similar" Look at it from the position of the Dutch government (or any other government): Who would you trust to digitally sign passports and crucial government communications? (Which is what the Diginotar certificates are being used for). No government would like the idea of being at the mercy of a foreign entity they cannot control.

icebraining 15y ago
>Who would you trust to digitally sign passports and crucial government communications? Myself. I don't understand why governments don't become their own CAs, limited to issuing certificates for official websites and documents. Of course, it would be better if browsers could limit CA trust to certain domains and subdomains (for example, the Portuguese govt CA should only be trusted for .gov.pt domains) to prevent abuse, but on the other hand we all know that if a govt is dirty enough to abuse that they'd be able to pressure some national CA into issuing it.

darklajid 15y ago

I'm torn. Should everyone and his mom be allowed to create certificates? No. Should we limit ourselves to 'the big players' in the US? No. That would drastically reduce the competition and make certificates far more expensive again. One could claim that quality has it's price, cheap competition probably cuts costs in the process, yadda yadda. I don't buy it. Give me a list of 20-30 CAs over 3 every day. I don't care about the number that much. What I would like to see is - a site where I can get information on the usage, origin and track record of CAs - a site where I can see where a a CA is based. A lot of people are already removing CAs from China. Different places of the world have different trust values already (and, frankly, the US is not high on my list of 'trusted' places. I very much know that we're discussing a big failure of a dutch CA here, but I'd usually prefer to trust a CA from the EU or Switzerland instead of an US one).