[saag] Re: post quantum guidance draft

Long-lived devices, or components within devices, that rely on public keys throughout their entire lifetime are not rare, they are common. A large and growing number of these devices implement IETF standards such as PKIX, CMS, IKEv2, TLS handshake, SSH, COSE, EDHOC.


Long-term signature keys are used for firmware and software updates, deployment and provisioning, secure boot, management, remote attestation, and similar functions. As an example, organizations such as IEEE, 3GPP, GSMA, TCG, and GlobalPlatform use PKIX for device certificates.


The reasons public keys are not updated vary. Sometimes they are hardcoded, sometimes the manufacturer loses interest or goes bankrupt, sometimes the device does not support newer algorithms, and sometimes users simply do not take the time or have the expertise to manually update devices, which may require specific hardware or technical competence. Considering just SSH, a significant fraction of devices still run libraries that are 10–20 years old.


If the IETF issues guidance, I strongly believe it should explicitly address long-lived devices.


Cheers,
John Preuß Mattsson


On 2025-12-12, 10:02, "Bellebaum, Thomas" <[email protected]> wrote:

Hi John,


> A common position is that there is a meaningful chance of a CRQC being built within the next 15 years. If that assumption is true, then we urgently need to migrate signatures in long-lived devices. Recommending inaction in that scenario is like having your house on fire, arguing about whether to use a powder or foam extinguisher, and ultimately deciding to recommend doing nothing.


Yeah, I originally wrote something about long-term authenticity. Stephen eventually changed that to


> Systems dealing with signatures that are required to still be
> usefully verifiable in the timeframe that might include a CRQC are
> rare and complex and are not further considered here. Systems that
> need to select a signature verification public key (and hence
> algorithm) now, for use in some years time, are also not covered by
> this guidance.


FWIW I think for a first guidance document this direction is a good balance. It makes for a short recommendation section for common scenarios yet is still explicit about such use cases. I would like the "For almost all deployments" in section 3.2 to become more explicit eventually (e.g. "For data/peer authentication within the next few years"; it is ok if this somewhat limits the scope to use cases we feel more confident about) and the "rare and complex" in the justification section to be more helpful in deciding whether or not $my_use_case might require worring further about such things.
But I feel like those are details we could work out :)


Best,


-- TBB

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]