[openpgp] Re: Mohamed Boucadair's No Objection on draft-ie tf-openpgp-pqc-14: (with COMMENT)

Aron Wussler <[email protected]> Mon, 15 Dec 2025 15:56:53 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<aUn-TjrLwFXuEPay1x95mbiIW_5nxY-ugFT5bTqCC9sPfqrAzfMmeasZL9n6iG22JaaiJXeLb3NgdvKqqioMOrbkcJlZ-nGjh6MuqDnV5c0=@wussler.it>
Hi Med,

see inline, I pushed some changes to the MR.

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Monday, 15 December 2025 at 15:32, [email protected] <[email protected]> wrote:

> Hi Aron,
> 

> Thanks for the follow-up. Please see inline.
> 

> Cheers,
> Med
> 

> > -----Message d'origine-----
> > De : Aron Wussler [email protected]
> > Envoyé : lundi 15 décembre 2025 13:47
> > À : BOUCADAIR Mohamed INNOV/NET [email protected]
> > Cc : The IESG [email protected]; [email protected]; draft-ietf-
> > [email protected]; [email protected]; [email protected]
> > Objet : Re: [openpgp] Mohamed Boucadair's No Objection on draft-
> > ietf-openpgp-pqc-14: (with COMMENT)
> > 

> > Hi Med,
> > 

> > Thank you for the review :)
> > 

> > We've addressed your comments on GitHub [1] and plan to publish
> > them in the upcoming days.
> > 

> > > I appreciate OPS-related discussion about migration (Section 8)
> > > and
> > > performance (Section 10). This can be even convenient if these
> > > two
> > > sections are moved under an "Operational Considerations"
> > > section.
> > 

> > The reason why we preferred keeping them separate is because 8 is
> > normative and 10 isn't :)
> 

> 

> [Med] ACK. You may then put them at least near each other, but feel free to ignore :-)

[Aron] We split the normative sections and the non-normative, and for the non-normative we started with the most important, aka security considerations.
I would prefer not altering the structure of the document without asking for a wider consensus.

> > > Please find below some very few comments:
> > > 

> > > # Interpretation of RFC 9580
> > > 

> > > CURRENT:
> > > Implementations SHOULD consider the message correctly signed if
> > > at
> > > least one of the non-ignored signatures validates successfully.
> > > This
> > > is an interpretation of Section 5.2.5 of [RFC9580].
> > > 

> > > I read this as basically adhering to what is already in 9580.
> > > 

> > > I find the use of normative language here confusing as it gives
> > > the
> > > impression that this is new behavior. Focusing on new behavior
> > > would
> > > help identify updates to RFC9580 (which is not straightforward
> > > as rightfully raised by Ketan).
> > 

> > This is not clearly specified in RFC 9580, but it's quite
> > implicit, and it's what most implementations are doing.
> > We wanted to clear this up in order to allow for a smooth
> > transition to PQC.
> 

> 

> [Med] I guess "interpretation" is what puzzled me. Maybe saying "Consistent with Section 5.2.5 of [RFC9580], .." or the like, but again feel free to ignore as I have the clarification I wanted. Thanks.

[Aron] Done

> > > # Mapping with US FIPS 20x Tables
> > > 

> > > The various tables do not map 1:1 to their counterpart in FIPS
> > > 20x documents.
> > > For example, how Key share/ Secret key maps to Table 3 of FIPS-
> > > 203?
> > 

> > Changed the tables to contain the original terms for FIPS-20[345]
> 

> 

> [Med] Thank you.
> 

> > > CURRENT:
> > > This feature is generally considered
> > > to be a high security guarantee.
> > > 

> > > # (nit) Believed
> > > 

> > > CURRENT:
> > > All schemes listed here are believed to provide security in the
> > > presence of a CRQC.
> > > 

> > > ..
> > > 

> > > The scheme is
> > > believed to provide security against cryptanalytic attacks based
> > > on
> > > classical as well as quantum algorithms.
> > > 

> > > Not sure "believed" is appropriate in an RFC.
> > 

> > I believe the two proposed changes are conflicting ;) Happy to
> > adjust terminology, as long as it's consistent.
> 

> 

> [Med] If we can get rid of "believed" that would be great. Thanks.

[Aron] Also changed :)

> > Cheers,
> > Aron
> 

> 

> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 

> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 

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

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 343 B)