5 ms·

> for issuing SSL Certificates for their own domains If you can only issue certificates for your domains and subdomains, then it's not an issue. This sounds mo

> for issuing SSL Certificates for their own domains If you can only issue certificates for your domains and subdomains, then it's not an issue. This sounds more like an alternative to setting up a Windows Enterprise CA and then distributing the root cert to all of your non-Windows clients. e: Think of it like this: instead of just giving you a wildcard cert, they're letting you make individual certs for your subdomains yourself.

tptacek 14y ago
There is no mechanism in the TLS X.509 PKI that enforces that rule. If a product promises transparent trust for any sort of customer-selected domains, it is either lying or selling the cryptographic equivalent of plutonium. There have definitely been attempts to build products that use technical controls in the CA product to enforce the restrictions --- ie, the customer gets a locked down box that tries to make sure it isn't misused --- but as I understand it, these are no longer OK to sell.
- madsushi 14y ago
  Gotcha, if the technology isn't in place to properly restrict the issued certs to only the customer's domains, that is bad. I saw this on another site discussing Trusted Root certs: > What is required to get a Root Signing Certificate? > Each certificate provider has different requirements for trusted rootsigning certificates. Most will require something similar to the following: > - Substantial net worth and insurance > - A Certification Practice Statement (CPS) outlining your exact policies on issuing and managing certificates. > - A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys. So it sounds like they are handing out the keys and then hoping that auditing/policies/insurance are in place to cover themselves.
  - JoachimSchipper 14y ago
    > A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys. For those not versed in this particular jargon: "FIPS 140-2 Level 2" pretty much means "tamper-evident seal" (part of a sticker over the opening stays on the box when you try to remove it - this is only slightly more secure than I make it sound.) Note also that this does not appear to include any restriction on the computers which can say "please sign this certificate for me". Sensible CAs will have extensive physical security around such devices, but can we count on anyone with $BIGNUM dollars to get this right? On a cryptographic level, there is the paper discussed at http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html http://blog.cryptographyengineering.com/2012/06/bad-couple-o... (http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf), which totally pwns some well-regarded smart cards using a (really nifty improvement on) a years-old crypto attack, then goes on to note that the authors really wanted to try their hand at a couple of HSMs too but lacked the funds. Which doesn't prove anything about HSMs, but doesn't exactly give one a lot of confidence either. So yeah, they do seem to be handing out the keys and hoping that auditing/policies/insurance covers it.
- ivanr 14y ago
  Strictly speaking, the mechanism is there (Name Constraints, see section 4.2.1.10 in the RFC 5280), but it's not practical due to it not being implemented consistently across all major browsers. EDIT: Changed RFC number from 2459 (obsolete) to 5280.
  - tptacek 14y ago
    D'oh! I meant to write "effectively enforces" because I knew you'd snipe me with something like this. You win this time, Ristic.
    - marshray 14y ago
      No, you're right Ptacek because in this case the extension is being marked NON-critical. I.e., if the client code doesn't recognize the name constraint extension, it's OK to just ignore it.
      - tptacek 14y ago
        If that is a problem that impacts only one popular browser, I find it easier to cast blame at the feet of the browser.
        marshray 14y ago
        You're forgetting the huge mass of non-browser SSL/TLS clients. Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers. Consider now that your home router's firmware update client, your server's IPMI, and the entire global network for real-time trading of [strategic material] was written by developers to RFCs that told them they had absolutely no reason to implement the Name Constraints extension because if it ever appeared, it was guaranteed to be marked 'critical'.
        tptacek 14y ago
        Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers. Careful. You're going to show up on "Shit HN Says".
- huhtenberg 14y ago
  Perhaps they don't give you the actual cert, but merely issue it, keep on their premises and then let you use it for unlimited signing through some sort of API (that enforces the subdomain restriction)? Because if they indeed are offering CA=yes certs, that's just plain unbelievable.
  - jlgaddis 14y ago
    Most will require that the private key be stored in an HSM (which almost certainly will be located on the customer's premises).
- benmmurphy 14y ago
  there is dNSName constraints but i don't know how well browsers support it. subordinate CAs seem quite problematic because they are invisible Certificate Authorities at least as far as the user is concerned.

tptacek 14y ago

There is no mechanism in the TLS X.509 PKI that enforces that rule. If a product promises transparent trust for any sort of customer-selected domains, it is either lying or selling the cryptographic equivalent of plutonium. There have definitely been attempts to build products that use technical controls in the CA product to enforce the restrictions --- ie, the customer gets a locked down box that tries to make sure it isn't misused --- but as I understand it, these are no longer OK to sell.

madsushi 14y ago
Gotcha, if the technology isn't in place to properly restrict the issued certs to only the customer's domains, that is bad. I saw this on another site discussing Trusted Root certs: > What is required to get a Root Signing Certificate? > Each certificate provider has different requirements for trusted rootsigning certificates. Most will require something similar to the following: > - Substantial net worth and insurance > - A Certification Practice Statement (CPS) outlining your exact policies on issuing and managing certificates. > - A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys. So it sounds like they are handing out the keys and then hoping that auditing/policies/insurance are in place to cover themselves.
- JoachimSchipper 14y ago
  > A FIPS 140-2 Level 2 compliant device to generate and managing your root certificate keys. For those not versed in this particular jargon: "FIPS 140-2 Level 2" pretty much means "tamper-evident seal" (part of a sticker over the opening stays on the box when you try to remove it - this is only slightly more secure than I make it sound.) Note also that this does not appear to include any restriction on the computers which can say "please sign this certificate for me". Sensible CAs will have extensive physical security around such devices, but can we count on anyone with $BIGNUM dollars to get this right? On a cryptographic level, there is the paper discussed at http://blog.cryptographyengineering.com/2012/06/bad-couple-of-years-for-cryptographic.html http://blog.cryptographyengineering.com/2012/06/bad-couple-o... (http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf http://hal.inria.fr/docs/00/70/47/90/PDF/RR-7944.pdf), which totally pwns some well-regarded smart cards using a (really nifty improvement on) a years-old crypto attack, then goes on to note that the authors really wanted to try their hand at a couple of HSMs too but lacked the funds. Which doesn't prove anything about HSMs, but doesn't exactly give one a lot of confidence either. So yeah, they do seem to be handing out the keys and hoping that auditing/policies/insurance covers it.
ivanr 14y ago
Strictly speaking, the mechanism is there (Name Constraints, see section 4.2.1.10 in the RFC 5280), but it's not practical due to it not being implemented consistently across all major browsers. EDIT: Changed RFC number from 2459 (obsolete) to 5280.
- tptacek 14y ago
  D'oh! I meant to write "effectively enforces" because I knew you'd snipe me with something like this. You win this time, Ristic.
  - marshray 14y ago
    No, you're right Ptacek because in this case the extension is being marked NON-critical. I.e., if the client code doesn't recognize the name constraint extension, it's OK to just ignore it.
    - tptacek 14y ago
      If that is a problem that impacts only one popular browser, I find it easier to cast blame at the feet of the browser.
      - marshray 14y ago
        You're forgetting the huge mass of non-browser SSL/TLS clients. Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers. Consider now that your home router's firmware update client, your server's IPMI, and the entire global network for real-time trading of [strategic material] was written by developers to RFCs that told them they had absolutely no reason to implement the Name Constraints extension because if it ever appeared, it was guaranteed to be marked 'critical'.
        tptacek 14y ago
        Do you see the expressions of surprise about this policy here on HN? These are the world's more informed client application developers. Careful. You're going to show up on "Shit HN Says".
huhtenberg 14y ago
Perhaps they don't give you the actual cert, but merely issue it, keep on their premises and then let you use it for unlimited signing through some sort of API (that enforces the subdomain restriction)? Because if they indeed are offering CA=yes certs, that's just plain unbelievable.
- jlgaddis 14y ago
  Most will require that the private key be stored in an HSM (which almost certainly will be located on the customer's premises).
benmmurphy 14y ago
there is dNSName constraints but i don't know how well browsers support it. subordinate CAs seem quite problematic because they are invisible Certificate Authorities at least as far as the user is concerned.