Re: [Pqc] [Ext] Listing pointers to not-yet-standardized PQC algorithms

[Roman Danyliw <[e-mail]>]

Hi Dan!

> -----Original Message-----
> From: Pqc <[e-mail]> On Behalf Of D. J. Bernstein
> Sent: Tuesday, May 16, 2023 3:12 PM
> To: [e-mail]
> Subject: Re: [Pqc] [Ext] Listing pointers to not-yet-standardized PQC algorithms

[snip]
 
> As a procedural matter, the LAMPS charter was last modified in May 2021,
> which is before NIST issued its selections (July 2022). It would be good for
> LAMPS to recognize the security problems at hand and expand its charter
> accordingly.

As a procedural matter, LAMPS re-chartered specifically to integrate future NIST PQC choices into various PKIX-relationship specification.  This certainly wouldn't preclude other work in principle.  If there is new work to propose for LAMPS, please make it there.

> (As a side note, I think that the opposite extreme, with all IETF WGs requiring
> CFRG algorithm vetting, could work well if CFRG takes this job seriously. But
> this would be a much larger change from the current situation, and I think it
> would need an IESG policy decision.)

In my assessment, CFRG does take their role in the IETF community seriously.  IETF WGs greatly benefit from the advice and products of CFRG.

The IESG does not oversee CFRG.  As research group, CFRG is part of the IRTF.

> If there's a problem caused by the differences between the charters, then surely
> the decision on the way forward should start by looking at the relevant goals
> for IETF (such as BCP 188) and figuring out how to organize the work into WGs,
> rather than by one current charter being allowed to override another.

I'm not seeing a situation where the charter of one WG is "overriding another".  Could you please restate the concern.  

> Right now there's a mess of different WGs looking at post-quantum updates to
> specific protocols _and_ looking at protocol-independent questions. Surely it
> would be better to have protocol-independent discussions (example: should
> IETF let NIST slow down IETF's response to the quantum threat?) centralized in
> PQUIP---meaning, e.g., that LAMPS should focus on issues specific to updating
> PKIX and SMIME, and should avoid being in the position of making IETF-wide
> post-quantum decisions.

If there is specific post-quantum updates you think that should be done, please bring it to the appropriate protocol WG.  If a corresponding WG does not exist, PQUIP is the right place to start the conversation.

A centralized WG to address standardizing PQC behavior of various protocols was proposed but did not find consensus.  The consensus was to form PQUIP, in the limited scope that it is (not producing standards).

Roman