[saag] Post-Quantum Resistance Cryptography Considerations ( was post quantum guidance draft)

Hi Steve,

After more than 80 email exchanges on the saag list under the topic 
"post quantum guidance draft" , I have a proposal
and for this proposal, I changed the topic of the thread into: 
Post-Quantum Resistance Cryptography Considerations.

All RFCs are required by RFC 2223 to contain a Security Considerations 
section.
RFC 3552, i.e., BCP: 72, issued in July 2003, has the following title 
"Guidelines for Writing RFC Text on Security Considerations".

At the moment, all RFCs are not required to have a Privacy 
Considerations section. RFC 6973 (Privacy Considerations for Internet 
Protocols) states:

    "Whether any individual document warrants a specific privacy
    considerations section will depend on the document's content".

  In the same way:

    "Whether any individual document warrants a specific Post-Quantum
    Resistance Cryptography Considerations section will depend on the
    document's content.

  Considering the thread initiated by Steve, I raise the following question:

    Would be appropriate for all RFCs prescribing or recommending in one
    or more contexts the use of one or more cryptographic algorithms,
    to [mandate / recommend ?] the presence of a section to provide
    guidance for the use of, or the migration to, Post-Quantum resistant
    algorithms ?

  If no guidance is provided, that title of that section [shall / should 
?] still be present and [shall / should ?] include a sentence stating that:

    At the time of the publication of this document, no guidance is
    provided for the use of, or the migration to Post-Quantum resistant
    cryptographic algorithms.

  This approach would leave to the WGs the responsibility to write what 
they believe is appropriate to say in the context of a given RFC.

The document that Steve originally proposed to develop could be a 
document similar to RFC 3552, with a title like:

    "Guidelines for Writing RFC Text on Post-Quantum Resistance
    Cryptography Considerations".

Denis

> Hiya,
>
> On 12/12/2025 13:52, Salz, Rich wrote:
>
>> I guess I was too cute, trying for a Lord of the Rings reference. I 
>> didn’t mean “rule” in any real sense of constraining what IETF WG’s 
>> do. Each of the many WGs you summarize wants to do PQ stuff and 
>> thinks they should. An IETF document that says “this part is fine, 
>> but maybe don’t do that part right now” is going to contradict all 
>> those efforts.
>
> Well, it's not saying "don't do" to implemeters but rather
> "don't deploy" to those deploying.
>
> But, it's a fair point to say that if a WG has developed PQ
> deployment guidance for a protocol, then that specific
> guidance should over-ride more generic guidance.
>
> I think having this (proposed) document could also make it
> easier for WGs to finish their work, e.g. if we have general
> guidance for hybrid KEMs (or x25519 and ML-KEM) that might
> reduce the friction in WGs when they want to define other
> codepoints that could be controversial in the absence of
> general guidance.
>
>> As for near-term guidance, how do we know when the time has come?
>
> The time for this guidance (IMO:-) is... now.
>
> And the time to supercede it is when we know how to do
> sigs for email and the web and related PKIs. Maybe in a
> year or two.
>
> After that, maybe when there's some credible PQ story from
> plants or related to dnssec.
>
> Cheers,
> S.
>
>
> _______________________________________________
> saag mailing list [email protected]
> To unsubscribe send an email [email protected]

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