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

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 :-)

> 
> > 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.

> 
> > # 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.

> 
> 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]