Hacker News Reader

Comment by bombcar | Hacker News Reader

You can have it "both ways" if you want, but it quickly becomes very muddy - defer to the OS, but override the deferral in some cases.

Certificate management is fifty kinds of all messed up - and in THEORY everything is designed perfectly and properly, in practice it's all bandaids on bandaids that nobody cares about as long as "things mostly work".

View on HN

This doesn't have the vibes of something that's designed perfectly even in theory. This more has the vibes of "this was the least worst option"

If you look at the FULL design, it's actually pretty good - things like https://en.wikipedia.org/wiki/Certificate_revocation_list CLRs have actual thought behind it - but I know of no system that actually IMPLEMENTS everything, for various practical reasons.

So from a spherical cow perspective, it's well-designed; from a "this has to work in the real world with real things and people" it's ... workable by violation of the design all the time.

I would argue for anything security - if there is a difference between how it works in theory vs in practice - then the theory is flawed. Physics gets to have theory/practice distinctions, but engineering doesn't because the bridge can't fall down.

Exactly, and it's a very real problem with the IETF-way of building things, and why "this is what Chrome does, copy it" becomes the real standard.

In Physics, if a theory doesn't describe reality, the theory is incomplete. Of course all theories are ultimately incomplete, the goal is to find theories that match reality better than the ones before.

Trust relationships are fundamental even in the most abstract view of the Web PKI and without the band-aids of Certificate Transparency etc. that trust relationship is: Some random commercial entities that are completely independent of the DNS, make fully trusted statements about the validity of DNS record ownership. It's bonkers to the core. If someone would design it from scratch, of course the domain registrars would be the ones issuing the certificates via their established relationship to the customers, and they would only be able to issue them for the domains they are responsible for. And no: DNSSec does not solve the same problem and is a tragedy all of its own.

In a roundabout way that’s effectively where we are now since everybody and everybody uses lets encrypt certificates which are just a fancy way of saying I controlled the DNS at some point

Even before Let's Encrypt was a thing, that is how most DV (Domain Validated) certs were issued. It was just a more manual, more expensive process to do it. GP's point is since the system depends completely on trusing the DNS chain anyway, why not have the registrar [sic. it should actually probably be the registry] act as the CA as well and cut out the middleman, and the need to verify the domain from multiple paths to prevent MitM.

CRLs were a great (ok, maybe just ok) design in the early days when the internet was small and the number of CAs and revoked certificates was small. But it was never going to be scalable. And it has the really big problem of needing to distribute these lists of revocations. OCSP has a different set of tradeoffs.

Reply on news.ycombinator.com