Comment by marshray | Hacker News Reader

Comment by marshray | Hacker News Reader

Parent Full thread

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/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.

It does not.

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 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".

Based on what's been said here, and on twitter (i.e. 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."

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.

Perhaps if you described these technical controls in more detail we could reason about its security instead of by way of obscurity.

They need to meet the same criteria we do, here are some starting points but its far from exaustive:

http://www.mozilla.org/projects/security/certs/policy/

http://social.technet.microsoft.com/wiki/contents/articles/3...

http://www.webtrust.org/homepage-documents/item27839.aspx

This is very comforting. After all, it's not like any CA "trusted" under those programs ever did Bad Things; certainly, these programs loudly warned about DigiNotar, TrustWave and TURKTRUST.

Reply on news.ycombinator.com