[jameshart]

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

[pzb]

There is such a thing -- name constraints. It allows exactly what you describe, limiting the valid names for certificates signed by the certificate.

[amluto]

Name constraints don't work [1] [2]. It's a nice thought, though :-/

[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... [2] http://middleware.internet2.edu/pki06/proceedings/chadwick-n...

[jameshart]

Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...

[h4xar]

You mention that the revocation-check problem is old, which is certainly true, but I think you allude to the possibility that a domain-registry-based hierarchy will exacerbate that problem in the form of an increase in revocation checks. I'm not sure that would be the case; it should be about the same. What difference does it make if I owned a domain, got a cert from a CA, and stopped owning the domain -- vs -- got that cert from my registrar? If anything this helps the process, because my registrar knows when I stop owning the domain whereas a CA has no clue and relies on the cert's expiration date exclusively.

[jameshart]

I guess you're right - I was considering the fact that someone once owned a domain was a threat, but it is already.

But with a delegated chain of certs, the problem does get worse - not least because you'd require individual domains to manage their own certificate revocation.

But since there's basically no secure way to obtain CRLs or perform OCSP cert validation, it's kind of moot.

[jessaustin]

I think this is kind of backwards? I.e. a CA that implements name constraints for one of its sub-CAs does limit the certs that sub-CA may sign. However, name constraints do not allow one to say "for this domain, only this sub-CA may sign certs", which is more what I feel we're looking for here?

[darkarmani]

> There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

As currently implemented this is mostly correct. I don't think the CAs want that situation to change, but it really harms the usability of the entire system.

[handsomeransoms]

This is the problem that pinning is intended to solve.