Hacker News Reader

Comment by e12e | Hacker News Reader

> There is no API to actually handle trust.

We might need something more - but I wonder i trust-stores could be modified so that:

- every device get a "host" CA (like a ssh key)

- this CA is the only one trusted

- in turn, this CA signs issuer/top-level CA (or even cross-signs the intermediary certs directly) (eg with - new/-force_pubkey)

Additional logic could be applied in the signing step - say rules to set the validity, or rules to sign/not-sign. One might set a 48h lifetime, and run a crown job every night - allowing for "dynamic" "revocation" (cert expiry).

Not sure if this would work out of the box though - I have not looked that deep into ca and ca trust.

View on HN

Certificates advertise if they're meant to be roots or not and libraries enforce that via things like the path length constraints, so it wouldn't work. But it also just seems kind of complicated - how is that any easier than just updating the root store in a cron job, which is already done via normal package maintenance routines anyway?

The reason the Linux root stores don't have a notion of 'trust until' like the article wants is simple - nothing stops an untrusted CA just issuing certificates that claim to have been issued before the cutoff, so it seems pointless. Browsers have ways to tackle that like Certificate Transparency or crawling the web to try and identify every extant cert, but most apps don't use that.

Linux root stores could piggyback on the browsers' efforts here though. The attack scenario you described was sensible in the past, so it didn't make sense for non-browser clients to go ahead with "trust until".

However, now CAs can't really do this anymore, because - as you say - they'd risk immediate exclusion from browsers if this is detected via CT analysis. So Linux distros can actually benefit from CT and browser's impact in the CA space in an indirect manner.

There is definitely a power imbalance though. E.g., even if a distro implemented "trust until", they could not realistically make their own rules that are stricter than what browsers do: CAs could backdate certs so they get accepted by the distro, but if browsers consider the CA fully trusted, they might not care about the backdated certificates.

I think it's more that Linux root stores date from an era when everyone approached CA trust as a binary thing (even browsers), and there has never been enough pressure and coordination to evolve them into a more complex system, unlike browsers. My memory is that browsers added conditional distrust and conditional limits on CAs and various similar things when they became convinced that it would be too bad of a user experience to simply remove CAs but also too dangerous to retain them in fully empowered form. Having conditional distrust also gave browsers more power over CAs, because now browsers had more options for dealing with marginal but (semi-)popular ones.

(I'm the author of the linked-to entry.)

Reply on news.ycombinator.com