Quantum Safe (PQ) Considerations for Autonomic Network Infrastructure (ANI)
draft-richardson-anima-quantum-safe-4ani-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Michael Richardson | ||
| Last updated | 2026-08-12 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-richardson-anima-quantum-safe-4ani-00
Autonomic Networking Integrated Model and Approach M. Richardson, Ed.
Internet-Draft Sandelman Software
Intended status: Standards Track 12 August 2026
Expires: 13 February 2027
Quantum Safe (PQ) Considerations for Autonomic Network Infrastructure
(ANI)
draft-richardson-anima-quantum-safe-4ani-00
Abstract
The imminent arrival of a Cryptographically Relevant Quantum Computer
(CRQC) makes algorithms such as RSA, ECDSA and EdDSA vulnerable to
attack. A transition to Quantum-Safe (PQ) algorithms is occurring.
This document provides specific requirements (Mandatory to Implement)
for Autonomic Network Infrastructure (ANI/ACP) and AgenticAI
manufacturers and operators to be able to seamlessly transition to
Quantum Safe algorithms.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://anima-
wg.github.io/quantum-safe-considerations-4ani/draft-richardson-anima-
quantum-safe-considerations-4ani.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-
richardson-anima-quantum-safe-4ani/.
Discussion of this document takes place on the Autonomic Networking
Integrated Model and Approach Working Group mailing list
(mailto:anima@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/anima/. Subscribe at
https://www.ietf.org/mailman/listinfo/anima/.
Source for this draft and an issue tracker can be found at
https://github.com/anima-wg/quantum-safe-considerations-4ani.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Richardson Expires 13 February 2027 [Page 1]
Internet-Draft ani-qs August 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Voucher Requirements for Autonomic Control Plane . . . . . . 3
4. PKI Requirements . . . . . . . . . . . . . . . . . . . . . . 4
5. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 4
6. IPsec Requirements . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
THIS IS SUBJECT TO MORE WORK
Richardson Expires 13 February 2027 [Page 2]
Internet-Draft ani-qs August 2026
[RFC9958] there is significant concern that current public key
schemes like RSA and ECC will be compromised with a few years of
publication of this document by a Cryptographically Relevant Quantum
Computer (CRQC).
In order to plan for this possibility it is necessary to switch to
quantum-safe algorithms.
Autonomic Control Plans and AgenticAI that make use of Autonomic
Network Infrastructure consist of the following dependancies:
* each manufacturer has an 802.1AR Public Key Infrastructure (PKI)
for the IDevID certificates
* each manufacturer to maintain a system of MASA for Voucher
signing, with a trust anchor predistributed
* each manufacturer has to maintain a system for firmware signing
* each device has to be able to sign Voucher Requests
* each device has to be able to do TLS mutual-authentication
* each operator has to maintain an operational (Domain) Public Key
Infrastructure (PKI) for LDevID
* each operator has to maintain a Registrar with a TLS end-point
* each device has to be able to do IPsec IKEv2 operations with a
quantum-safe PK, and to do quantum-safe key agreement
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Voucher Requirements for Autonomic Control Plane
When ECDSA is supported, curves secp256r1 and secp384r1 SHOULD be
supported. When EdDSA is supported, curves Ed25519 and Ed448 SHOULD
be supported. When RSA is supported, key lengths between 2048 and
4096 bits SHOULD be supported.
ML-DSA [RFC9964] SHOULD be supported for COSE and JOSE signed
vouchers, with [RFC9881] used for CMS format voucher artifacts.
Richardson Expires 13 February 2027 [Page 3]
Internet-Draft ani-qs August 2026
4. PKI Requirements
Neither of these are hybrid algorithms and may not be suitable for
use by a certification authority creating IDevID certificates. For
that use, [I-D.ietf-lamps-pq-composite-sigs] SHOULD be supported.
The decision as to when to transition to quantum-safe algorithms is a
manufacturer decision.
Other choices are possible, but likely will result in Pledge devices
being unable to onboard on networks until the Registrar involved
implements those choices. In such a situation, an automated, zero-
touch onboarding solution may be impossible, but it may still be
possible to use mechanisms such as suggested in [RFC8995],
Section 7.2 to onboard a device.
5. TLS Requirements
For issue 6: the key agreement protocols within TLS and IPsec/IKE are
the subject of documents such as [RFC9954], [RFC10024],
[I-D.ietf-tls-mlkem], [I-D.ietf-ipsecme-ikev2-pqc-auth], and
[I-D.ietf-ipsecme-ikev2-mlkem].
6. IPsec Requirements
Where the significant risk comes from is in all the related
infrastructure required. An attack could be made upon any of the
steps. This includes:
1. the PKI used create and sign IDevID
2. the PKI used by the MASA to sign Vouchers
3. the algorithm used by the Pledge to sign Voucher Requests (the
public key algorithm within the IDevID), and which is used for
client-side certificate authentication in [RFC8995]
4. the PKI used by Registrar operator to authenticate the TLS end-
point for the Registrar within [RFC8995]
5. the PKI used by Registrar operator to provision operational
certificates (LDevID) to the device
6. the algorithms used in the operational certificates to
authenticate the device for operational purposes
7. the key agreement protocols used by the TLS instances, or for
creation of the ACP [RFC8994]
Richardson Expires 13 February 2027 [Page 4]
Internet-Draft ani-qs August 2026
8. the PKI used by the manufacturer to authenticate firmware
updates.
Issue 3 (above) is a concern for [RFC8995], issue 5 is about the
ability of [RFC8995] to use [EST] to provision quantum-safe
algorithms.
For issue 6: the key agreement protocols within TLS and IPsec/IKE are
the subject of documents such as [RFC9954], [RFC10024],
[I-D.ietf-tls-mlkem], [I-D.ietf-ipsecme-ikev2-pqc-auth], and
[I-D.ietf-ipsecme-ikev2-mlkem].
Issue 7, is the domain of [I-D.ietf-suit-mti] which suggests the
inclusion of the HSS-LMS for signing of firmware updates.
The transition of operational aspects (LDevID, IPsec) to quantum-safe
algorithms requires that equipement firmware contain support for the
new algorithms. Once that support is present, there are significant,
but manageable, issues for the operator managing the transition. New
firmware, new (hybrid) certificates issued via [EST] following an
orderly renewal process, along with in-protocol mechanisms being
developed for TLS and IPsec/IKE to allow for an incremental
transition. All the above things are not in scope for this document.
The manufacturer of a device controls what firmware goes into it and
when. To first order, the manufacturer may switch to quantum-safe
methods as soon as:
* it has updated its MASA to verify voucher requests with the new
algorithm, and sign vouchers with the new algorithm
* it has switched its IDevID PKI to use a quantum-safe trust anchor,
updating its qfactory device ID provisioning mechanism to use the
new algorithm
* it has a quantum-safe TLS certificate for it's MASA internet
visible end-point
* it has suitable firmware in the Pledge device that can use the new
algorithms
A manufacturer can essentially treat all new devices produced as
being part of a new product line. That could include putting in a
different MASA URL into the IDevID. That allows for all quantum-safe
operations to be done on a new platform removing any risk to any
installed based.
Richardson Expires 13 February 2027 [Page 5]
Internet-Draft ani-qs August 2026
The limiting factor for doing this is that the operator's Registrar
must be ready to support the new algorithms.
This includes:
* answering provisional-TLS [RFC8995] requests with a quantum-safe
certificate
* accepting quantum-safe client-certificates from new devices
* verification of the Pledge Voucher Request (PVR)
* connecting to the MASA using quantum-safe mutual TLS
* validating/auditing the resulting voucher
Of these steps, only the voucher operations involves Registrar
application code, the rest of this is "just" TLS upgrades necessary
for quantum-safe operation.
It may be possible for manufacturers to provision IDevID using both
traditional and quantum-safe versions. In that case, the Pledge can
look at the certificate presented by the Registrar, and if it is not
quantum-safe, then it can use traditional algorithms. For enterprise
and ISP level equipment used in an [RFC8994] ACP there are no code
space reasons to prevent this. For IoT use cases, there may be code
space, but also network capacity issues with the quantum-safe
methods. This is an evolving problem in the IoT space.
7. Security Considerations
Transitions are hard.
8. IANA Considerations
This document has no IANA actions.
9. References
9.1. Normative References
[EST] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
Richardson Expires 13 February 2027 [Page 6]
Internet-Draft ani-qs August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8366bis]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/rfc/rfc8366>.
[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", RFC 8994,
DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/rfc/rfc8994>.
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/rfc/rfc9881>.
[RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing
and Encryption (JOSE) and CBOR Object Signing and
Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May
2026, <https://www.rfc-editor.org/rfc/rfc9964>.
9.2. Informative References
[I-D.ietf-ipsecme-ikev2-mlkem]
Kampanakis, P., "Post-quantum Key Exchange with ML-KEM in
the Internet Key Exchange Protocol Version 2 (IKEv2)",
Work in Progress, Internet-Draft, draft-ietf-ipsecme-
ikev2-mlkem-09, 5 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-mlkem-09>.
Richardson Expires 13 February 2027 [Page 7]
Internet-Draft ani-qs August 2026
[I-D.ietf-ipsecme-ikev2-pqc-auth]
Reddy.K, T., Smyslov, V., and S. Fluhrer, "Signature
Authentication in the Internet Key Exchange Version 2
(IKEv2) using PQC", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-ikev2-pqc-auth-11, 5 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-pqc-auth-11>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[I-D.ietf-suit-mti]
Moran, B., Rønningstad, O., and A. Tsukamoto,
"Cryptographic Algorithms for Internet of Things (IoT)
Devices", Work in Progress, Internet-Draft, draft-ietf-
suit-mti-23, 22 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-suit-
mti-23>.
[I-D.ietf-tls-mlkem]
Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS
1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
mlkem-09, 20 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
mlkem-09>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/rfc/rfc8366>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
2026, <https://www.rfc-editor.org/rfc/rfc9954>.
[RFC9958] Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
T., and M. Ounsworth, "Post-Quantum Cryptography for
Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026,
<https://www.rfc-editor.org/rfc/rfc9958>.
Richardson Expires 13 February 2027 [Page 8]
Internet-Draft ani-qs August 2026
[RFC10024] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D.
Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key
Agreement Mechanisms for TLS 1.3", RFC 10024,
DOI 10.17487/RFC10024, August 2026,
<https://www.rfc-editor.org/rfc/rfc10024>.
Acknowledgments
TODO acknowledge.
Author's Address
Michael C. Richardson (editor)
Sandelman Software
Email: mcr+ietf@sandelman.ca, https://orcid.org/0000-0002-0773-8388
URI: https://www.sandelman.ca/
Richardson Expires 13 February 2027 [Page 9]