How's the support for X.509 "Name Constraints" these days:
* https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Would restricting it to only dot-ir domains be a mitigation?
How's the support for X.509 "Name Constraints" these days:
* https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Would restricting it to only dot-ir domains be a mitigation?
The main technical way I know of doing this would be by putting TLS public keys in DNS (DANE, RFC 6698), but then you have to make sure that DNS packets are not fiddled with, so you need to bring in DNSSEC.
It would be great to have a widely-recognizable pseudodomain out there where the names were key hashes. It would actually graft really easily into DNSSEC. The zone format doesn't have to change at all; you just declare that if the KSK hash matches the domain label under this specific TLD, you don't need to check upstream of that. Then you add a P2P protocol for getting the actual data, and start slowly pushing that protocol down the resolver tree to incrementally decentralize everything.
What would you suggest as an alternative? TOFU?
I could see that for local applications (e.g. making mDNS/.local and private IP certs TOFU capable by default would be amazing, and maybe even for some explicit hobbyist public TLDs?), but I don’t think I’d love it for my bank or email provider.
I think some servers do not send a copy of the root certificate to the client. In this case, what I described above might already be possible even if that feature has not already been added to existing implementations, as long as it does not require the installed certificate to be self-signed.