2 ms·

I’m not talking about a name constraint — that would need to be part of the root certificate. I’m suggesting that MS add a feature to its root store to constra

by amluto 2y ago

I’m not talking about a name constraint — that would need to be part of the root certificate. I’m suggesting that MS add a feature to its root store to constrain the usage of the certificates in the store. IIRC Google’s root store has features like this.

tsimionescu 2y ago
The Windows trust store doesn't offer a verification API, I believe it simply lists the trusted certificates so that they can be looked up by verification software. That is, OpenSSL doesn't ask windows "hey, is this certificate with this chain trusted for google.com?" it asks Windows "hey, do you have a cert in the trusted root CAs with this ID? If so give it to me", and then OpenSSL will use that root cert to check if this is the real google.com. Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services. Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.
- nordsieck 2y ago
  > Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. That's a silly position to take. When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.
  - tsimionescu 2y ago
    It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
    - amluto 2y ago
      This is true, but it’s an old design that has been (in my opinion at least) obviously wrong since the very beginning of HTTPS. Microsoft could easily fix it, at least for clients that can manage to use an updated API.
      - tsimionescu 2y ago
        Microsoft has nowhere near the power to change the PKI and/or DNS. And it's not an API problem, it's a problem of where companies go to get their legitimate certs. If there are a lot of companies getting their certs for international TLDs from country CAs, or country TLDs from international CAs, then you have to wait for huge systemic changes before enforcing any kind of TLD-CA relationship.
        account42 2y ago
        Microsoft has absolute power about the restrictions they support in their root store.
        tsimionescu 2y ago
        That's irrelevant. My whole point is that such restrictions go against the whole design of the PKI, at a systemic level. It's actively harmful to try to restrict trust in a CA to certificates for a certain TLD, because the two don't have any relationship whatsoever, by design. It would be like restricting trust in a CA to certificates for sites whose name starts with a certain letter. It's exactly as meaningful from a Web PKI perspective. Could Microsoft make it so that Windows only trusts this CA for certificates on domains whose name starts with a "b"? Sure. Would it help with anything? No. Would it be actively harmful to companies whose name starts with A that are using this CA? Yes. The same thing is true for domains whose name ends in .br.

by amluto 2y ago

tsimionescu 2y ago

The Windows trust store doesn't offer a verification API, I believe it simply lists the trusted certificates so that they can be looked up by verification software. That is, OpenSSL doesn't ask windows "hey, is this certificate with this chain trusted for google.com?" it asks Windows "hey, do you have a cert in the trusted root CAs with this ID? If so give it to me", and then OpenSSL will use that root cert to check if this is the real google.com. Chrome, which is both the cert store and the client on certain OSs, might implement this limited trust. But Windows can't, except maybe for its own internal services. Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. Brazilian companies wishing to use a local CA can own .com domain names, so you'd be preventing a completely legitimate use case. Google almost certainly has a google.br domain, so if the Brazil CA is untrustworthy, they can still be used to attack Google even if you only trust them for .br domain.

nordsieck 2y ago
> Either way, this makes little sense overall. If a CA is trustable, it can be trusted to sign a certificate for any domain. And if it's not trustable, then you can't trust it for any domain. That's a silly position to take. When I lived with roommates, I trusted them. But I also locked my bedroom when I went out. Because there's no good reason to rely on trust when you don't have to.
- tsimionescu 2y ago
  It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.
  - amluto 2y ago
    This is true, but it’s an old design that has been (in my opinion at least) obviously wrong since the very beginning of HTTPS. Microsoft could easily fix it, at least for clients that can manage to use an updated API.
    - tsimionescu 2y ago
      Microsoft has nowhere near the power to change the PKI and/or DNS. And it's not an API problem, it's a problem of where companies go to get their legitimate certs. If there are a lot of companies getting their certs for international TLDs from country CAs, or country TLDs from international CAs, then you have to wait for huge systemic changes before enforcing any kind of TLD-CA relationship.
      - account42 2y ago
        Microsoft has absolute power about the restrictions they support in their root store.
        tsimionescu 2y ago
        That's irrelevant. My whole point is that such restrictions go against the whole design of the PKI, at a systemic level. It's actively harmful to try to restrict trust in a CA to certificates for a certain TLD, because the two don't have any relationship whatsoever, by design. It would be like restricting trust in a CA to certificates for sites whose name starts with a certain letter. It's exactly as meaningful from a Web PKI perspective. Could Microsoft make it so that Windows only trusts this CA for certificates on domains whose name starts with a "b"? Sure. Would it help with anything? No. Would it be actively harmful to companies whose name starts with A that are using this CA? Yes. The same thing is true for domains whose name ends in .br.