Hey, I’m Chris

Every conversation about post-quantum risk starts with the same story: adversaries are recording encrypted traffic today and will decrypt it when quantum computers arrive. That threat — Harvest Now, Decrypt Later (HNDL) — is real, and I covered it in detail in Encryption on Borrowed Time. But HNDL has a twin that gets far less attention, and it is the one that should set your migration calendar. Trust Now, Forge Later (TNFL) uses the same mathematics to attack a different target. Instead of breaking the key exchange that protects a recorded session, it breaks the signature that anchors trust. The result is not exposed data — it is forged identity. And unlike HNDL, there is no cleaning it up after the fact. ...

I gave this talk at PA TechCon 2026 in Harrisburg on August 13. The audience was Pennsylvania state and local government IT leaders — CIOs, CISOs, procurement officers, and the county IT directors who keep the lights on with two-person teams. The premise fits in one sentence: Pennsylvania’s data has a shelf life measured in decades, and the encryption protecting it has a shelf life measured in years. Nobody has done the subtraction. ...

In July and August 2026, a coordinated cyberattack struck water systems across more than twelve U.S. states. Over a single weekend, more than thirty Minnesota water utilities lost control of their programmable logic controllers. Operators were locked out of their own equipment. Safety alarms were silently disabled while displays continued to show normal operation. Boil-water advisories went out across multiple states, and facilities fell back to manual operations — dispatching personnel to physically operate pumps and valves. ...

Enterprise certificate enrollment has a tooling problem. Most organizations run a certificate authority — often Red Hat Certificate System (Dogtag), Microsoft AD CS, or EJBCA — but getting certificates onto devices, servers, and workloads still involves brittle SCEP integrations, custom scripts, or manual CSR submission. The enrollment layer is the weak link. EST (Enrollment over Secure Transport) was designed to fix this. Published as RFC 7030 in 2013, it replaces SCEP with a modern HTTPS-based protocol that supports mutual TLS, one-time passwords, and integration with existing CAs. But production-ready EST implementations remain scarce — especially ones that meet government and enterprise compliance requirements. ...

Post-quantum cryptography is no longer a standards exercise. ML-KEM key exchange is the default in every major browser and in OpenSSH. RHEL 10 ships with post-quantum TLS and SSH enabled out of the box. DigiCert is issuing ML-DSA certificates today. But “available” and “deployed” are not the same thing. Key exchange is largely solved. Authentication — the part where certificates, signatures, and trust chains live — is not. The gap between what the standards define and what production systems can actually verify is where most of the engineering work remains. ...

Every X.509 certificate, every CRL, every OCSP response, every CSR is encoded in ASN.1 DER. If you are building PKI software in Rust, ASN.1 encoding and decoding is the foundation everything else rests on. Get it wrong, and certificates parse incorrectly. Get it slow, and your CA cannot keep up with issuance. Get it fragmented across multiple libraries, and you spend more time managing dependencies than building features. PKI.Next was using six ASN.1 crates simultaneously. We replaced all of them with synta in a single commit. This post explains why, how, and what we gained. ...

Dogtag PKI has been Red Hat’s Certificate Authority since 2005. It started as Netscape Certificate Management System, became Red Hat Certificate System, was open-sourced as Dogtag, and is now the CA backend for FreeIPA — Red Hat’s identity management platform that manages certificates, Kerberos, DNS, and SUDO for enterprise Linux environments. Dogtag works. It has passed Common Criteria evaluations. It runs in government agencies, financial institutions, and large enterprises. It has issued millions of certificates in production. ...

A Certificate Authority that only speaks one protocol is a CA that only serves one audience. Enterprise networks need EST for managed devices. DevOps teams expect ACME for automated renewal. IoT deployments require CoAP for constrained devices. Kubernetes clusters want SPIFFE for workload identity. HashiCorp shops need Vault integration. And existing Red Hat infrastructure needs Dogtag compatibility. PKI.Next serves all six from a single CA, using independent protocol server binaries that communicate with the CA through mTLS-authenticated API calls. This post explains the architecture, the protocol implementations, and why the Registration Authority pattern makes this possible without compromising security. ...

Every CA operation is an audit event. Certificate issued. Certificate revoked. CRL generated. User created. Profile modified. If you cannot prove that the audit log is complete and unmodified, you cannot prove that the CA has been operated correctly. This is not a theoretical concern — it is a certification requirement. Common Criteria Protection Profile for Certification Authorities (PP_CA v2.1) includes requirement FAU_STG.2: the CA must detect modification of stored audit records. PKI.Next implements this through HMAC-based hash chaining, where every audit record includes a cryptographic hash that depends on the previous record, creating a tamper-evident chain that detects insertion, deletion, or modification of any record. ...

A Certificate Authority has a unique constraint that most software does not: the cryptographic backend is not just a library choice, it is a compliance decision. Government customers require FIPS 140-3 validated modules. Financial institutions require hardware security modules. Development teams need fast builds without hardware dependencies. These are three different backends with three different dependencies, build processes, and runtime characteristics — and the CA business logic should not care which one is active. ...