6 ms·

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 consi

by 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".
        marshray 14y ago
        Oh dude, make my day! :-)
marshray 14y ago
http://tools.ietf.org/html/rfc5280#section-4.2.1.10 http://tools.ietf.org/html/rfc5280#section-4.2.1.10 4.2.1.10. Name Constraints ... Conforming CAs MUST mark this extension as critical
- tptacek 14y ago
  And? So they're not RFC compliant. Lots of things aren't.
  - marshray 14y ago
    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.

by ivanr 14y ago

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".
      - marshray 14y ago
        Oh dude, make my day! :-)

marshray 14y ago

http://tools.ietf.org/html/rfc5280#section-4.2.1.10 http://tools.ietf.org/html/rfc5280#section-4.2.1.10 4.2.1.10. Name Constraints ... Conforming CAs MUST mark this extension as critical

tptacek 14y ago
And? So they're not RFC compliant. Lots of things aren't.
- marshray 14y ago
  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.