Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is given the design of the PKI and DNS. There's no relation between CA and the TLDs on the certificate being signed.


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.


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.


Microsoft has absolute power about the restrictions they support in their root store.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: