6 ms·

I think you are misunderstanding. First off so there is no ambiguity let me say clearly that GlobalSign's policies do not allow the use of certificates that ch

by rmhrisk 14y ago

I think you are misunderstanding. First off so there is no ambiguity let me say clearly that GlobalSign's policies do not allow the use of certificates that chain to our roots to be used for MiTM purposes (or other malicious use cases for that matter). That said there are lots of reasons why a company might want or need to operate their own in house PKI and have that PKI trusted; one easy to understand case is google; though they are not our customer they operate their own in house PKI that they use to issue the many many SSL certificates their infrastructure utilizes: https://sslcheck.x509labs.com/en_US/sslcheck?host=www.google.com#74.125.227.114-cert https://sslcheck.x509labs.com/en_US/sslcheck?host=www.google... But SSL is not the only reason one might want to operate their own internal PKI that is trusted, other cases include business to consumer and business to business communication (for example S/MIME). As for how we (and other CAs) go about ensuring trusted root deployments are not used for MiTM cases, there is the obvious contractual obligations that are accompanied by audits but we also were the first publicly trusted CA to use Name Constraints to deploy qualified subordination to these deployments (which has become a requirement now – it was not when we started). This approach technically limits what domains these enterprise trusted root customers are trusted by mainstream clients for - see: http://unmitigatedrisk.com/?p=24 http://unmitigatedrisk.com/?p=24 There are also a set of “Trusted Root” customers who are in the process of becoming trusted by browsers (which can take 3-5 years) where we will cross-certify their root enabling them to be trusted while their own key material becomes ubiquitously trusted. I should also add that Mozila’s root inclusion policy (as well as Microsoft’s and the other root programs) allow for these scenarios. I hope this helps clarify, please let me now if you have any questions. Ryan Hurst CTO, GlobalSign ryan.hurst@globalsign.com

tptacek 14y ago
Hey, Ryan. Thanks for clarifying. I only have one followup question. Do any of your offerings provide customers with custody of an X.509 certificate that chains to a GlobalSign certificate that is trusted by any of IE, Mozilla, Chrome, or Safari where that X.509 certificate has CA:TRUE in its Basic Constraints? By "custody" I mean that the private key corresponding to that certificate is held in some fashion on customer premises, regardless of the technical controls implemented in the device in which it's held.
- rmhrisk 14y ago
  They do and that's is specifically what this offering is about. However our policies have always been that those entities need to meet the same requirements (operationally, etc) as we do which includes not participating MiTMs with any key material associated with that PKI. Those customers who do have such CAs are also (normally) subject contractual restrictions to what namespaces they can issue against and they are always subject to audits where we confirm their usage is consistent with those policies. In the very rare cases where that is not the case they are audited to meet the exact requirements we meet - we almost never do this. It’s a difficult problem as a whole, there are legitimate use cases that help secure the web and enable commerce that are best served by having publicly trusted certificates our goal as an industry is to find ways to address those needs while reducing the risk. To that end when I joined GlobalSign a year ago (from Microsoft) one of the first things I did was started here to advocate the industries use of name constraints as a means to reduce risk for all parties involved in these scenarios. Ryan
  - tptacek 14y ago
    Thanks. I'm sorry, I knew MITM wasn't the only or most common reason enterprises wanted these certs, but wrote lazily. Are the nameConstraints extensions on these certs marked critical? I didn't know they could even be non-critical (one RFC says they can't) but 'agl says otherwise and would know.
    - rmhrisk 14y ago
      That's the position we start with when we engage with a customer but its dependent on the community in which they are going to communicate with. To be honest in most cases today (due to Safari) criticality is not enabled on most deployments.
      - tptacek 14y ago
        Argh.
      - lawnchair_larry 14y ago
ivanr 14y ago
Can you expand further on the practicality of the Name Constraints extension? My understanding is that not all browsers/libraries enforce them and IIRC, that certs that use them may not work in some browsers?
- agl 14y ago
  (Copying this reply of mine from another part of the thread as you're not the only person to ask.) Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users. But there are two ways to use Name Constraints: they can be marked critical or non-critical. Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base. Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
  - rmhrisk 14y ago
    I agree with Adam, support is actually quite good in modern libraries and this is in no small thanks to the good folks at NIST who published the PKITS tests for chain engines - http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitest... Many libraries built these into regression tests for their chain engines and the suite covers name constraints pretty good.
    - marshray 14y ago
      If support is really that good, then you should have no problem following the RFC requirement that the name constraint extension be marked 'critical'.
      - rmhrisk 14y ago

by rmhrisk 14y ago

tptacek 14y ago

Hey, Ryan. Thanks for clarifying. I only have one followup question. Do any of your offerings provide customers with custody of an X.509 certificate that chains to a GlobalSign certificate that is trusted by any of IE, Mozilla, Chrome, or Safari where that X.509 certificate has CA:TRUE in its Basic Constraints? By "custody" I mean that the private key corresponding to that certificate is held in some fashion on customer premises, regardless of the technical controls implemented in the device in which it's held.

rmhrisk 14y ago
They do and that's is specifically what this offering is about. However our policies have always been that those entities need to meet the same requirements (operationally, etc) as we do which includes not participating MiTMs with any key material associated with that PKI. Those customers who do have such CAs are also (normally) subject contractual restrictions to what namespaces they can issue against and they are always subject to audits where we confirm their usage is consistent with those policies. In the very rare cases where that is not the case they are audited to meet the exact requirements we meet - we almost never do this. It’s a difficult problem as a whole, there are legitimate use cases that help secure the web and enable commerce that are best served by having publicly trusted certificates our goal as an industry is to find ways to address those needs while reducing the risk. To that end when I joined GlobalSign a year ago (from Microsoft) one of the first things I did was started here to advocate the industries use of name constraints as a means to reduce risk for all parties involved in these scenarios. Ryan
- tptacek 14y ago
  Thanks. I'm sorry, I knew MITM wasn't the only or most common reason enterprises wanted these certs, but wrote lazily. Are the nameConstraints extensions on these certs marked critical? I didn't know they could even be non-critical (one RFC says they can't) but 'agl says otherwise and would know.
  - rmhrisk 14y ago
    That's the position we start with when we engage with a customer but its dependent on the community in which they are going to communicate with. To be honest in most cases today (due to Safari) criticality is not enabled on most deployments.
    - tptacek 14y ago
      Argh.
    - lawnchair_larry 14y ago

ivanr 14y ago

Can you expand further on the practicality of the Name Constraints extension? My understanding is that not all browsers/libraries enforce them and IIRC, that certs that use them may not work in some browsers?

agl 14y ago
(Copying this reply of mine from another part of the thread as you're not the only person to ask.) Name Constraints support is pretty good in modern certificate libraries. It's certainly in CryptoAPI these days which accounts for the bulk of users. But there are two ways to use Name Constraints: they can be marked critical or non-critical. Critical Name Constraints are great, but they will cause anything that doesn't support Name Constraints to reject the certificate. This is obviously a problem because few deployments have much control over their client base. Non-critical name constraints provide a security benefit to clients that support them without affecting those that do not. Clients that don't support them are vulnerable to misuse of the constrained certificate, of course, but since the alternative is often an unconstrained, CA certificate, it's still a clear win.
- rmhrisk 14y ago
  I agree with Adam, support is actually quite good in modern libraries and this is in no small thanks to the good folks at NIST who published the PKITS tests for chain engines - http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitest... Many libraries built these into regression tests for their chain engines and the suite covers name constraints pretty good.
  - marshray 14y ago
    If support is really that good, then you should have no problem following the RFC requirement that the name constraint extension be marked 'critical'.
    - rmhrisk 14y ago