[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 09:48:35 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<RQU8WMGiPZZbep4Wlu60AbJdTot4QMmMw_G2idH6MPHqEgoorIn2eeHMbLD3rxUbryQlP68XutmgOJ0qK191hs3Rcamav1ijxJX3cefNFN8=@wussler.it>
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

> ### Abstract
>
> As mentioned by the id-nits tool, RFC 9580 must be listed in the abstract as
> being updated.

Added to the abstract

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

> ### Section 1
>
> s/The OpenPGP protocol supports/The OpenPGP protocol supports [RFC 9580]/
>
> s/National Institute of Standards and Technology/US National Institute of
> Standards and Technology/ since "national" does not mean "USA" in the rest of
> the world ;-)
>
> Strongly suggest to add a sentence such as "This document updates RFC 9580 by
> adding KEM and signature algorithms specified in sections 4, 5, and 6.

All addressed

> ### Section 1.2.3
>
> Who is the "we" in `We refer` ? The authors ? the WG ? The IETF ? Please avoid
> ambiguities (passive voice is an easy fix). This may occur in other places as
> well.

Made passive

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

> ### Section 11
>
> Add a reference to the IANA registries (e.g.,
> https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-public-key-algorithms)
> to avoid any ambiguities.

Added a reference

Cheers,
Aron

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

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



On Tuesday, 9 December 2025 at 13:37, Éric Vyncke via Datatracker <[email protected]> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-openpgp-pqc-14: Discuss
> 

> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 

> 

> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 

> 

> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-openpgp-pqc/
> 

> 

> 

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 

> # Éric Vyncke INT AD comments for draft-ietf-openpgp-pqc-14
> CC @evyncke
> 

> Thank you for the work put into this document. As an OpenPGP user, I warmly
> welcome this update!
> 

> Please find below one blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points/nits (replies would be appreciated even if only for
> my own education).
> 

> I hope that this review helps to improve the document,
> 

> Regards,
> 

> -éric
> 

> Note: this ballot comments follow the Markdown syntax of
> https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by
> a tool to create github issues.
> 

> ## DISCUSS (blocking)
> 

> As noted in
> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> a DISCUSS ballot is a request to have a discussion on the points below; I
> really think that the document would be improved with a change here, but can be
> convinced otherwise.
> 

> ### Section 2.1
> 

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

> Per
> https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/,
> SHOULD has to be 'shouldered' by explanations on when to bypass or what are the
> consequences of bypassing it.
> 

> 

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 

> 

> ## COMMENTS (non-blocking)
> 

> ### Abstract
> 

> As mentioned by the id-nits tool, RFC 9580 must be listed in the abstract as
> being updated.
> 

> I am trusting the SEC AD to check that this point will be addressed ;-)
> 

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

> ### Section 1
> 

> s/The OpenPGP protocol supports/The OpenPGP protocol supports [RFC 9580]/
> 

> s/National Institute of Standards and Technology/US National Institute of
> Standards and Technology/ since "national" does not mean "USA" in the rest of
> the world ;-)
> 

> Strongly suggest to add a sentence such as "This document updates RFC 9580 by
> adding KEM and signature algorithms specified in sections 4, 5, and 6.
> 

> ### Section 1.2.3
> 

> Who is the "we" in `We refer` ? The authors ? the WG ? The IETF ? Please avoid
> ambiguities (passive voice is an easy fix). This may occur in other places as
> well.
> 

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

> ### Section 11
> 

> Add a reference to the IANA registries (e.g.,
> https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-public-key-algorithms)
> to avoid any ambiguities.
> 

> 

> 

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