Being able to partially distrust a Certificate Authority is good | Hacker News Reader

Being able to partially distrust a Certificate Authority is good

utcc.utoronto.ca

52 pointszdw14 comments

It would be good to be able to only trust CAs with some TLDs. That would limit the harm for adding a geographically useful CA to only a certain segment of the internet.

One of the problems with domain restrictions on CAs is that real world geography has turned out to not correlate with domain name 'geography' for general use. Organizations located in a country (or the EU or etc) will register their domains all over, instead of nicely restricting themselves to something under a single TLD or a small number of them, where they could use a restricted-scope CA. This mostly leaves you with organizational CAs, such as government ones (for the government's sites), and they seem to not have been too popular in practice.

Seems like it would mirror how the registrar system works, where some registrars are able to register most TLDs and some are more regional.

I'm guessing that for some TLDs it would make even more sense like for .gov or .google or similar.

The ability exists. Such constraints aren't used very often for root certificates though, as far as I can tell. The Japanese Government CA which was mentioned in the discussions around TrustCor was constrained to .go.jp.

It needs to be supported in the clients, both browsers and libraries. I'm actually mad that scope restrictions are not more commonly used, and that tooling is absurdly complicated.

It would be useful for internal CAs too, because they could be trusted for only a specific subdomain, eg *.intranet.acme.com.

The previous article discussed on HN:

https://news.ycombinator.com/item?id=33876949 (> 100 comments)

Regarding backdating: isn't there a thing like a log that cannot be fudged with? I.e. if you issue a cert now with date y - 1, it needs to be on the log at y - 1. Which will invalidate al l entries after that. Like a hashlist (I don't want to say the other word)

You're describing certificate transparency: https://certificate.transparency.dev/howctworks/

Certificate transparency doesn’t prevent cert backdating, because certs can be included in logs long after they’re issued.

It would be possible to require certs be included in logs before some cutoff time but no browsers do that today.

It does provide a mechanism that cert backdating can be detected, if new never before seen certs keep showing up from a partially distrusted CA.

Your last paragraph seems pretty key to me.

Should be a choice by user these days. It may break the browser. But not the net.

In theory Firefox in the linked thread did exactly that: They said TrustCor has X number of days to reply to allegations. It sounds like you're proposing a technical solution to a offline solution that already exist.

Chris is explaining why the way browsers currently handle this problem is good, not proposing they act differently.

He did propose that Linux act differently (https://utcc.utoronto.ca/~cks/space/blog/linux/CARootStoreTr...), and this post is a follow-up explaining the value browsers get out of this partial-trust situation.

but everyone disagrees.

a sketchy CA should not be given the benefit of the doubt. and customers of sketchy CA should suffer for not doing their homework and should rightly scramble to secure certs from other providers to resume their business.

the only sin of kernel/distro maintainers is not dropping those CAs faster.

what browsers did is the ultimate sin of sacrificing users to not be blamed by something they are fixing under the guise of backward compatibility.

Reply on news.ycombinator.com