[saag] Re: post quantum guidance draft

Let's not forget about the time it takes to migrate, even for updateable
software and short-lived devices.

On Fri, Dec 12, 2025 at 10:47 AM John Mattsson <john.mattsson=
[email protected]> wrote:

> 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" <thomas.bellebaum=
> [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]
>

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