Build a tiny certificate authority for your homelab

As it is Linux already has completely acceptable source of entropy. The most significant drawbacks are that it could potentially be observed by somebody else with access to the machine and that it provides only very limited amount of entropy. Both are not a problem when you use private RPi to generate a dozen keys for your home lab.

But let's talk about PSKs (pre-shared keys).

TLS 1.3 itself doesn't care why this PSK is used. It's true that today your Web Browser will only use it for resumption, because it offers a significant speed-up in some scenarios on second and subsequent visits.

But for IoT applications it is envisioned that a group of devices might share one or more PSKs out of band. Maybe they're a factory setup thing, maybe the devices are to be set up in close physical proximity using low bandwidth Bluetooth, then they'll build themselves a WiFi network when deployed using PSKs to secure TLS.

Browsers could do that, but all the vendors are clear there's no way they'd actually want to do that. What would the UX look like? "Please enter the hexadecimal PSK for the site in this box?". So today they only use PSKs for resumption.

The reason this one feature (PSKs) has two very different purposes is to narrow the security proof work. Mathematicians worked really hard to prove some important things about TLS 1.3 and the more extra different features it has, the less focus can be put on any particular feature.

Even as it is they missed the fact that PSKs are symmetric. If Alice and Bob have a single PSK to "authenticate" them and are both capable of serving, then Mallory can trick Alice into thinking she's talking to Bob when she's actually talking to herself. It's a small problem, but the proofs didn't cover it, and so it was not spelled out in the TLS 1.3 document that you should worry about this.

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.

But because ACME has been so successful (good!) lots of newer or updated software incorporates ACME support out of the box, and so it is attractive to be able to interface to that support.

We could have had a situation where most server software did SCEP and you needed an adaptor to reflect the SCEP requests into a system that would use ACME to get them a certificate if they face the public Internet. But that isn't what we got, so, fine, this works, I'll take it.

Then however, we get to the political question who exactly that central authority should be and why.

> Like, just last week the browsers had to remove a certificate authority from their root cert programs because Kazakhstan was issuing certificates to MiTM traffic.

I may have misunderstood the incident, but wasn't it such that the CA was not even one of the built-ins, but a "custom" root CA that all users were required to install on their systems? As such, the block was more equivalent to block a specific to TOFU key.

Of course, blocking the MITM CA won't magically turn off the ISP's MITM proxy. It will simply make it so that kazhakh citizens can't access any web sites at all until the government hopefully caves and turns off the proxy.

So most SSH users (who, on average, are way more technically competent than browser users) will automatically 1) panic and think they're being hacked, or 2) blindly trust the new key when a key change occurs with SSH. Both of these responses are dangerous. The result is that, unless you have fancy stuff for managing known hosts for all of your users on all of your endpoints, you're probably just avoiding this scenario by not rotating host keys at all for SSH. Which is also problematic.

By using a CA you're delegating the key binding to a trusted piece of infrastructure that can be locked down and monitored by experts. You can't do that easily with key-bindings written to files on a bunch of different endpoints. With a CA, end users shouldn't need to care about key changes. The fact that the CA can issue a new certificate for some entity is a benefit: it makes credential rotation easier. If you do want to know when credentials rotate there are ways to monitor that yourself (and Web PKI has ways like key pinning and cert transparency).

TLA cert authorities are bad enough. MTA-STS is would make running your own mailsever harder and leash you to one of a dozen cert authorities. If you don't think that's a problem then remember what happened to dot org, and think what will happen to these cert authorities given enough money and time.

I've run my own mailserver for a decade now and I am strongly against everything you suggest. But it doesn't matter what I care about. If everyone uses only one of a handful of email providers then they'll just slowly close off their walled gardens anyway. It's already happening no matter how many superfluous cargo-cult standards independent mailserver operators implement.

They didn't steal it. You'd hijacked it, and your hijacking failed. Go big or go home. The IETF hijacked the OID arc 1.3.6.1 and they succeeded because everybody accepted their control of that arc and it's now used everywhere, but if you hijack some namespace and then only use it on a few dozen machines nobody has heard of, that's not going to stick.

More seriously, what you've done is probably a bad idea. https://myprinter.lan/ seems unique to you, and then your new partner moves in, why doesn't the printer work? Oh right, his printer is also named myprinter.lan because you don't have globally unique namespaces.

This happens on a bigger scale at a business or other organisations of course, but it's annoying even in one household. Here's a metaphorical nickel kid, get yourself a domain in the public DNS hierarchy.