]> Sandelman Software Works

mcr+ietf@sandelman.ca

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.

Introduction As explained by and , the advent of a Cryptographically Reelvant Quantum Computer (CRQC) will make public key infrastructures systems vulnerable to attack. describes a PKI system with a set of End-Entity Certificates 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 ) allows the vendor to do late binding to the customer, while maintaining the integrity of the supply chain. 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, ) 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.

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 when, and only when, they appear in all capitals, as shown here. defines a number of useful terms, including pkilevel

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 Certificate object constructed according to advice in . 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 . There are often extensions in the IDevID relating to MUD , and BRSKI . It is unusual for IDevID PKI to have Certificate Revocation Lists (CRLs), and so no CRL distribution points will be included. 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 ) 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 's set of suggested algorithms , 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.

Challenges of Hash Based Signing (HBS) algorithms The problem with Hash-Based Signing systems such as HSS/LMS 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.

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 's definition LMS_SHA256_M32_H15 which has a tree height of 2^15 (32768), and signature size of 32-bytes. 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 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.

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 .

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 , 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.

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.

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 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

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. 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.

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 , 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 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.

IANA Considerations This document does not make any requests to IANA.

Security Considerations This draft is aspirational at this point.

References Normative References Sandelman Software Works This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. // This document is a product of the Internet Research Task Force // (IRTF). The IRTF publishes the results of Internet-related // research and development activities. These results might not be // suitable for deployment. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. Informative References One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. IEEE n.d. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE). This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. Arm Limited Nordic Semiconductor Openchip & Software Technologies, S.L. The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019). In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Watsen Networks Sandelman Software IoTconsultancy.nl Futurewei Technologies Inc. Huawei This document defines a strategy to securely assign a candidate device (Pledge) to an Owner using a digital artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer which is represented by the Manufacturer Authorized Signing Authority (MASA). This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995.