Network Working Group M. Richardson Internet-Draft Sandelman Software Works Intended status: Standards Track 13 October 2026 Expires: 16 April 2027 Quantum-Safe Device Identity Public Key Infrastructure (PKI) draft-richardson-quantum-safe-devid-pki-00 Abstract This document discussed options for building a quantum-safe 802.1AR Device Identity certificates. The focus of this document is on IDevID which are used for onboarding of devices, detection of counterfeit devices, and limited remote attestation methods. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 16 April 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. Richardson Expires 16 April 2027 [Page 1] Internet-Draft QC-IDevID October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Constraints on Device Identifier credentials . . . . . . . . 3 3.1. Challenges of Hash Based Signing (HBS) algorithms . . . . 5 4. Proposed Public Key Infrastructure architecture . . . . . . . 5 5. Options for IDevID End-Entity Certificate algorithms . . . . 7 5.1. Proposal One: ECDSA End-Entity certificates for Onboarding . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Proposal Two: A small Hash Based Signature (HBS) for Onboarding . . . . . . . . . . . . . . . . . . . . . . . 8 6. Infrastructure/Operational Key Infrastructure . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction As explained by [RFC9958] and [RFC9794], the advent of a Cryptographically Reelvant Quantum Computer (CRQC) will make public key infrastructures systems vulnerable to attack. [IDevID] describes a PKI system with a set of End-Entity Certificates [RFC5280] deployed in the factory, at device manufacturing time. The private asymmetric key is held inside the device, often built very deep into the device, such as through blown fuses inside the CPU module, and effectively not extractable without physical methods. IDevID systems are expected to surive for decades, and devices with built-in certificate are expected to be available for long periods of time. For instance, an IoT smart lightbulb could be purchased in quantity, and stored in a warehouse against future smart building needs. At the other end of the scale, ISP/Enterprise switching equipment can cost hundreds of thousands of dollars, require multiple people to carry, but expected to be replaceable within a 4hr service window. Such service level agreements (SLA) require that the vendor maintain a diverse inventory of spares, for equipment that might no longer even be actively manufacturered. Vendors keep one unit of each kind for a multitude of customers who are within a 4hr transportation window. The use of IDevID with a suitable onboarding protocol (such as [RFC8995]) allows the vendor to do late binding to the customer, while maintaining the integrity of the supply chain. Richardson Expires 16 April 2027 [Page 2] Internet-Draft QC-IDevID October 2026 The use of quantum-safe algorithms (whether hybrid or single- algorithm) in larger equipment intended to run on very well connected networks is probably acceptable. For smaller, lower power controllers (class J10 or smaller, [I-D.ietf-iotops-7228bis]) operating over Challenged Networks, the constraints of total number of bytes, and total amount of space make straight quantum-safe algorithms like ML-DSA a problem. This document reviews the requirements for Device Identifier PKI, how onboarding systems use the credentials, and proposes architectural ideas for construction and operation of a quantum-safe PKI. 2. Terminology Although this document is not an IETF Standards Track publication, it adopts the conventions for normative language to provide clarity of instructions to the implementer. 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. [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] defines a number of useful terms, including pkilevel 3. Constraints on Device Identifier credentials The device identifier is a certificate and associated private key (stamp) built-in to the device at manufacturing time. The credential is a PKIX [RFC5280] Certificate object constructed according to advice in [IDevID]. IDevID have been deployed widely by many vendors, but in 2026, they are not yet ubiquitous. For instance, the Cisco IDevID concept is called SUDI: System Unique Device Identifier. IDevID use manufacturer assigned SubjectNames, often using the X520SerialNumber attribute to store a manufacturer unique serial number. Some manufacturers will use their ethernet address, aka the IEEE assigned OUI as their serial number, and some store this as a SubjectAltName, such as an MAC Address [RFC10031]. There are often extensions in the IDevID relating to MUD [RFC8520], and BRSKI [RFC8995]. It is unusual for IDevID PKI to have Certificate Revocation Lists (CRLs), and so no CRL distribution points will be included. Richardson Expires 16 April 2027 [Page 3] Internet-Draft QC-IDevID October 2026 [IDevID] specifies that IDevID End Entity Certificates do not expire, but as the notAfter attribute is not optional, an end-date of "99991231" is defined to be "infinite". End Entity certificates are not in general replaced or updated during the life of the device. Replacing or updating the certificate would in many cases require physical access to the device in order to load a new certificate/credential. If the new credential is to be associated with a new private key, then that new key needs to be generated securely (ideally, inside the device, in a place that can not be exfiltrated), and while also communicating the public part of the key pair to the certification authority. Doing such a thing would require every device to be located in a warehouse, unpacked, powered on, and then, after the update, replaced into the packaging to wait for it's eventual use. The longevity of the IDevID and the inaccessibility of it makes securing this ecosystem against a CRQC more difficult than for other systems. The web browser ("WebPKI") is a polar opposite: continuously and easily updated clients and servers that can come with the latest code and recent trust anchors. Concerns that the quantum-safe algorithms like ML-DSA might be broken by some non-quantum method/mathematics (such as [brokensike]) can be mitigated in that ecosystem through hybrid constructions, and/or fast deployment of new algorithms. In the hybrid construction the classic algorithm mitigates against the quantum-safe algorithm being weak, and the quantum-safe algorithm mitigates against the CRQC. If/when one of the sides of this hybrid construct are defeated, then updates to software would stop trusting that part of the construct, and the WebPKIs would stop using that part. The above process does not work for devices that are still in a box. They can not receive firmware updates, and the algorithm choices will persist for potentially decades. In the industrial, automotive, transport and medical areas, spare components are needed in order to keep equipment operational for what are often multi-decades of operation. The SUIT protocol [RFC9019]'s set of suggested algorithms [I-D.ietf-suit-mti], includes the hsslms-a256kw-a256ctr algorithm for signing firmware updates. This Hash-Based Signing algorithm (HBS) is not subject to the Shor algorithm, and is therefore believed to be immune from quantum-computer based attacks. Richardson Expires 16 April 2027 [Page 4] Internet-Draft QC-IDevID October 2026 3.1. Challenges of Hash Based Signing (HBS) algorithms The problem with Hash-Based Signing systems such as HSS/LMS [RFC8554] is that the signing mechanism is stateful. Were two signatures made from the same part of the Merkle tree, then the security of the system is compromised. This puts significant, but not unsolvable, operational constraints on keeping the signing system resilient against loss due to damage. A backup (business-continuity) system for a more traditional ("classical"), or ML-DSA based Certification Authority can be backed up at pretty much any point in time, and that backup can be restored and put into operation. This allows both for recovery from events like fire, earth quake, plague/pandemic without respect to what the state of the primary system is. It is even possible to horizontally scale the signing system across multiple data centers, (on multiple continents even) and operate both at the same time. This is not possible for Hash Based Signing: a naive backup/restore of the operation of the signer does not work. Hash-Based Signing systems such as HSS/LMS have to be provisioned with the number of signatures that they will make. This number is finite, and higher numbers result in larger trees and larger signatures. Once a HBS reaches the end of its lifespan, then it has to destroyed and a new one created. One way to deal with the backup challenge of the HBS is to do _sectorization_ of the signing space. After initialization, the signing space if split up into some number of ranges, called sectors. Signer A might have signatures 0 through 8191, while Signer B has signatures 8192 through 16383. 4. Proposed Public Key Infrastructure architecture The device manufacturer establishes a trust anchor, in a set of Hardware Security Modules, as an HSS/LMS key. This trust anchor is the basis of the manufacturer IDevID Certification Authority. This key is shared among the HSM device(s), and is sectorized. (Caveat about FIPS/NIST details) It is kept by the device vendor: offline when not in use. The HSS/LMS parameters are configured for 32768 signatures. The corresponds to [RFC8554], Section 5.1's definition LMS_SHA256_M32_H15 which has a tree height of 2^15 (32768), and signature size of 32-bytes. Richardson Expires 16 April 2027 [Page 5] Internet-Draft QC-IDevID October 2026 This system is sectorized into up to four sectors, each having 8192 possible signatures. This is the PKIlevel 0, the trust anchor. Every day for which there is manufacturing of devices, another HSS/ LMS key pair is created. This can be done in/at the factory, nearby, or accessible over a network from the factory, but kept at the vendor's location. The considerations around this decision are affected by business considerations, political considerations for the factory location, vs resiliency that allow the factory to continue to operate without access. This new key pair is configured as a subordinate (pkilevel=1) Certification Authority That involves having the root CA (pkilevel=0) sign a certificate for the subordinate CA. That is done once per (operating) day, once per factory. For a single factory operating 5 days/week (250 days/year), a 8192 signature HBS can operate for approximately 32 years, (per sector). This subordinate CA operates in association with the factory, signing End Entity IDevID certificates. A 2^15 tree height allows for 32768 devices to be manufactured in a way, and this is likely more than a typical factory produces in a single day. A smaller tree height will could reduce signature size. Alternatively, this subordinate CA could be operated for more than one production day. This document recommends that the subordinate CA be operated only for that single production day, that the signing state be kept in memory, to be thrown away at the end of the day. (Should a power failure occur, all the state is lost, but the factory likely also stops. Should power be restored, then that can be considered a new production day) The subordinate CA is ideally created on-site, in-situ, with the subordinate CA Certificate (signed by the root CA) created at that time. An alternative way is that the subordinate CA is created by the vendor, at/near the root CA, the subordinate certificate created, and then shipped (online or by courier) to the factory for use. The subordinate certificate is created with an infinite ("99991231") notAfter day, as that certificate never expires, even though no signatures are issued after the production day. By destroying the subordinate CA at the end of every production run, the concern that the private (stateful) parts are backed up and reused (restarting the signature count) the next day are reduced. This architecture allows for 8192 production days, each of which produces up to 32768 devices, for a total of 268 million devices. This count can be for a single model, or for some combination of device models. If this number is too small for all devices, then Richardson Expires 16 April 2027 [Page 6] Internet-Draft QC-IDevID October 2026 different device models can reasonably have different trust anchors, up to some reasonable limit set by the ability of the different trust anchors to be uniquely identified by target customers. 5. Options for IDevID End-Entity Certificate algorithms Current (Web)PKI systems tend to use a single algorithm for all levels of the PKI. So, if the trust anchor is ECDSA, then all certificates will also be ECDSA. (The exact curve used can vary. For RSA, the key sizes can equivalently be varied) This proposal does not stick that that habit, as it is not required by [RFC5280]. 5.1. Proposal One: ECDSA End-Entity certificates for Onboarding In this model the End-Entity (pkilevel=2) IDevID certificates (and keypair) that are embedded into the devices remain as 256-bit ECDSA keys. Although not quantum-safe themselves, these certificates are signed by a pair of quantum-safe CAs (the daily factory subordinate CA, and the trust anchor CA). There are two key observations that allow for this. 1. the certificate, and therefore the public key, is stored in the device at manufacturing time. It is not visible until the device is removed from its box and powered on the first time. No matter how fast/cheap a CRQC might become, it can not attack a public key nobody has yet seen. Whether or not a CRQC will eventually become low enough cost to be used to attack a single End-Entity device certificate is open to debate. It is certain that the initial price will be quite high, and the time to do an attack will be measured in minute to hours. Attackers will focus on breaking trust anchors, particularly those associated with firmware signing for devices with massive or critical uses. 1. Onboarding processes including those described in [RFC8995], OPC UA, CSA/MATTER, take only a few minutes at most. After the device is accepted into the operational network, the device is provisioned with an Operational Certificate, an LDevID. During this process, the device firmware can also undergo an upgrade (signed by a suitable quantum-safe firmware signing key), which could bring in support for algorithms that either did not exist when the device was first manufactured, for which there was not yet evidence of safety, or even removing algorithms which are not safe. Richardson Expires 16 April 2027 [Page 7] Internet-Draft QC-IDevID October 2026 The LDevID is typically not of infinite duration, is often replaced during the operational lifetime of the device, often with new private keys generated. It may come to be that there are no asymmetric algorithms that are both safe and sufficiently consise that they can be used in challenged IoT networks. One possible result might be that IoT systems will transition to using symmetric systems such as Kerberos, and the onboarding mechanism would involve doing a kinit for the device instead. In this proposal the IDevID would be an ECDSA key, even after a CRQC. It would become visible the first time the device attempts to onboard to a network, and it would be at that point that the public key would first become visible. Only at that point could a CRQC be applied to this key, finding a private key that corresponds to the visible public key. This is a race: can the device onboard and receive a quantum-safe operational key before the CRQC breaks the keys. Onboarding is an activity that takes on the order of 5 minutes, so even if it takes less than 5 minutes to break a key, unless the onboarding and CRQC are coordinated, the CRQC is likely to be busy breaking another key. Further, until the cost of the CRQC is significantly inexpensive, using it to attack an End-Entity IDevID may be unjustified. Doing so breaks only a single device, not a class of systems. 5.2. Proposal Two: A small Hash Based Signature (HBS) for Onboarding In this model the End-Entity (pkilevel=2) IDevID certificates (and keypair) that are embedded into the devices are a very small HMS/LSS. Onboarding with a protocol like [RFC8995] requires only a few signatures: 1. a signature on the voucher-request. 2. a signature for the TLS client-side authentication 3. possible signature of Remote Attestation Evidence [RFC9334] An HMS/LSS that is sized to be able to do only 256 signatures could quite easily deal with three signatures. However, it is possible that a device might have to attempt to onboard to a number of possible networks before it finds the right network. Richardson Expires 16 April 2027 [Page 8] Internet-Draft QC-IDevID October 2026 This is a problem in general for onboarding of battery powered devices on wifi. The device is as likely to run out of battery before it finds the right network, as it is to run out of signatures. For a number of small sensors, the onboarding process is expensive, but once onboarded the device wakes up once or twice a day, living on that initial charge for a few years. For other devices, power is scavanged from other sources (light, heat, etc.), and the challenge during onboarding is that the device is limited in the rate at which it can use energy, rather than the total amount. 6. Infrastructure/Operational Key Infrastructure A device onboards onto a specific network. That network will have an operational PKI using a specific set of algorithms. In [RFC8995], a provisional TLS connection that is created. The authenticity of the server side of the TLS connection is not authenticated at the time the TLS connection is initialized. Instead, that credential becomes part of the voucher-request, and the MASA signs a voucher pinning the same credential for the device. The nature of that operational credential needs to be understood well enough by the device in order for it to be pinned. If that algorithm has to change to one that the device has no code, then the device will need to do a firmware upgrade. There then becomes to order of operations problem: onboarding requires new firmware, but getting new firmware requires onboarding. XXX SOLUTION TBD. The signature that the MASA creates on the [I-D.ietf-anima-rfc8366bis] voucher has to be verifiable by the device. The best choice for the device would be a hash-based signature. The MASA will potentially need to do an essentially unlimited number of signature, this will require a PKI with at least two layers of CA similiar to the IDevID CA. It may need to be larger than that. Fortunately, the MASA can be split up into multiple trees by product line, and even different production runs of the device could come with different trust anchors. At the extreme, a unique symmetric key could be provisioned into every device, a copy kept by the MASA, and a simple keyed symmetric hash done over the voucher. While this would not allow for the Operational Registrar to verify the voucher, that is not critical for the onboarding process that BRSKI provides. Richardson Expires 16 April 2027 [Page 9] Internet-Draft QC-IDevID October 2026 7. IANA Considerations This document does not make any requests to IANA. 8. Security Considerations This draft is aspirational at this point. 9. References 9.1. Normative References [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] Richardson, M., "A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors", Work in Progress, Internet-Draft, draft-irtf- t2trg-taxonomy-manufacturer-anchors-21, 24 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, April 2019, . 9.2. Informative References [brokensike] "Post-Quantum Safe Algorithm Candidate Cracked in an Hour on a PC", 5 August 2022, . [I-D.ietf-anima-rfc8366bis] Watsen, K., Richardson, M., Dijk, E., Eckert, T. T., and Q. Ma, "A Voucher Artifact for Onboarding Protocols", Work in Progress, Internet-Draft, draft-ietf-anima-rfc8366bis- 37, 5 October 2026, . Richardson Expires 16 April 2027 [Page 10] Internet-Draft QC-IDevID October 2026 [I-D.ietf-iotops-7228bis] Bormann, C., Ersue, M., Keränen, A., and C. Gomez, "Terminology for Constrained-Node Networks", Work in Progress, Internet-Draft, draft-ietf-iotops-7228bis-10, 6 July 2026, . [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, . [IDevID] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", n.d., . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage Description Specification", RFC 8520, DOI 10.17487/RFC8520, March 2019, . [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, . [RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Richardson Expires 16 April 2027 [Page 11] Internet-Draft QC-IDevID October 2026 [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for Post-Quantum Traditional Hybrid Schemes", RFC 9794, DOI 10.17487/RFC9794, June 2025, . [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, . [RFC10031] Housley, R., Bonnell, C., Mandel, J., Okubo, T., and M. StJohns, "Media Access Control (MAC) Addresses in X.509 Certificates", RFC 10031, DOI 10.17487/RFC10031, August 2026, . Author's Address Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Richardson Expires 16 April 2027 [Page 12]