> However, the thing about ACME is it's built out of existing standard components such as Certificate Signing Requests. So instead of attack surface in Python, or Bash, or C, and trying to mitigate it with local sandboxing, you can choose to hand the CSRs to a completely separate system and so to literally airgap your private keys and all the TLS server code from your ACME implementation if you want.

> You can use CSRs with Certbot, you can use CSRs with acme.sh, but, they aren't an option with OpenBSD's acme-client at all.

acme-client uses a privilege separated process model (using pledge and unveil) so that private keys are never loaded or accessible to the network-facing process.

And it's not just acme-client that does this. Most OpenBSD service daemons, like httpd and smtpd, perform private key operations in a privilege-separated subprocess. The technique won't win any awards for request throughput, but it reflects OpenBSD's "secure by default" ethos, which of course always has to be understood in the context of what they're trying to accomplish.

Air-gapping the long-term account private keys for a semi-automated Let's Encrypt renewal process sounds more aspirational than anything. If you're going to attempt that, the lack of support in acme-client is the least of your problems in terms of initial and long-term operational complexity.[1]

OpenBSD tools are primarily designed for the needs of OpenBSD maintainers, and secondarily for the needs of typical OpenBSD users. These people aren't trying to build the next AWS using OpenBSD, nor are they trying to secure Apple's or the NSA's proprietary key escrow system root of trust key. "Secure by default" has to be understood in that context. And so the fact other tools support more features, some of which can be used to theoretically implement hypothetically more secure systems is sort of beside the point. Moreover, a general rule of thumb is complexity is anathema to security, and OpenBSD is rigorous about providing the fewest knobs possible while minimizing administrative burden and effective risk for their typical user base. This is why the utility and pervasive use of pledge and unveil are simply incomparable to the Linux equivalents, seccomp and filesystem namespaces; and why the fact that OpenBSD services privilege separate private key operations is something most OpenBSD users, let alone non-OpenBSD, don't even realize.

I don't really care about the exploit writers' opinions of OpenBSD. How many of them host and use their own public-facing web or e-mail servers? Attackers and defenders have completely different perspectives that sometimes lead to completely different opinions. And I definitely don't care about the consensus opinion of the security community considering that over the past decade the majority of self-described and even employed "security engineers" are neither experienced systems programmers nor experienced system administrators. Prowess with nmap and Wireshark seem to make for "hacker" credentials in this community. The depth and sophistication of their knowledge is about the same as many Node.js-cum-Rust programmers who write "parsers" and "servers" by stitching together a bunch of crates. That's not nothing, but I'm not going to attach much worth to their opinions regarding complex architectural or algorithmic problems. How many Kubernetes engineers can even understand the value of, let alone conceptualize or even implement, a pipelined series of network daemons that rigorously preserves backpressure? Why would I value their opinion on how to efficiently scale services when their measure of scalability and survivability is the ease with which you can throw more hardware or AWS account credits at a problem, and generate more Prometheus data sets?

People who use OpenBSD over the long term know perfectly well what "secure by default" means, even when they themselves might have made different choices.

[1] Not that I think air gapping is generally impossible or impractical. I've defended DNSSEC on multiple occasions for preserving this ability. And I do a lot of work with HSM, secure enclave, and smartcard integration, so I very much agree with and promote the idea of moving private key operations entirely off network-facing hosts, whether air-gapped or not. But WebPKI infrastructure tends to be operationally quite shallow and quite dynamic, making manually administered key signing operations less practical at any scale. But if someone can make it work, more power to them. In general this use case is too niche for OpenBSD to emphasize--either not enough potential utility, or invites too much complexity. The exception would be OpenSSH's recent embrace of FIDO HID USB keys, but it's not really an exception considering typical interactive ssh workflows, and considering the implementation complexity relative to the traditional ecosystem involving PKCS#11, PC/SC, PIV, etc. I don't think those latter standards are deal killers, but I totally understand and appreciate why they wouldn't see much attention from OpenBSD developers. OpenBSD continues to embrace and enhance IPSec and IKE despite the complexity, even as they integrate Wireguard; they're capable of making context-sensitive analyses.