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

Hello Aron,

I had a look at the added text in section 2.1, it adds some hints about the "SHOULD" in the table 2, but no clear definition of the MUST/MAY/SHOULD in the table 1, especially when the IANA registry for public key algorithms does not have such a column.

As a way forward, I strongly recommend using a similar approach used in section 9.1 of RFC 9580, i.e., moving the MUST/MAY/SHOULD out of the table in the text and keeping the added text & linking it to the SHOULD.

Regards

-éric


From: Aron Wussler <[email protected]>
Date: Monday, 15 December 2025 at 17:07
To: Eric Vyncke (evyncke) <[email protected]>
Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>
Subject: Re: [openpgp] Re: Éric Vyncke's Discuss on draft-ietf-openpgp-pqc-14: (with DISCUSS and COMMENT)

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]