Proposal: PQC Protocol Readiness Matrix

[syedDS]

Create and maintain an OWASP PQC Protocol Readiness Matrix that evaluates the post-quantum readiness of application and security protocols such as TLS, SSH, IPsec/IKEv2, QUIC, DTLS, MQTT, PKI/X.509, DNSSEC, and signing protocols.

The matrix would track whether each protocol has a defined migration path to PQC, including standardization, hybrid support, implementation availability, interoperability, and operational considerations.

PR #41 focuses on cryptographic inventory management and PQ-readiness software. Its primary question is:

What cryptographic assets and algorithms does an organization have, and how can they manage their migration?

This proposal focuses on the protocol layer:

How ready are the protocols that applications depend on for PQC adoption?

Expected Outcome

The project would maintain a living, evidence-backed reference matrix showing the current PQC readiness of protocols and their surrounding ecosystem.

The matrix would be based on standards, implementation evidence, interoperability testing, and publicly verifiable sources rather than subjective vendor rankings.

[rot169]

Whilst the top-10 list is the primary goal right now, I think it'd be great for the project to also curate a source of up-to-date information on protocol readiness. (I'd actually take it a step further and extend that to application readiness too). The secret to success will be accuracy and keeping it up-to-date.

@syedDS did you have a plan in mind as to what this matrix would look like? At it's simplest it could just be a single markdown page in our repo that anyone can submit updates too. Or at the more complex end of the spectrum, maintain a structured format (e.g., JSON/YAML) to capture the data and provide means to then translate that into a pretty human-readable form.

Thoughts?

Also, do we have many other members of the community who'd be up for contributing towards this?

[ossumpossum]

@syedDS this is your proposal, so take the below as input rather than a counter-proposal, and I am happy to defer to whatever shape you had in mind.

@rot169 answering your second question first: yes, I would contribute. Concretely, the TLS row, since that is where the QS06 negotiation-and-downgrade wording I contributed on review (#17) already sits.

On format, a flat markdown table can carry this: the PQUIP WG's state-of-protocols-and-pqc does exactly that across eleven protocols today. What it cannot do is make the provenance checkable. Its evidence lives in a free-text Comments column, so nothing validates it, nothing queries it, and nothing shows you what has gone stale. That list still cites draft-kwiatkowski-tls-ecdhe-mlkem, which is two renames and an RFC behind, and that is the failure mode rather than a criticism of the format.

So I would lean structured, but the part that actually matters is a JSON Schema plus a CI validation gate; either serialisation works behind that. If we go YAML, the schema needs to force quoting on enum cells, because hybrid_support: no parses as boolean false under YAML 1.1.

You are right that currency is where this lives or dies. A rendered, sortable last_verified is the cheapest way to make staleness visible, and it is worth saying that PR #41 already carries "evidence source and last-verified date" per asset. That thread settled on not making full provenance load-bearing in an MVP. Different layer, same trade-off, and the two schemas are worth keeping compatible rather than letting them diverge.

One thing worth considering in the schema, if the structured route wins: readiness is not one axis, and a single score can hide the failure modes that matter in deployment. Suggested axes, roughly, and happy to be told three of these collapse into one:

• standardisation status, naming the document and its maturity
• implementation availability, naming implementations and versions
• interoperability evidence, what has actually been tested against what
• failure-mode assessment: what happens on negotiation failure, retry, or downgrade

A live example for why the fourth earns its place, and for the staleness point at the same time. QS06 reference 2 still describes draft-ietf-tls-ecdhe-mlkem as "IESG-approved and awaiting RFC publication", verified 2026-07-27. It was published as RFC 10024 in August. I will put that one-line refresh up separately; it is exactly the drift a rendered last_verified is meant to surface.

On the fourth axis itself: draft-ietf-uta-pqc-app covers this ground for TLS in prose, including explicit fallback policy and preference ordering, but as narrative rather than as a field you can sort on. I would expect the column to read "not assessed" for most protocols at first, which is itself useful signal. For TLS the content is already written up in QS06 and I would just be pointing the row at it.

On extending to application readiness: agree in principle, though I would keep v1 to protocols. The evidence base for applications is thinner and would dilute the provenance requirement.

Timing-wise I assume this is post-v1 or a parallel track rather than anything competing with the 26 October publication, and I will work to whatever sequencing the leads want.

To be concrete about what I can commit to rather than leaving it vague: a strawman schema plus the TLS row within two weeks of there being agreement on direction, and I can keep the TLS row current through v1. Beyond that I would want someone else on a rota, since I have conference commitments through December and a matrix only works if the rows do not go stale. @syedDS if you would rather drive the schema yourself, I am glad to fill rows against it instead.

[syedDS]

did you have a plan in mind as to what this matrix would look like? At it's simplest it could just be a single markdown page in our repo that anyone can submit updates too. Or at the more complex end of the spectrum, maintain a structured format (e.g., JSON/YAML) to capture the data and provide means to then translate that into a pretty human-readable form.

@rot169 I can put a PR with matrix in the repo, the goal is open the format for contributor and make it a live document as we go. Do you have specific folder where this MD file should go under top 10 folder or anywhere else. Once that clear can go ahead with PR

[syedDS]

@ossumpossum yes that direction we can proceed . I agree that last_verified should be first class field to avoid staleness . For V1 which will be post Oct deadline , we can work together to keep your suggested dimensions. The strawman schema and TLS row you offered would be a great starting point. I can incorporate that and coordinate the review/iteration , once i am back from my travel end of this month.