Hacker News Reader

Comment by 1vuio0pswjnm7 | Hacker News Reader

https://en.wikipedia.org/wiki/Trust_on_first_use#First_known...

Firefox is the only browser that ships with a built-in trust store. Other browsers use your operating system’s trust store and you can add & remove trusted CA certs from that trust store using OS-specific utilities.

The big three root store programs are run by Apple, Microsoft, and Mozilla/NSS. Most (all?) Linux distros are based on the Mozilla store. Until recently, Google also used Mozilla’s store for things like ChromeOS and Android. They just recently announced that they’re gonna start running their own program though.

FWIW the browsers seem to do a pretty good job of policing CAs. Probably better than most end-users would do.

Browsers do a crappy job in general for any CA usecase that isn't https on public websites. Guidelines for the WebPKI are, of course, very web-centric. E.g. short lifetimes may be acceptable there. Automated frequent reissuance may be an option. But if you e.g. look at email and auth certs, possibly stored on a smartcard, things are quite different. Lifetime should be long and can be long, because the key is used rarely (compared to webservers) and maybe stored in dedicated smartcards. Verification is another thing thats totally different for an email address or a person's name.

Can users remove CA certs from ChromeOS and Android?

Good question. I know you can add a root CA cert.

I’m on iOS and don’t have an Android or ChromeOS device handy. I don’t see a way to remove a cert from Apple’s iOS trust store (settings just tells me what store version I’m running). There may be a way to do it using mobile device management (MDM) tools.

On Android (Galaxy Note9 in my case), you can disable any CA certificate from being used. There's a "view security certificates" screen with the ability to disable each individually.

It would be nice to use a hybrid: (only) Trust CA on first use. But I guess in practice some random company is much more likely to misplace their keys than you are to be mitmed by CA's.

Also, the Web PKI model has no real granular authorization when it comes to which CA can issue for which domain. A trusted CA can issue for any domain. So if you TOFU in my CA to connect to my website you’re also allowing me to issue for google.com.

Obviously this is all addressable in theory, but now you’d need some kinda policy system baked in pretty much everywhere.

No I meant like this:

Your website hands me a cert. I have never seen it before so I make sure CA says it's legit. From then on I keep using that same cert to connect to you, and CA no longer matters.

I haven't checked/verified recently but from your comment I'm guessing that the major browsers still don't support (i.e., enforce) the Name Constraints extension?

There are CAA records in DNS, but those are far too weak. The CAs are supposed to check them at issue-time. To be useful, the clients would have to check them at acceptance-time.

That wouldn't quite work the way you think it would...

The CAA record is useful only at the time a certificate is issued (signed) by a CA.

A client has no way to know what the CAA record was at the time the certificate was issued -- a browser cannot ("at acceptance-time") use the current value of the CAA record to determine whether a certificate was properly issued or not.

Reply on news.ycombinator.com