4 ms·

Developers use the RFCs to write implementations. That's what RFCs are for. In this case, GlobalSign is issuing certs that are noncompliant in a direction that

Developers use the RFCs to write implementations. That's what RFCs are for. In this case, GlobalSign is issuing certs that are noncompliant in a direction that reduces the security experienced by users of compliant implementations. I think this is wrong both in principle and in practice.

tptacek 14y ago
The alternative, which is also established practice, is to sell CA=YES certificates with no nameConstraints extension. What does the RFC say about that? Nothing. That's why bringing up the RFC is silly.
- marshray 14y ago
  CA=TRUE with no nameConstrains is valid under the RFCs. Whether or not one ought to rely upon a CA that would sell such a cert to a 3rd party is a question of trustworthiness which is (wisely) left out of scope for the RFCs. Client app developers have a "root CA inclusion program" for this reason. It's more of a business process than a technical one. Mozilla's is probably the most publicly open and well-documented inclusion policy. I believe it also explicitly forbids the practice you describe. http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html http://www.mozilla.org/projects/security/certs/policy/Inclus... We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate; [...] for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf; This requirement clearly cannot be met by a root cert under which sub-CAs with no (or noncritical) name constraints are given to 3rd parties.
  - rmhrisk 14y ago
    It does not.
    - marshray 14y ago
      So how then does "the CA take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate" when giving a 3rd party a private key which can sign a cert for any domain (and will be trusted by many clients the same as if had been issued by the CA itself)? Here you go: https://wiki.mozilla.org/CA:Communications https://wiki.mozilla.org/CA:Communications February 17, 2012 1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. Note the word "cannnot" there. It's not "prohibited by contractual agreement", it's "destroy the HSMs containing the private keys".
      - adamcaudill 14y ago
        Based on what's been said here, and on twitter (i.e. https://twitter.com/rmhrisk/status/300351604715057154 https://twitter.com/rmhrisk/status/300351604715057154 ), doesn't it appear that they are in violation of that requirement? Unless contracts and audits meet the requirement for "cannot."
      - rmhrisk 14y ago
        The root programs all allow for technical and procedural controls to meet the this criteria. There are technical controls beyond name constraints as well. Again 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) and we have controls in place that protect against such things occurring.
- kelnos 14y ago
  Another alternative is not to sell CA=YES certificates at all.

tptacek 14y ago

The alternative, which is also established practice, is to sell CA=YES certificates with no nameConstraints extension. What does the RFC say about that? Nothing. That's why bringing up the RFC is silly.

marshray 14y ago
CA=TRUE with no nameConstrains is valid under the RFCs. Whether or not one ought to rely upon a CA that would sell such a cert to a 3rd party is a question of trustworthiness which is (wisely) left out of scope for the RFCs. Client app developers have a "root CA inclusion program" for this reason. It's more of a business process than a technical one. Mozilla's is probably the most publicly open and well-documented inclusion policy. I believe it also explicitly forbids the practice you describe. http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html http://www.mozilla.org/projects/security/certs/policy/Inclus... We consider verification of certificate signing requests to be acceptable if it meets or exceeds the following requirements: all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate; [...] for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf; This requirement clearly cannot be met by a root cert under which sub-CAs with no (or noncritical) name constraints are given to 3rd parties.
- rmhrisk 14y ago
  It does not.
  - marshray 14y ago
    So how then does "the CA take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate" when giving a 3rd party a private key which can sign a cert for any domain (and will be trusted by many clients the same as if had been issued by the CA itself)? Here you go: https://wiki.mozilla.org/CA:Communications https://wiki.mozilla.org/CA:Communications February 17, 2012 1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. Note the word "cannnot" there. It's not "prohibited by contractual agreement", it's "destroy the HSMs containing the private keys".
    - adamcaudill 14y ago
      Based on what's been said here, and on twitter (i.e. https://twitter.com/rmhrisk/status/300351604715057154 https://twitter.com/rmhrisk/status/300351604715057154 ), doesn't it appear that they are in violation of that requirement? Unless contracts and audits meet the requirement for "cannot."
    - rmhrisk 14y ago
      The root programs all allow for technical and procedural controls to meet the this criteria. There are technical controls beyond name constraints as well. Again 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) and we have controls in place that protect against such things occurring.
kelnos 14y ago
Another alternative is not to sell CA=YES certificates at all.