> Since the aforementioned improvements have shipped in production browsers, it is much more practical, from a technical standpoint, to do that.
What about non-browser HTTPS/TLS libraries? Even if browsers support it perfectly, this doesn't seem like something CAs should start deploying if widely used libraries have problems with it. And based on the test results from BetterTLS, it looks like widely used libraries still have problems with it.
Also, the BetterTLS article gives an example of a NameConstraints for "192.168.0.0/16"; I don't think that's something a public CA could reasonably issue, for a variety of reasons (conflicts with routers, IoT devices, and many other things). We need some reasonable solution for "local network" devices, and in particular for devices where a user may be able to get hold of the private key, but in the meantime I don't think publicly valid IP-address certificates make sense.
> The CA that issues you the intermediate CA certificate would be on the hook, with the consequence of being removed from the root CA programs, if you issued a malformed certificate.
Given that today, such an intermediate CA could be used for arbitrary MITM, that's entirely understandable. If there are additional constraints that an intermediate certificate needs to have, we need to have enforcement mechanisms to support such policies, so that an intermediate CA can't create certificates that may lead to MITM or similar attacks.
- Root CA policies for proving access to (star).yoursite.example such that you can get an intermediate CA.
- Root CA policies for the valid duration of intermediate CA certificates (no longer than X, no longer than the proven ownership of your domain...). This already constraints the valid duration of certificates underneath the intermediate CA.
- Policies for requiring Certificate Transparency (e.g. any such intermediate certificate still has to use CT logs, such that individual certificates must appear in the CT logs to be considered valid). This could be done by policy in browsers, such that any CA opting into issuing intermediate CA certificates must use CT for everything; that's where we're going for all CAs anyway.
- Do we have mechanisms to ensure that an intermediate CA can't issue another intermediate CA certificate?
- Policies for wildcards underneath intermediate CAs. If you have an intermediate CA for (star).yoursite.example, under what circumstances can you issue a wildcard certificate underneath it, and for what domains?
- Under what circumstances should you be able to get an intermediate certificate for something like (star).yoursite.internal? Should you, or should all names chain up to a domain you prove ownership of (e.g. (star).internal.yoursite.example)? There's potential value in internal-only domain names, and this would reduce the scope of attacks (preventing the intermediate CA from issuing certificates for your public site), but ownership issues might become tricky.
- Related: Today, if you want to MITM example.com, you need to get a root CA to sign your certificate. If example.com obtains an intermediate CA, it's potentially easier for an adversary to somehow obtain a certificate for example.com or www.example.com signed by that intermediary, depending on example.com's infrastructure. (It's also potentially easier for an adversarial jurisdiction to force example.com to surreptitiously mint a certificate; CT would help there, but this still seems like substantially more attack surface.) Is there some way we can make that less likely and more difficult as an exploit vector?
- Policies for the duration of certificates underneath intermediate CAs.
- Policies for handling revocation of certificates underneath intermediate CAs.
- Policies for the use of dedicated HSMs for intermediate CAs. Should we make that a policy requirement?
- Eventually, when NameConstraints becomes not only usable but best-practice for intranets, browsers and libraries could start defaulting to only loading certificates from the system certificate store iff they have NameConstraints that meet some appropriate policy.
> Since the aforementioned improvements have shipped in production browsers, it is much more practical, from a technical standpoint, to do that.
What about non-browser HTTPS/TLS libraries? Even if browsers support it perfectly, this doesn't seem like something CAs should start deploying if widely used libraries have problems with it. And based on the test results from BetterTLS, it looks like widely used libraries still have problems with it.
Also, the BetterTLS article gives an example of a NameConstraints for "192.168.0.0/16"; I don't think that's something a public CA could reasonably issue, for a variety of reasons (conflicts with routers, IoT devices, and many other things). We need some reasonable solution for "local network" devices, and in particular for devices where a user may be able to get hold of the private key, but in the meantime I don't think publicly valid IP-address certificates make sense.
> The CA that issues you the intermediate CA certificate would be on the hook, with the consequence of being removed from the root CA programs, if you issued a malformed certificate.
Given that today, such an intermediate CA could be used for arbitrary MITM, that's entirely understandable. If there are additional constraints that an intermediate certificate needs to have, we need to have enforcement mechanisms to support such policies, so that an intermediate CA can't create certificates that may lead to MITM or similar attacks.
- Root CA policies for proving access to (star).yoursite.example such that you can get an intermediate CA.
- Root CA policies for the valid duration of intermediate CA certificates (no longer than X, no longer than the proven ownership of your domain...). This already constraints the valid duration of certificates underneath the intermediate CA.
- Policies for requiring Certificate Transparency (e.g. any such intermediate certificate still has to use CT logs, such that individual certificates must appear in the CT logs to be considered valid). This could be done by policy in browsers, such that any CA opting into issuing intermediate CA certificates must use CT for everything; that's where we're going for all CAs anyway.
- Do we have mechanisms to ensure that an intermediate CA can't issue another intermediate CA certificate?
- Policies for wildcards underneath intermediate CAs. If you have an intermediate CA for (star).yoursite.example, under what circumstances can you issue a wildcard certificate underneath it, and for what domains?
- Under what circumstances should you be able to get an intermediate certificate for something like (star).yoursite.internal? Should you, or should all names chain up to a domain you prove ownership of (e.g. (star).internal.yoursite.example)? There's potential value in internal-only domain names, and this would reduce the scope of attacks (preventing the intermediate CA from issuing certificates for your public site), but ownership issues might become tricky.
- Related: Today, if you want to MITM example.com, you need to get a root CA to sign your certificate. If example.com obtains an intermediate CA, it's potentially easier for an adversary to somehow obtain a certificate for example.com or www.example.com signed by that intermediary, depending on example.com's infrastructure. (It's also potentially easier for an adversarial jurisdiction to force example.com to surreptitiously mint a certificate; CT would help there, but this still seems like substantially more attack surface.) Is there some way we can make that less likely and more difficult as an exploit vector?
- Policies for the duration of certificates underneath intermediate CAs.
- Policies for handling revocation of certificates underneath intermediate CAs.
- Policies for the use of dedicated HSMs for intermediate CAs. Should we make that a policy requirement?
- Eventually, when NameConstraints becomes not only usable but best-practice for intranets, browsers and libraries could start defaulting to only loading certificates from the system certificate store iff they have NameConstraints that meet some appropriate policy.