up:: Migration Architecture MOC

The Ignore-or-Reject Question

The ignore-or-reject question is the question put to architects before post-quantum cryptography is enabled on any path that matters: for every system that validates a certificate in this flow, what does it do with a certificate field it doesn’t understand, ignore it or reject it? The binary is the transition risk in miniature. During the migration, certificates carry both a classical and a post-quantum signature so old and new verifiers can coexist, and an older verifier handed one of these certificates does one of two things. It ignores the part it can’t read and validates on the classical signature alone, quietly giving that path none of the post-quantum protection you deployed, or it rejects the whole certificate as malformed and breaks a connection that worked yesterday.

Which behavior you get depends entirely on how each verifier was written, so the question is asked per verifier, per path, and the full list of answers is the output. That list is the map of where a rollout is safe, where it silently under-secures, and where it breaks on contact.

The short version:

• The question, asked of the architects before anything is enabled on a live path: for every system that validates a certificate in this flow, what does it do with a certificate field it doesn’t understand, ignore it or reject it?
• The two old-verifier behaviors are written into the standards. RFC 5280 lets a verifier ignore a non-critical extension it doesn’t recognize, which is exactly where dual-signature certificates carry the post-quantum material, while a composite certificate presents an unrecognized algorithm identifier that leaves an old verifier nothing it can validate.
• Ignore means the connection works and the path’s trust still rests entirely on the classical signature a quantum computer forges. Reject means a loud outage. The quiet one is the one that misreports itself as migrated.
• You won’t get one answer across an estate, and that’s the point. The list of answers, verifier by verifier, is the rollout map.
• Every answer gets paired with the size limit on the same hop, because a verifier that would validate both signatures is still unreachable if a box in front of it drops the larger certificate chain.

Picture a border where passports just gained a new biometric page. One officer has never seen the page, flips past it, and stamps you through on the old photo page alone, so the stronger check you paid for never happened and nobody logged that it didn’t. The next officer, trained to treat anything unfamiliar as tampering, confiscates the same passport on sight. Same document, two honest officers, opposite outcomes, and the traveler finds out which kind they got only at the booth. A rollout that doesn’t ask each officer in advance is choosing to find out the same way.

What is the ignore-or-reject question?

The ignore-or-reject question is a pre-rollout diagnostic for the certificate layer of a post-quantum migration. It has three components:

1. The question itself, put to the people who own the architecture, one sentence long, asked before post-quantum certificates are enabled on any path that matters: for every system that validates a certificate in this flow, what does it do with a certificate field it doesn’t understand?
2. The unit of analysis, which is the verifier-on-a-path, never the product name. A “verifier” is any software that checks a certificate in the flow: the TLS library in a client, the validation logic in a load balancer, an inspection appliance that re-validates chains, an embedded validator in a payment terminal, a partner’s connector you’ve never seen the source of. The same library can appear on 3 paths and count 3 times, because the paths go live separately.
3. The output, a per-path map with one row per verifier: ignore (the path silently under-secures), reject (the path breaks on contact), or validates both (the path is safe to enable), with the hop’s size limit recorded beside each answer.

The question applies wherever transition certificates, dual-signature or composite, will be introduced on a path with verifiers you didn’t write yourself, which during the migration window is nearly every path that matters. It sits at the certificate layer specifically. The neighboring failure at the key-exchange layer, where a connection quietly falls back to classical key exchange, is a different mechanism with a different instrument, covered in Downgrade and Rollback Attacks and verified by Wire Over Config.

Why do old verifiers give two different answers?

Because the two behaviors are both legitimate readings of the rulebook, applied to different parts of the certificate. The split comes straight out of how X.509 handles the unknown.

Every extension in an X.509 certificate carries a criticality flag, and RFC 5280, the profile nearly every verifier implements, gives one rule for each setting. For critical extensions: “A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process.” For the other kind: “A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.”

Source: D. Cooper, S. Santesson, S. Farrell et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” IETF, RFC 5280, §4.2, May 2008.

The dual-signature formats were built to ride that MAY. ITU-T X.509 (2019) defines the alternative public key and alternative signature fields as non-critical extensions, so a legacy verifier flips past them and validates the primary classical signature exactly as it always has, and RFC 9763 likewise specifies that its certificate-linking extension “SHOULD NOT be marked critical.” The ignore path is the designed behavior, chosen so the ecosystem could start carrying post-quantum signatures before anyone was ready to check them. In the separate-certificates dual form the ignore is purer still, because the old verifier receives only the classical certificate and never sees the post-quantum one at all.

Source: ITU-T Recommendation X.509 (10/2019), clause 7.2.2 (alternative-signature extensions); A. Becker, R. Guthrie, M. Jenkins, “Related Certificates for Use in Multiple Authentications within a Protocol,” IETF, RFC 9763, June 2025.

The reject answer arrives by three separate routes, which is why it shows up even where every extension was marked non-critical:

1. Composite certificates put the unknown outside the extension machinery. A composite certificate presents one combined algorithm identifier in the signature-algorithm and public-key fields, treated “as a single atomic algorithm at the protocol level.” Those fields carry no criticality flag and no MAY. A verifier that doesn’t recognize the composite identifier has no signature it can check, so validation fails and the certificate is rejected, which is the outcome of having nothing to validate.
2. MAY is permission rather than a promise. Strict validators, hand-rolled ASN.1 parsers, and security appliances that treat unfamiliar structure as evidence of tampering reject certificates the specification would have let them accept. Decades of independently written verifiers means decades of independently chosen strictness.
3. The size can fail before the logic runs. A dual-signature certificate adds an ML-DSA public key and signature, 1,952 and 3,309 bytes at ML-DSA-65 against roughly 64 bytes for the ECDSA signature it accompanies, so a parser with a fixed certificate buffer can choke on the object’s size and report it malformed before any extension handling happens.

Source: M. Ounsworth, J. Gray, S. Fluhrer et al., “Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure,” IETF LAMPS WG, draft-ietf-lamps-pq-composite-sigs (v19, in RFC Editor queue); NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, Table 2, August 2024; NIST, “Digital Signature Standard (DSS),” FIPS 186-5, February 2023.

Put the routes together and the estate-level picture writes itself: any real population of verifiers, written by different teams across decades to different readings of the same rulebook, contains ignorers, rejecters, and upgraded validators at once. The question exists because no amount of reasoning about the specification tells you which one is sitting on a given path.

What does each answer mean for a rollout?

Each answer sorts its path into a rollout category, and the table is the extractable core of the framework.

The verifier’s answer	Why it happens	The risk it creates	What you do with the path
Ignores the unknown field, validates the classical signature alone	Designed legacy behavior for dual-signature certificates under RFC 5280’s non-critical MAY	Silent under-securing. The connection works, the dashboard reads migrated, and trust on that path still rests entirely on the signature Shor’s algorithm forges	Enable for compatibility, count the path as unmigrated in every status report, and re-ask the question when the verifier is upgraded
Rejects the certificate as malformed	An unrecognized composite algorithm identifier, an unknown critical extension, a strict parser, or a buffer blown by the larger object	Loud breakage. A connection that worked yesterday fails on contact, visibly	Hold the rollout on that path until the verifier is upgraded. Loud failures get found in staging and fixed
Recognizes and validates both signatures	An upgraded, transition-aware verifier with enforcement active in its default path	Residual risk moves to the transport, where the larger chain meets the hop’s size limits	Enable, pair the answer with the hop’s measured size limit, and verify on real traffic. Confirm enforcement is on by default rather than available behind a flag, per the section below

The asymmetry between the top rows deserves stating plainly. A reject is an outage with a stack trace, and outages get tickets, root causes, and fixes. An ignore completes the handshake, shows the padlock, and reports success to every layer above it, while the post-quantum signature you paid to deploy goes unexamined.

And the ignore leaves nothing on the wire to catch, which makes it stranger than the key-exchange fallback it resembles. A fallen-back key exchange is visible in the negotiated group, which is why Wire Over Config works as the detection instrument there. A certificate that carries both signatures looks identical on the wire whether the verifier checked one signature or both, because which signature got checked is a decision inside the verifier’s process, invisible from outside. The wire shows what was presented. Only the verifier knows what was validated, which is exactly why the instrument here is a question rather than a packet capture.

What if a verifier recognizes the field and still doesn’t act on it?

Then it belongs in a fourth category, and a 2026 measurement study says that category is common enough to plan for. The three answers above assume that recognizing the post-quantum material and acting on it are the same event. They aren’t, and the gap between them has a measured size.

Kim et al. drove eight path-validation stacks, built on 7 independent codebases, against 6 certificate schemes. Across the 24 combinations involving separable transition certificates, 19 accepted on the classical path alone, 4 recognized the post-quantum material and still let the verdict stand without it, and 1 rejected an unsupported structure. None of them required the post-quantum signature by default. More pointedly, 4 of those stacks verify ML-DSA signatures elsewhere along a certification path, so they demonstrably have the algorithm. What they lack is a rule that makes the result matter.

That splits the top row of the table into two rows that need different fixes:

The verifier’s answer	What’s actually happening	Why the fix differs
Ignores the unknown field	The verifier doesn’t recognize the extension, so RFC 5280’s non-critical MAY permits it to skip it and accept	Fixed by upgrading the verifier to a version that understands the format
Recognizes the field and accepts anyway	The verifier parses the post-quantum material and validates the classical path regardless, so a failure in the post-quantum half changes nothing	Upgrading doesn’t fix it. The verifier needs a policy that requires both, and many expose that only behind a build flag or a separate call the default path never makes

The second row is the one that surprises people, because every proxy a team normally uses to check readiness returns a clean answer for it. The library version is current. The algorithm is supported. The certificate is genuinely a transition certificate. And the decision is still classical.

There’s a fifth answer as well, at the other end. A verifier that does enforce correctly can reject a certificate that a different, equally conforming implementation accepts. Kim et al. observed exactly this between two stacks that disagreed on how to reconstruct the bytes the alternative signature covers, with each internally consistent and neither demonstrably wrong. The authors report the divergence and decline to adjudicate it, because the encoding hasn’t been interoperably profiled yet. For a rollout that means “validates both signatures” earns its green only after it’s tested against the specific issuers on that path, and enabling enforcement without a rollback plan can turn a silent problem into an outage.

So the practical amendment to the map is one extra column and one extra test. Beside each verifier’s answer, record whether enforcement is on in the default configuration rather than available somewhere in the product. Then test it directly: invalidate the post-quantum signature on a certificate in a controlled environment and see whether that verifier’s verdict changes. A verdict that doesn’t change is the fourth answer, whatever the release notes say.

Source: T. Kim, B. Chung, K. Kim, Y. Kang, “Classical Acceptance Is Not Hybrid Authentication: Validation Policy and Lifecycle Management of Hybrid X.509 Certificates in Deployed Open-Source Stacks,” arXiv:2607.20800, Table IV and §VI-A, v3, 12 August 2026 (preprint; reproducibility package archived at Zenodo 10.5281/zenodo.21452130).

Why is getting many different answers the point?

Because the heterogeneity is the finding. An estate’s verifier population spans operating-system trust stacks, TLS libraries pinned inside appliances years ago, embedded validators sealed at manufacture, SDK fleets spread across customer devices, and partner-run systems whose source nobody on your side has read. Those were written independently, against different X.509 profiles, with different strictness, on different upgrade cadences. Asking one question of that population and getting back one answer would mean the question was asked at the wrong altitude, of an inventory spreadsheet instead of the architects, and somebody averaged.

The list of answers is the artifact. One row per verifier per path, and the rows partition the estate into the three categories a rollout plan actually needs: paths you can enable now, paths that will pretend to migrate while staying classical, and paths that will page someone at 2 AM. A single averaged answer supports a go/no-go decision, which is the wrong decision shape for a transition whose whole character is that different paths are ready at different times. The map supports the right shape, which is enabling path by path, in the order the answers permit.

How does certificate size pair with the question?

Every answer gets a second number written beside it, the size limit on the same hop, because the two failures travel together and imitate each other. A dual-signature or composite certificate is kilobytes larger than its classical ancestor, chains stack several certificates, and the TLS handshake carries the whole chain, so the object arriving at each verifier is several times the size every buffer on the route was measured for. The full size arithmetic lives in PQC Performance and Size Overhead, and the method for finding a path’s actual threshold is its own framework, The Ceiling Question.

The pairing rule exists because a clean verifier answer can still describe an unreachable path. A verifier that validates both signatures perfectly does nothing for you if a middlebox two hops upstream drops the fatter chain, and that failure presents exactly like the reject row while having a completely different fix, a transport limit rather than a validation upgrade. A map row is finished when it carries both facts: what this verifier does with the unknown field, and what this hop does with the larger object. The rollout decision for the path reads both columns at once.

What does the question look like on a real path?

Run it end to end on a generic case: a payment-authorization flow moving a transaction from checkout to the acquiring bank, with the payment provider preparing to issue dual-signature certificates across it. The team walks the path and finds 4 systems that validate a certificate, then asks the question of each. The example’s dual chain runs about 15 KB, from a 4 KB classical chain plus an ML-DSA public key and signature (1,952 and 3,309 bytes) on each of the 2 certificates the server sends.

#	Verifier on the path	Answer to the question	Map entry	Paired size finding
1	Edge load balancer’s validation of upstream certificates, current cloud image	Recognizes the alternative-signature extensions and validates both	Safe to enable	64 KB buffer, the 15 KB chain fits
2	Fraud-screening appliance that re-validates chains, vendor firmware from 2019	Ignores the non-critical extensions, validates classical only	Silently under-secures	16 KB buffer, the chain fits, which is precisely why nothing will look wrong
3	Acquiring bank’s connector, hand-rolled ASN.1 parsing	Rejects certificates carrying unfamiliar content as malformed	Breaks on contact	8 KB certificate buffer, the chain overruns it, so this hop fails twice over
4	Checkout SDK fleet on customer devices, validation delegated to each device’s OS trust stack	”It depends on the OS version,” which is an honest unknown	Unknown, treated as breakage risk until measured	Unmeasured

The resulting map is four sentences long and it changes the rollout from a switch into a sequence. Enable on the hop behind verifier 1 now. Enable through verifier 2 for compatibility while reporting that path as unmigrated, and put the appliance’s firmware upgrade on the plan, because until then the path’s trust rests on the classical signature alone. Hold verifier 3’s path entirely, with two named fixes, the parser and the buffer. Measure verifier 4’s fleet before deciding anything, since an unknown that turns out to reject would break checkout itself, the one path on the list that pages executives. Every one of those moves was invisible to the version of the plan that asked “did the certificate pass in the lab,” and the lab answer was yes the whole time.

Common misconceptions

1. “Our vendor said their stack ignores unknown extensions, so we have our answer.” You have one verifier’s answer. The estate’s answer is a list, one entry per verifier per path, and the paths through appliances, partners, and device fleets are exactly the ones a vendor’s statement never covers. One answer per estate is the assumption the question exists to break.
2. “The certificate validated in the lab, so the paths are covered.” The lab contains your test verifier and none of the others. Every behavior in the map, the 2019 appliance that ignores, the bank connector that rejects, the SDK fleet nobody measured, lives on the production path and only there. A passed lab test is one row of the map wearing the authority of the whole thing.
3. “Reject is the outcome to fear, ignore is the safe one.” Reject is loud, diagnosable, and fixed once. Ignore completes the connection, reports success, and quietly leaves the path’s trust on the quantum-forgeable signature while every dashboard above it reads green. Of the two, the one that lies to you is the expensive one.
4. “RFC 5280 defines the behavior, so we can derive the answers from the spec.” The spec’s MAY is permission, and permission produces divergence by design. Two fully conformant verifiers can give opposite answers to the same certificate, and composite identifiers sit outside the extension rules entirely, so the only way to know a verifier’s answer is to get it from the verifier.
5. “We patch aggressively, so our verifiers are all modern.” Patching currency and validation behavior are different properties. A fully patched appliance still runs the validation logic its vendor shipped, embedded validators keep the behavior they were sealed with, and partner-run verifiers follow the partner’s roadmap rather than yours. The verifier population is always older than the server fleet.
6. “The ignore behavior is spec-compliant, so the rollout worked.” Compliant and protected are separate claims. The ignoring verifier is doing exactly what ITU-T X.509 and RFC 5280 designed it to do, and the path it guards still gains nothing from the post-quantum signature until the verifier checks it. The design goal of the ignore path was compatibility, and compatibility is what it delivers, all it delivers.

Pro tips

1. Ask per path, never per inventory. An inventory answer (“we run library X at version Y”) collapses the map back into an average. The question is asked of a flow: name the path, walk it hop by hop, list every system that validates a certificate on it, and get one answer per system. The same library counts once per path it sits on, because the paths go live separately.
2. Probe the verifiers you control with 3 test certificates. A dual certificate with both signatures valid, one with a valid classical signature and a deliberately corrupted post-quantum one, and one with the corruption reversed. A verifier that accepts the corrupted-post-quantum certificate just told you it ignores. One that rejects it is checking both. About 15 minutes per verifier converts a hallway answer into a measured one.
3. Treat “we’d have to check” as its own map color. An unknown is a real answer and it maps to breakage risk until measured, because the downside of an unmeasured rejecter is an outage on a live path. The evasive answer goes onto the map as its own row, and the row’s remediation is a measurement.
4. Date-stamp every answer and log verifier upgrades, because the answer rots. A map drawn in March describes March. Every verifier upgrade, firmware push, and partner migration after that date can flip a row from ignore to validates-both, or from reject to safe, and a rotted map either blocks a path that’s ready or trusts a path that changed. The upgrade log is what keeps the map a living document instead of an artifact of the quarter it was drawn in.
5. Write the size number into the same row, in the same sitting. The hop’s limit and the verifier’s behavior get gathered by different teams, and unpaired they drift into separate documents that nobody joins at decision time. The rollout decision needs both columns of the row simultaneously, which is easiest when they were never apart.

Where does the question break down?

On a single-verifier path you fully control, the machinery is bigger than the job. If the flow is your service calling your other service, through your load balancer, with one TLS library you pinned yourself, the answer set has exactly one entry, you can go read the code or run the 3-certificate probe before lunch, and the map is a sentence. Asking the architects a formal pre-rollout question about a verifier you wrote is ceremony.

Write the sentence down anyway, dated. Paths accrete verifiers silently, a new inspection appliance, a new partner integration, an SDK that delegates validation to someone else’s trust stack, and the dated one-line map is what makes the accretion visible the next time anyone looks. The framework also goes quiet where there’s no certificate validation to interrogate at all, on pre-shared-key and symmetric-only links, whose transition runs through different mechanics entirely.

How do you use the question in a boardroom?

Deploy it whenever certificate readiness is reported as a lab result, which in most organizations is every time it’s reported. The deck slide says the post-quantum certificates were tested and validated, and the wield-upward form of the framework is one sentence: “How many of the verifiers on this path have answered the ignore-or-reject question?”

The answers sort the room. A team that responds with a per-path list, so many validate both, so many ignore and are counted as unmigrated, so many reject and are holding the rollout, one fleet still being measured, is running the transition on a map, and the number they can’t produce yet is itself reported honestly. A team that responds by re-describing the lab test has one row and a switch, and the board should understand that flipping that switch means discovering the rest of the map in production, where the ignores surface as a false migration report and the rejects surface as outages. The question costs nothing to ask and converts “tested” from a reassurance into a coverage number, which is the unit a board can actually govern with.

Questions people ask

Is a verifier that ignores the post-quantum signature broken? No, it’s doing what the standards designed. RFC 5280 permits ignoring unrecognized non-critical extensions, and the dual-signature formats put the post-quantum material there deliberately so legacy software would keep working. The rollout problem is knowing which paths took that route, because those paths gain no post-quantum protection until their verifiers upgrade.

Which answer is worse, ignore or reject? Reject costs you an outage once, gets diagnosed, and gets fixed. Ignore costs you nothing visible and leaves the path’s trust on the classical signature indefinitely while reporting the migration complete. Loud and honest beats quiet and misleading, so budget your worry toward the ignores.

Does the question apply to both composite and dual-signature certificates? Yes, with different physics. Dual-signature certificates mostly meet the ignore behavior, because their post-quantum material rides in non-critical extensions built for exactly that. Composite certificates mostly meet reject, because an old verifier faces an algorithm identifier it can’t process and has nothing left to validate. A mixed rollout inherits both patterns at once, which makes the per-verifier map more necessary rather than less.

How do I actually get a verifier’s answer? In order of strength: read the validation code if you own it, run the 3-certificate probe against a test instance if you can reach one, get a written statement from the vendor or partner naming the product version, and failing all three, record “unknown” and treat the path as breakage risk. An answer without a version number attached is a rumor.

How often does the map need redrawing? On events rather than a calendar. Any verifier upgrade, firmware push, partner migration, or new system added to a path can flip a row, so the practical discipline is date-stamping answers and keeping an upgrade log that flags which rows to re-ask. A map more than a couple of quarters old should be treated as a hypothesis.

Doesn’t TLS downgrade protection catch this? Different layer. The TLS 1.3 protections in Downgrade and Rollback Attacks authenticate the handshake negotiation, and Wire Over Config reads what the negotiation chose. Which signature a verifier checked inside a certificate is a local decision in that verifier’s process, invisible to the transcript and the wire alike, which is why the certificate layer needs a question where the key-exchange layer has a packet capture.

Do I need this before we’ve deployed any post-quantum certificates? That’s the cheapest time to ask it. The map determines the rollout order, so drawing it first means the first certificate you issue lands on a path you already know is safe, and the verifier upgrades for the ignore and reject paths get scheduled before they’re blocking anything.

What goes in the size half of each row? The measured limit of the hop in front of that verifier, buffer sizes, record limits, whatever bounds the largest certificate chain the hop will carry, checked against your actual chain’s size. The Ceiling Question covers finding that threshold, and PQC Performance and Size Overhead carries the arithmetic of why transition chains are several times their classical size.

---

Everything here is the map, given freely. When the question needs asking across your own estate, path by path, with every verifier’s answer and every hop’s limit quantified into a rollout map that survives contact with production, that’s the work I do. Request the workshop.

Last verified 2026-07-28 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.