A Signature Nobody Can Verify Is Just Decoration

In October 2025, California's DMV announced a new design for driver's licenses and ID cards. Buried in the usual catalogue of physical security features was one sentence about adding a digital security signature to one of the two barcodes on the back of the card. That signature is real cryptography: a standard W3C Verifiable Credential, signed with a P-256 key, pointing at a public key published on the DMV's own domain. And for roughly six months after cards started shipping, almost nobody outside the DMV could check it.

That gap is not a story about crypto being hard. It is a story about a security feature that shipped without the one thing that makes a signature worth anything: a verifier anyone can run. If you sign anything in your job — build artifacts, SBOMs, invoices, audit logs, firmware, receipts — the California case is the most useful cautionary tale you will read this year.

What is actually on the back of an ID card

Every US driver's license carries a PDF417 barcode: a stacked 2D barcode that encodes a plain-text record of the card's fields. Most of it is boring and standardised, with three-letter codes like DCS for the name, DBB for date of birth, and DAQ for the license number. The header carries an Issuer Identification Number that names the jurisdiction.

The interesting part is the extension area. AAMVA reserves a jurisdiction-specific section prefixed with Z plus a letter: ZC for California, ZV for Virginia, ZN for New York. A generic scanner that only knows the mandatory fields simply skips these. That is a genuinely good piece of format design. You can add whatever you want without breaking every reader in the world.

Inside California's ZC section is a compressed, signed credential. The signed payload is spelled out precisely: a bitstring chooses which AAMVA fields are covered, those fields get formatted as code-plus-value, joined with newlines, sorted, and hashed. The signature covers that hash. The credential points at a public key published at a well-known URL on the DMV's own domain — a plain P-256 key anyone can download. California even ships an open-source verifier with valid and revoked sample barcodes.

That last sentence is the whole difference. The cryptography was never the hard part.

Four ways a signature turns into decoration

1. The verifier lives inside the issuer

Two states, New York and Virginia, had been signing their barcodes for years before California. But their format was proprietary, undocumented, and checkable only by the issuing DMV. That is not verification. That is a phone call with extra steps. A signature only means something to the party who needs to trust the document, and that party is never the issuer.

2. Canonicalisation is undocumented

A signature does not cover the data itself. It covers a specific sequence of bytes. Change the field order, the whitespace, the date format, or whether you include a trailing newline, and verification fails, usually with a useless error. California's spec has hard requirements: sorted, joined with newlines, formatted as code-plus-value. Miss any one of those and you get a signature that is mathematically valid and practically uncheckable.

3. Keys are unfindable or unrotatable

Documenting the algorithm but not where the public key lives is the same as not documenting it. And the question nobody asks until year two is: what happens when you rotate the key or revoke a device? Revocation is where verification systems quietly die. If your design has no revocation story on day one, you do not have a verification system. You have a signing ceremony.

4. Documentation ships months after the feature

California announced the signature in October 2025. Detailed documentation of what signs what, which fields are covered, and where the key lives arrived the following April. In the interim, cards were in circulation with real signatures that no outside party could validate. Documentation is not a follow-up task. It is part of the security boundary, and it needs to ship in the same release as the signature.

The trick that makes proprietary pointless

Here is the part that should change how you think about undisclosed formats. ECDSA, the signature scheme used on these cards, has a property most engineers never touch: given a signature and the exact message it signed, you can recover candidate public keys that could have produced it. You get a small set per signature, but signatures from the same signer narrow to a single shared key.

Which means an undocumented signature is not opaque. It is just undocumented. A researcher found that Canadian Bank Note, the vendor that produces IDs for New York, Virginia, North Carolina, South Carolina, and Wisconsin, implements digital signatures in all five. Inside is an Ascii85 string that decodes to a DER structure: a sequence of two 256-bit integers. That is the canonical on-the-wire encoding of an ECDSA signature over P-256. The blobs come out at 70, 71, or 72 bytes depending on the card, which is exactly what you would expect, because DER drops or adds a leading byte depending on whether the high bit of each random integer is set. A hash or a counter would not wobble like that. A pair of random 256-bit integers does.

The only missing ingredient was the signed message itself, and it turned out to be the entire payload, including the signature field. Before signing, that field is filled with a placeholder — a repeated zero, padded to the field's exact length — and overwritten afterwards. Reconstruct that convention and the key falls out.

Two lessons. First, obscurity protects nobody except the people who need to verify your documents, who are exactly the people you are trying to reassure. Second, your placeholder conventions are part of your spec. A single undocumented rule about a padding character can block third-party verification for years.

A checklist for anything you sign

1. Write the verification spec first. If you cannot describe, on one page, how a stranger reconstructs the signed bytes, you are not ready to ship the signer.
2. Publish a verifier, not just a format. A reference implementation with test fixtures is worth more than a spec document, and it forces you to resolve ambiguity.
3. Ship fixtures for every failure mode. At minimum: valid, tampered, revoked, expired, and unknown key. California's revoked sample is the kind of detail that tells you someone thought about year two.
4. Version your canonicalisation. Label it v1 and assume there will be a v2. Migration is far cheaper when the version is a field and not a memory.
5. Put the key somewhere boring and permanent. A well-known HTTPS URL on your own domain beats an invented distribution scheme. Publish rotation plans and overlap windows before you need them.
6. Extend without breaking old parsers. The AAMVA reserved-subfile pattern is a good model: mandatory core that everyone reads, clearly namespaced extension that everyone else skips.
7. State what is deliberately not covered. Partial coverage is fine. Silent partial coverage is how disputes start.
8. Test with a stranger. Hand the spec, the key, and one sample artifact to someone outside your team. If they cannot verify it in an afternoon, you have documentation work left.

The trade-off you actually have to make

Someone will argue that publishing your verification scheme helps forgers. Look at the evidence. The states with proprietary, unverifiable signatures were not more secure as a result. They were just harder to audit, and their format was reconstructed anyway by anyone willing to spend a weekend on it. A public standard does not weaken the signature. It weakens your ability to be the only gatekeeper.

That is the real trade-off, stated honestly. If there is a genuine reason to keep a format closed — regulatory, contractual, competitive — that is a legitimate choice. But then call it a proprietary check, not a trust signal, and do not be surprised when the only people who can verify your documents are the people you already control. Everything else is a signature-shaped decoration.

California got this mostly right. It just arrived six months late, and in that window a cryptographic advance was indistinguishable from a hologram. Your release schedule decides which one your users experience.

Key Takeaways

• A signature is only a security feature if the party who needs to trust the document can verify it without asking you.
• Canonicalisation — the exact bytes that get signed — is the spec. Field order, formatting, sorting, and padding placeholders all have to be written down and versioned.
• ECDSA signatures can reveal their public key when the message is known, so an undocumented format is not a protection. It just delays interoperability.
• Ship a reference verifier and test fixtures for valid, tampered, revoked, and expired cases in the same release as the signer.
• Key discovery and revocation matter more in year two than the crypto choice matters in year one.
• Reserved, namespaced extension points let you add signed data without breaking existing parsers. Steal that pattern.