Summary

  • The IAB has extended the position-paper deadline for its post-quantum authentication workshop to 11 September 2026. The workshop is seeking deployment measurements and operator experience, not votes for an algorithm.
  • Its record will contain different evidence states: normally public papers, permitted withheld material, unattributed discussion, public collaborative notes with exclusions, and a later IAB report. None can silently stand in for another.
  • Leadership should preserve a chain from tested component and raw measurement through the exact submitted paper, disclosure status, workshop synthesis, later technical action and independently observed production outcome.

On 4 September, the Internet Architecture Board gave prospective contributors another week. The IETF blog now says papers for the Workshop on Accelerating the Deployment of Post-Quantum Authentication are due on 11 September. The mail announcement calls the deadline extended. The original IAB call and Datatracker page preserve the earlier 4 September date.

That small discrepancy is not a defect. It is a useful example of provenance. One record shows the first plan; a later record changes the operative date. An analyst can reconstruct the sequence only by retaining both and identifying which one governs now.

The same discipline will be needed for the evidence the workshop receives. A benchmark table may be accurate for one HSM, firmware version, certificate chain and workload. A position paper may describe it faithfully. A workshop discussion may generalize it. An IAB report may summarize the discussion. A working group may later change a protocol. An operator may then deploy the change. Those are related events, not one event.

The workshop is asking for the missing middle

The IAB's premise is deliberately operational. NIST has standardized ML-DSA and SLH-DSA. The IETF has protocol work around signatures and certificates. Yet a mathematical construction and a wire format do not show what happens when a chain meets a handshake limit, a key meets an HSM interface, a verifier meets old firmware, or a trust store meets a multi-year release cycle.

The call therefore asks for short papers about attempts, measurements, constraints and costs. It names certificate chains, PKI, DNS, tokens, software and firmware signing, constrained devices, key custody, offline verification and long-lived systems. It wants figures such as sizes, timings, throughput, memory and validation schedules. A compact table with a clear test context can be more valuable than a sweeping claim.

This is the missing middle between standard and outcome. FIPS 204 establishes ML-DSA. It does not establish that a particular cryptographic module exposes the required operation, that a certificate path fits a transport budget, or that a fleet can rotate its trust anchors. FIPS 205 establishes SLH-DSA. It does not show the signing capacity, failure recovery or verifier memory of a named installation.

The workshop page is equally careful about proposed alternatives. Composite signatures combine component mechanisms and move cost into larger objects and combined validation. Merkle Tree Certificates move work toward logs, proofs and freshness. KEM-based authentication changes an interactive authentication path. They are works in progress. Their inclusion in the agenda is evidence that they are relevant for deployment discussion, not that the IAB has selected them.

Intake has more than one disclosure state

The workshop is invitation-only and planned for Prague on 11–12 October. Anyone may send a short statement of interest; a position paper has more influence on the agenda, and the Program Committee can also invite participants. Submission, acceptance, invitation, attendance and presentation are therefore separate fields.

The publication rules add another dimension. Relevant accepted papers will normally be posted on the Datatracker. Authors can ask that a paper not be published or that specific material be handled without attribution. A discussion can invoke the Chatham House Rule. There will be no public recordings or minutes. Collaborative notes are planned as a public reference, excluding protected sections.

These choices allow operators to disclose constraints they could not safely put into an unrestricted archive. They also limit what later readers can independently test. The correct response is not to reject confidential evidence or pretend it became public. It is to label the evidence state.

A public paper can be cited and hashed, but publication does not reproduce its experiment. A withheld paper can inform the room, but a reader cannot inspect its method. An unattributed statement may describe a genuine fleet constraint, but it cannot support a claim about a named organization. Collaborative notes may record a conclusion while intentionally omitting the path through protected discussion. Each state has value and a ceiling.

A workshop report is a map, not a standards act

The intended output is an IAB-stream report. RFC 4845 explains an important boundary for such reports. When outside participants contribute to a workshop, IAB approval may assert that the report faithfully represents the proceedings and that the issue matters; it need not make the IAB responsible for the technical correctness of every underlying statement. IAB-stream publications are generally Informational, not Internet Standards.

That does not make the report weak. A faithful synthesis can reveal recurring constraints, contradictory measurements and unanswered questions. RFC 8980, a previous IAB workshop report on design expectations and deployment reality, shows how position papers, discussion, conclusions and possible actions can be separated in a permanent record.

The danger comes later, when the record is compressed. “The IAB found” may replace “three public papers reported, two protected interventions qualified, and the workshop report summarized.” “Industry consensus” may replace a room shaped by invitations and disclosure constraints. “Deployment blocker” may survive after the tested firmware or protocol revision has changed.

Heng Lu's reality-layer discipline resists that compression. The workshop is a coordination layer. A paper is an evidence claim. A report is an institutional record. A specification is a design rule. Running code is an execution layer. The customer-visible result is another layer again.

Build the chain before the room meets

Every quantitative submission should carry a compact provenance envelope. It should name the tested component, version, cryptographic provider, algorithm and parameter set. It should define the credential or object shape, workload, hardware, topology, baseline, sample size, units and failure categories. It should preserve raw results or state why they cannot be shared.

The submitted PDF then needs its own date and hash. Disclosure status should be explicit: public, withheld, partly withheld or attribution-restricted. If the workshop changes a conclusion, the notes or report should distinguish the paper's claim from the room's synthesis.

The later report should link a conclusion to inspectable inputs where possible and say when protected evidence contributed. A subsequent working-group document should cite the report without treating it as protocol consensus. A vendor release note should identify the implemented change. An operator test should show which version ran and what happened. Only then can the organization speak about deployment.

This is Running-Code Primacy without anti-institutional theatre. The IAB can usefully gather evidence and publish a minimum common map. Under Heng Lu's Minimum Initial Specification, that shared map should preserve the smallest facts needed for local verification while leaving deployment decisions with accountable operators.

The extra week matters because missing evidence cannot be invented after the workshop. It should be used to improve the diversity and specificity of inputs. It should not be counted as proof that a particular approach is late, ready or preferred. The deadline moved. The burden of proof did not.

Sources

  1. IETF blog — Post-Quantum Authentication: Up Next
  2. IETF announcement — deadline extended
  3. IAB call for papers
  4. Datatracker workshop page
  5. RFC 4845 — Process for Publication of IAB RFCs
  6. RFC 8980 — Design Expectations vs. Deployment Reality
  7. NIST FIPS 204 — ML-DSA
  8. NIST FIPS 205 — SLH-DSA
  9. Composite ML-DSA signatures draft
  10. Merkle Tree Certificates draft
  11. KEM-based authentication draft
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — On Reality Layers