Dear IP-NNI,
As I have not been attending the ALIII meetings, therefore I am not sure whether the need to support post-quantum cryptography has already been discussed by the group.
I have reviewed draft specification IPNNI-2026-00113R000.docx , Agreement-Less IP Interconnection over the Internet: Trust Architecture and Certificate Management, and based on that review, I wanted to provide the following thoughts for your consideration. The draft currently requires the ALIII Authorization Token to use ES256, which combines ECDSA using the P-256 elliptic curve with SHA-256. My primary concern is the use of ECDSA, which is vulnerable to a future cryptographically relevant quantum computer. SHA-256 does not present the same immediate concern, although the current spki_sha256 claim could be made algorithm-neutral to provide greater flexibility in the future.
Recent White House direction on migration to post-quantum cryptography reinforces the need for critical infrastructure and telecommunications systems to begin moving away from quantum-vulnerable public-key cryptography. Against that background, I believe it would be important for the ALIII specification to address PQC and cryptographic agility before the architecture and related certificate profiles are finalized.
The principal areas that may need further consideration are:
- The AAT currently mandates a single quantum-vulnerable signature algorithm.
- JWS Compact Serialization supports only one signature, which may limit the ability to use both classical and PQC signatures during a transition period.
- The broader requirements for mTLS key establishment, endpoint certificates, CA certificates, certificate-status services and trust-anchor management do not yet appear to define how PQC will be supported.
- The draft does not currently establish an explicit cryptographic-agility framework, algorithm transition process or downgrade protections.
I would recommend that the core architecture avoid permanently fixing a specific public-key algorithm. Instead, permitted algorithms could be defined through versioned ALIII cryptographic profiles. These profiles could establish the mandatory-to-implement algorithms and transition requirements for AAT signing, mTLS key establishment, TLS authentication, certificate issuance, certificate validation, revocation and protection of the Trusted ALIII-CA List.
The specification should also consider:
- Supporting NIST-approved post-quantum signatures, such as ML-DSA, for the AAT.
- Defining whether any transition period would use PQC-only signatures, parallel classical and PQC tokens, or a dual-signature mechanism.
- Supporting PQC or hybrid key establishment for mTLS sessions.
- Defining clear algorithm transition, deprecation and downgrade-protection requirements.
- Making the SPKI-binding structure algorithm-neutral, even if SHA-256 remains the initial required digest.
More fundamentally, as ALIII has not yet been implemented and the related certificate, PKI and operational requirements are still being developed, it is not clear why PQC should be treated solely as a future migration issue. This appears to be an opportunity to design PQC support into the framework from the outset, rather than deploy a new ECC-dependent trust infrastructure and subsequently require service providers, certification authorities and governance entities to retrofit it.
There may be valid interoperability or implementation reasons to support ES256 initially. However, I suggest that any reliance on classical cryptography should be treated as a defined and time-bound transition mechanism, rather than the long-term architectural basis for ALIII. At a minimum, the first release should establish the cryptographic-agility requirements and a clear path to mandatory PQC support.
I would appreciate the group's consideration of these points as the specification and the associated ALIII mTLS Certificate Profile continue to be developed.
Best regards, Ian
| ![Description: Description: <a href=]() image001.png@01D1F181.B01EF8B0" width="63" height="63" style="width: 0.6666in; height: 0.6666in; margin: 0" data-outlook-trace="F:2|T:2" src="https://higherlogicdownload.s3.amazonaws.com/ATIS/MessageImages/92cd62cf9bf847b3b629aa53fc0f5b37.png"> | Ian Deakin Principal Technologist
Office +1202 434 8823
Cell +353 86 8199 563 |