[openpgp] Re: Éric Vyncke's Discuss on draft-ietf-ope npgp-pqc-14: (with DISCUSS and COMMENT)

Aron Wussler <[email protected]> Mon, 15 Dec 2025 16:07:10 +0000

Newsgroups	gmane.ietf.openpgp
Message-ID	<3-Vm1TdrvfjGgWUNXY-87YJWWE5MpkmIxg0lRLsO2XMgUR9NB64e5wV3GEWlmXNWHNLUlcInGXtlmON1IMLjIWp1w_mjp8lXjF-OI4z4s5s=@wussler.it>

Hi Éric,

See inline

Cheers,
Aron

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



On Monday, 15 December 2025 at 16:24, Eric Vyncke \(evyncke\) <[email protected]> wrote:

> Hello Aron,
> 

> Thank you for your email. I had a look at the PR and did not find anything related to my DISCUSS point (or was it addressed in another PR ?)
> 

> See below for more comments, search for EV>
> 

> Regards
> 

> -éric
> 

> PS: cool to have your email PGP encrypted to me and in the clear to the IETF mail archives 😉
> 

> On 15/12/2025, 10:48, "Aron Wussler" <[email protected]> wrote:
> 

> Hi Éric,
> 

> Than you for the review! We've addressed your concerns in a PR on GitHub [1] that we plan to merge and publish in the next days.
> 

> > ### Section 2.1
> > What is the context for the BCP14 terms in the "Requirement" column ? I.e., is
> > it for implementation and/or deployment ?
> 

> Added some context
> 

> EV> as written above, I fail to see any change in this section.


[Aron] The discuss point is addressed (or at least tried to address) in the diff on line 349-350:

> The larger parameter sets of ML-DSA and ML-KEM (Algorithm IDs 31 and 36) are recommended to support interoperability, but they are not required for compliance.
> Implementations targeting highly constrained environments may omit these larger variants.



> 

> > The term 'composite' in this context was new for me and is only explained at
> > the end of section 1 :-( unsure how to fix this though.
> 

> This is quite specific language, and I think it makes sense to keep it there.
> It is "standard language" for RFC 9794.
> 

> EV> And I have read the added text, thanks.
> 

> > ### Section 7.1
> >
> > Why not a MUST in `An implementation SHOULD use AES-256` as it is followed by
> > `if all recipient certificates indicate support for it` ?
> >
> > When can the 2 other "SHOULD" be bypassed ? Please avoid ambiguities per
> > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
> 

> This is because a MUST implies that a message not using AES-256 is invalid, and it should be rejected on decryption.
> This MUST cannot be enforced, as the receiving implementation may not have all the certificates of the other recipients available, and can't validate the policy. So it can't properly reject a malformed message.
> 

> EV> OK but suggest adding this explanation next to the SHOULD 


[Aron] Added a sentence to the spec


> [1] https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/253/files
>

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

signature.asc (application/pgp-signature, 343 B)