Your CAC has never checked who you are

A Common Access Card authenticates a certificate, not a person. The distinction is not rhetorical. When a CAC is inserted into a reader and a PIN is entered, the relying system does not confirm that a specific human being is present. It confirms that a private key held on the card can produce a valid signature, and that the corresponding X.509 certificate chains to a trusted DoD PKI root. The card is a container. The certificate is a claim. The signature is evidence that the claim’s key material was accessible at that moment. None of that establishes identity in the sense the word is normally used.

What the system actually executes is a sequence of checks with a narrow scope. It walks the certificate chain to a trust anchor it already holds. It confirms the current time falls between the certificate’s notBefore and notAfter fields. It consults revocation state through a Certificate Revocation List or an OCSP responder, if it is configured to consult anything at all. When those checks pass, it emits an authentication decision. That decision is a statement about cryptographic validity and certificate status. The system then permits access as though the question answered had been a question about a person.

This is not a flaw in the CAC or in X.509. It is the designed behaviour. The DoD PKI was built to answer one question quickly and repeatedly: does this key material correspond to a certificate my trust anchor has vouched for. It answers that question well. The gap opens where the answer to that question is treated as the answer to a different question, one the system was never built to ask. The certificate is present. The person is inferred. The system optimized for verifiable key possession, and verifiable key possession is what it delivers.

The trust model underneath the CAC is hierarchical, delegable, and durable within a fixed window. A root certificate authority signs intermediates. Intermediates sign end-entity certificates issued to enrolled personnel. Trust flows downward by reference. No relying party independently re-establishes who the holder is. Each one verifies only that a chain terminates at an anchor it has decided in advance to trust. The judgment that matters was made once, at the certificate authority, and every downstream system inherits it rather than reproducing it.

That model rests on three assumptions about the nature of trust. The first is persistence: trust granted at issuance holds for the entire validity period, commonly around 3 years, unless something actively cancels it. The second is transferability: the binding decision made by the certificate authority is accepted, unquestioned, by every system that trusts the same root, from a badge reader to a VPN concentrator to a web application front end. The third is validity as a default state: a certificate is treated as good until it expires or is explicitly revoked, and revocation only takes effect if the relying party bothers to check and the check succeeds.

Taken together, these assumptions concentrate trust at the anchor and stretch it across time. The enrolled identity and the current key holder are assumed to be the same entity for the life of the certificate. The relying system does not carry a model of the person. It carries a pointer to a decision the certificate authority made in the past. In the DoD PKI, as in any X.509 hierarchy, the strength of every authentication event is the strength of that original enrollment, projected forward and copied sideways to every system that shares the root.

What changed is not attacker capability and not the cryptography. What changed is the validity of the equivalence the system depends on: that possession of an unrevoked certificate is the same thing as authorized presence of the enrolled identity. That equivalence is established exactly once, at enrollment, when a specific person is bound to specific key material. The system never re-establishes it. It references it. And the conditions that made the binding true at the moment of issuance do not hold constant across 3 years. Roles change. Cards move through shared operational environments. Key material can be cached, extracted, or copied depending on how and where it lives. A PIN can be observed or entered under compulsion. The binding is a snapshot the system keeps treating as a live feed.

The system did not re-evaluate trust because it was never built to. It resolved the trust question at issuance, and every authentication afterward is a lookup against that resolution, not a fresh evaluation of it. The only mechanism for correcting a stale decision is revocation, and revocation is a negative signal that has to propagate to be real. CRL freshness, OCSP responder availability, and the relying party’s own configuration decide whether a certificate whose real-world binding has already dissolved is actually rejected. In practice, a system inside the DoD PKI can accept a certificate that no longer describes an authorized state, because it is checking the reference and the reference still says yes.

The assumption that a valid certificate equals an authorized person was true at one moment and is treated as true for the whole window. That is the drift. Nothing broke. The X.509 chain still verifies. The root is still trusted. The signature is still valid. The system continues to inherit trust from a past state that may no longer describe the present, and it has no built-in reason to notice the difference. That assumption held at enrollment. It does not hold continuously. The system behaves as if it does.

The failure is not a bypass. Nothing in the sequence is skipped, forged, or defeated. When a CAC certificate is presented, the relying system resolves a set of references and returns the answer those references produce. It asks whether the chain terminates at a DoD PKI anchor it already holds. It asks whether the current time sits between the certificate’s notBefore and notAfter fields. It asks a revocation source, a CRL or an OCSP responder, whether the serial number has been listed. Every one of these is a lookup. None of them opens the content of the claim and tests it against the present. The system references validity. It does not reconstruct it.

What the mechanism substitutes is identity of source for integrity of content. The certificate authority’s signature is a statement about origin: this certificate was issued by an authority I trust, to a subject that authority enrolled. The signature says nothing about whether that subject and the current key holder are the same entity at the moment of authentication. The relying system treats verified origin as though it were verified content. Because the source is trusted and the signature over it checks out, the claim inside is admitted without independent test. Integrity of the live binding is inferred from identity of the issuer. These are two different properties, and X.509 was never built to collapse them into one.

Revocation is the only mechanism that could correct a stale reference, and it is a negative signal that has to arrive to matter. An OCSP responder that is unreachable, a CRL that is hours or days behind, a relying party configured to proceed when status cannot be retrieved: each of these resolves to acceptance, because acceptance is the default and revocation is the exception that must be proven. From outside, the behaviour is indistinguishable from a fully valid authentication. The system emits the same decision. A certificate whose real-world binding dissolved yesterday and a certificate issued to the person standing at the reader produce the same result, because the reference still says yes and the system was built to act on the reference.

The pattern is execution based on reference rather than verification. A system resolves a pointer to a decision made somewhere else and at some earlier time, confirms the pointer is well-formed and still nominally in date, and then acts as though it had performed the underlying evaluation itself. The evaluation happened once. Everything after it is dereferencing. This is not an accident of implementation. It is the economics of the design: verification is expensive and must be repeated, while reference is cheap and can be cached, copied, and distributed across every system that shares the anchor.

The same structure runs under OAuth 2.0. RFC 6750 defines the bearer token, and its defining property is that any party in possession of the token may use it. The resource server grants access on possession. The authorization server made the real decision at issuance: this subject, these scopes, this lifetime. The resource server does not re-establish any of it. It validates the token, confirms it has not expired, and, if it is configured to, consults an introspection or revocation endpoint. These are the same three questions the DoD PKI asks of a CAC. Does this resolve to something I trust. Is it inside its window. Has anything cancelled it. And it is the same substitution: possession of a valid reference standing in for the authorized presence of the party the reference was issued to.

A smartcard in a reader and a token in an HTTP header share almost nothing at the protocol level. X.509 chains and JWT bearer tokens are different objects moving through different systems. The failure mode is identical because the trust structure is identical. Both concentrate the real decision at an issuing authority. Both project that decision forward across a validity window. Both distribute it sideways to every relying party that trusts the issuer. Both depend on a negative signal propagating in time to overturn a binding that has already changed in the world. Reference is not verification. A system that dereferences a past decision is not evaluating the present, no matter how correctly the dereference executes.

A Common Access Card resolves identity once, at enrollment. For the roughly 3 years that follow, every authentication is a reference to that single resolution, not a fresh evaluation of it. The system does not revalidate, because it was never built to.

The chain verifies. The signature is valid. The reference still says yes. None of that describes who is at the reader.

The control exists. The authentication is real. The assurance it was built to produce is not.