[lamps] Re: Liaison Statement from ETSI TC ESI WG PQC to IETF LAMPS working group

[Jonathan Hammell <[e-mail]>]

Hi Russ,
Thanks for drafting this response.

Small typo for Use of the HSS/LMS in CMS:
s/RFC 8708/RFC 9708

Apologies if I'm pointing this out too late.

Jonathan

On Wed, Jun 10, 2026 at 1:39 AM Brockhaus, Hendrik
<hendrik.brockhaus=[e-mail]> wrote:
>
> I like the additional pointer to RFC 9810 for managing KEM certificates as ETSI/3GPP uses CMP already.
>
> Hendrik
>
> > -----Ursprüngliche Nachricht-----
> > Von: Russ Housley <[e-mail]>
> > Gesendet: Dienstag, 9. Juni 2026 20:33
> > An: Michael Richardson <[e-mail]>
> > Cc: IETF LAMPS <[e-mail]>
> > Betreff: [lamps] Re: Liaison Statement from ETSI TC ESI WG PQC to IETF LAMPS
> > working group
> >
> > CMP and CMC already have more than one proof-of-possesion approach.  RFC
> > 9883 adds an additional workflow based on a different trust model.  So, I suggest a
> > bit higher-level description around enrollment:
> >
> > The LAMPS WG has been updating certificate enrollment protocols to
> > support certification of KEM public keys.  For example CMPv3 has been
> > published as RFC 9810.  Further work is anticipated related to
> > proof-of-possession and certificate enrollment.  We invite people
> > from the ETSI community to participate should this work get adopted.
> >
> > Russ
> >
> > > On Jun 9, 2026, at 10:57 AM, Michael Richardson <[e-mail]>
> > wrote:
> > >
> > >
> > > Russ Housley <[e-mail]> wrote:
> > >> Please review the proposed response to this liaison statement.
> > >
> > > Weird that ETSI is using the term PQC, as they have preferred "quantum-safe"
> > > otherwise...
> > > EVerything you wrote looks fine to me.
> > >
> > > They did not ask specifically about plans for enrollment of keys that can not
> > > sign (either by policy, or because math).   Okay, that's a pet project of
> > > mine.
> > > I might add:
> > >
> > > "The LAMPS WG has been doing maintenance on enrollment protocols such as
> > CMP
> > > and EST and is contemplating starting new work to update these protocols
> > > and/or the underlying CSR concept to support algorithms that do not support
> > > signing as proof-of-possession.  We invite ETSI to participate in this
> > > process, should it get adopted."
> > >
> > >
> > >> = = = = = = = =
> > >
> > >> Since the CAdES specifications rely in particular on RFC 5652, the
> > >> LAMPS WG wants ETSI TC EIS to be aware of the work that has already
> > >> been accomplished to prepare CMS for use with PQC algorithms.  First,
> > >> RFC 9629 specifies the use of Key Encapsulation Mechanism (KEM)
> > >> Algorithms in the CMS.  Second, several specifications for the use of
> > >> PQC signature algorithms have been written, including: RFC 8708, RFC
> > >> 9814, and RFC 9882.  More are on the way, including support for
> > >> composite signature algorithms.  Third, several specifications for the
> > >> use of PQC KEM algorithms have been written, including: RFC 9936.  More
> > >> are on the way, including support for composite KEM algorithms.
> > >
> > >> Since the EN 319 412 technical specification series build on RFC 5280,
> > >> the LAMPS WG wants ETSI TC EIS to be aware of the work that has already
> > >> been accomplished to prepare public key certificates for use with PQC
> > >> algorithms.  First, several specifications for the use of PQC signature
> > >> algorithms have been written, including: RFC 9802, RFC 9881, and RFC
> > >> 9909.  More are on the way, including support for composite signature
> > >> algorithms.  Second, RFC 9935 specifies the way to carry an ML-KEM
> > >> public key as the certificate subject public key.  Similar
> > >> specifications are on the way for other PQC KEMs, including support for
> > >> composite KEM algorithms.
> > >
> > >> US NIST is assigning algorithm identifiers for PQC algorithms that they
> > >> specify, and you will see that the RFCs listed above use these
> > >> algorithm identifiers for these algorithms.
> > >
> > >> ISO has assigned algorithm identifiers for the FrodoKEM algorithm.  The
> > >> LAMPS WG is considering adopting specifications related to this
> > >> algorithm, and these use the ISO-assigned algorithm identifiers.
> > >
> > >> IANA has assigned algorithm identifiers for HSS/LMS, XMSS, XMSS^MT,
> > >> composite KEM algorithms, and composite signature algorithms.  These
> > >> algorithm identifiers are included in this registry:
> > >
> > >>
> > https://www.iana.or/
> > g%2Fassignments%2Fsmi-numbers%2Fsmi-numbers.xhtml%23smi-numbers-
> > 1.3.6.1.5.5.7.6&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd6c8
> > 9f1fbdba4ec6e31008dec6559442%7C38ae3bcd95794fd4addab42e1495d55a%7C1
> > %7C0%7C639166268065463639%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> > hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=BWj3U%2BqMwYYaBIhUYfNxTx2MZ%
> > 2FECUz%2Faj1Okj%2F5NRzY%3D&reserved=0
> > >
> > >> Best Regards, Russ and Tim
> > >
> > >
> > >>> On Jun 8, 2026, at 11:39 AM, Russ Housley <[e-mail]>
> > >>> wrote:
> > >>>
> > >>>
> > >>>
> > >>>> Begin forwarded message:
> > >>>>
> > >>>> From: ETSI ESIsupport <[e-mail]> Subject: Liaison
> > >>>> Statement from ETSI TC ESI WG PQC to IETF LAMPS working group Date:
> > >>>> June 8, 2026 at 4:37:44 AM EDT To: "[e-mail]"
> > >>>> <[e-mail]>, "[e-mail]"
> > >>>> <[e-mail]>, "[e-mail]"
> > >>>> <[e-mail]> Cc: Nick Pope <[e-mail]>,
> > >>>> Jean-Emmanuel Perez Hernandez
> > >>>> <[e-mail]>, Lucas PRABEL
> > >>>> <[e-mail]>
> > >>>>
> > >>>> Dear IETF LAMPS experts,
> > >>>>
> > >>>> Please find attached a liaison statement from ETSI TC ESI WG PQC to
> > >>>> IETF LAMPS working group.
> > >>>>
> > >>>> 2. Actions: Considering that the CAdES specifications rely in
> > >>>> particular on RFC 5652, and that the EN 319 412 technical
> > >>>> specification series build on RFC 5280, ESI PQC would welcome
> > >>>> collaborating with the IETF LAMPS working group to ensure that the
> > >>>> CAdES standard and the EN 319 412 series remains aligned with the
> > >>>> latest and upcoming specifications from IETF LAMPS that deal with
> > >>>> PQC, in particular it is kindly requested to IETF LAMPS for an update
> > >>>> on the status of the support of PQC algorithms in IETF LAMPS
> > >>>> specifications, especially whether algorithm identifiers have already
> > >>>> been allocated for use in CMS signatures and X.509 certificates.
> > >>>>
> > >>>> 3. Date of next meetings of the originator: ESIPQC#1a 3rd July 2026
> > >>>> ESIPQC#1b 28th August 2026 ESIPQC#2 15 October 2026
> > >>>>
> > >>>> Best regards,
> > >>>>
> > >>>> Antoine.
> > >>> <ESI(26)000319_LS_form_ESI_PQC_to_IETF_LAMPS.docx>
> > >>>
> > >>> _______________________________________________ Spasm mailing list -
> > -
> > >>> [e-mail] To unsubscribe send an email to [e-mail]
> > >
> > >
> > >> ----------------------------------------------------
> > >> Alternatives:
> > >
> > >> ----------------------------------------------------
> > >> _______________________________________________ Spasm mailing list --
> > >> [e-mail] To unsubscribe send an email to [e-mail]
> > >
> > > --
> > > Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
> > >           Sandelman Software Works Inc, Ottawa and Worldwide
> > >
> > > **       My working hours and your working hours may be different.         **
> > > ** Please do not feel obligated to reply outside your normal working hours **
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Spasm mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]