Infrared: The Next-Generation Validation Framework To Meet The Challenges of Next-Generation PKI
See it in action. Infrared already powers a live Merkle Tree Certificate CA cosigner validator.
A single non-compliant certificate triggers a mandatory five-day revocation clock. That five days lands on your customers as an unplanned certificate replacement that leaves them scrambling. Repeat the pattern and it becomes an existential crisis, the kind that gets a CA’s incidents cited by name in a browser distrust announcement. And, every one of these events degrades confidence in the integrity of the Web PKI.
The unfortunate part is that much of this non-compliance is machine-detectable, yet it still ships. Some of the most damaging cases come from a certificate simply disagreeing with the CA’s own CP/CPS. That divergence triggers revocation even when the certificate is otherwise perfectly well-formed. It is the problem I detailed in Certificate Profiles Need a Single Source of Truth. This type of non-compliance happens because the tools most CAs rely on to catch it are blind to the categories of problem that now cause the most damage.
Linters raised the bar but have their limits
Industry standard linters such as zlint and pkilint (which I architected and maintained while at DigiCert) are wired into CA issuance pipelines as pre-issuance checks. These checks have eliminated whole categories of mis-issuance. For example, an ASN.1 encoding mistake that would have triggered a mass revocation event now fails a check before any certificate with the issue is signed.
But almost every linter in production shares one limitation, and it is exactly the limitation that lets the damaging incidents through.
Linters see one certificate at a time
A per-certificate linter takes a single certificate as a DER blob or PEM file. It applies rules encoded from the Baseline Requirements or other policies and the relevant RFCs. Then it tells you whether that one artifact is well-formed. This is the right approach for catching an overly-long serialNumber or a malformed subjectAltName. However, it is the wrong way to prevent a growing set of problems that only exist in the relationships between certificates and the trust context around them.
Consider what a per-certificate linter cannot see:
- Issuer and subject relationships. Whether a subordinate CA has the right policy OIDs to issue trusted EV certificates, or whether an EKU chains coherently from the root to the leaf is not a property of any single certificate but rather a property of the certification path.
- The wider trust context. CCADB carries information about which roots are trusted and what capabilities they have. A linter looking at a leaf certificate has none of this. It cannot tell you that a certificate chains to a CA whose audited scope does not cover the profile it just issued.
- CA-specific profile elements. Every CA layers its own changes on top of the Baseline Requirements profiles: which policy OIDs it asserts, which extensions it includes, and how it populates subject attributes. Generic linters cannot check any of this, because the rules live in the CA’s own CP/CPS rather than in a shared specification.
Issues stemming from the items above are not rare. In reality, they are where a large fraction of today’s incidents actually originate. The linter passed, but the certificate still should not have been issued, because it disagreed with something the linter was never given access to.
New standards call for a new model
At the same time, the ground is shifting under the profiles themselves. Merkle Tree Certificates (MTCs) do not look anything like a traditional X.509 PKI. Under active standardization in the IETF PLANTS working group, Google is looking towards Merkle Tree Certificates as the technical underpinning of its next-generation, quantum-resistant root program. MTC replaces per-certificate issuer signatures with inclusion proofs. It introduces cosigners as first-class trust participants. It reorganizes issuance around transparency logs from the start, rather than bolting transparency on afterward.
Mechanically, the infrastructure to run a Merkle Tree Certificate-based PKI is far more complex than traditional PKI. In addition to its traditional signing and key management infrastructure, the CA also must operate transparency logs to publish certificate issuance. These logs use newly developed primitives and protocols, none of which are supported by any linter today. And, to remain trustworthy, these logs must adhere to strict consistency and integrity requirements.
A validation framework that can monitor such infrastructure and catch potential problems before they manifest into real issues needs to break away from the traditional single-certificate linting model and take a new approach.
What Infrared does differently
Infrared is a PKI validation framework built around the assumption that full validation is only possible when the full trust context is provided to the validator. Validators can pull in the full certification path, CCADB data, a set of trusted cosigners, or a CA’s own declared profile. Then they evaluate the certificate against all of it. Infrared can run the same well-formedness checks a traditional linter does, but it treats them as the starting point rather than the whole job.
It is also deliberately extensible. Encoding a CA-specific profile, a new relationship check, or the rules for an emerging standard is a first-class operation. The point is to let the people who actually know a given profile express it as something machine-checkable. When they can do that, the profile and the practice statement stop being two hand-maintained copies that drift apart.
And it does this without asking you to trade away speed. Context-aware validation sounds like it should be slower than single-certificate linting with traditional linters, but it is not. Initial benchmarking shows that Infrared runs 5 to 20 times faster than zlint, depending on the workload.
Here is a concrete example. I used Infrared to build a Merkle Tree Certificate CA cosigner certificate validator, which you can try right now. It validates a real, emerging post-quantum PKI object that no existing linter addresses. Support has already been added to validate other Merkle Tree Certificate artifacts, such as TBSCertificateLogEntry structures encoded in tiles. Adding support for monitoring CA cosigner logs to ensure operational correctness is planned.
Where this is going
The next phase of PKI tooling is context-aware validation. Infrared is my attempt to build the framework for that. But I would rather build it around the problems you are actually facing today.
What challenges is your organization running into that per-certificate linting cannot reach? Think about profile-to-CPS alignment, path and relationship checks, consistency against CCADB, and readiness for MTC and whatever follows it. These are the problems Infrared is designed to grow into, and I would like to build it out against real ones.
If any of this is close to what you are dealing with, I would be glad to show you more of what Infrared can do and talk through your specific challenges.