[openpgp] Re: Deb Cooley's No Objection on draft-ietf-open pgp-pqc-14: (with COMMENT)

Aron Wussler <[email protected]> Mon, 15 Dec 2025 12:45:58 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<syW2nCvSAbjbm8OIeQPOtlTGEZ91rr2ubOZ_HQ-eFBv-INmfiKelKRpj5ObP2hdqUyVRTLPMFTIWAn9d1JkujDoUB7DLbH7uVqbxwomIGsU=@wussler.it>
Hi Deb,

Thank you as well for the review! We've taken action and prepared a PR on GitHub [1] and plan to publish it in the upcoming days in version 15.

> Section 1.4.2, second para: PKESK? please, spell out the first time.

Done

> Section 3.3, last para: (why not MUST) Under what circumstances would an
> implementation not consider a message correctly signed?

This would be a significant protocol change, that falls out of the scope of implementing PQC.
Unfortunately, this behavior is left as an "exercise to the reader" in RFC 9580 and this is an interpretation of the requirements and the existing implementations.
For the sake of making the migration easier, we decided to make it explicit, but dictating the validation policy so that a packet distribution system may not require 2 different signatures to be valid seemed too hard.

> Section 3.4, para 1: It would be helpful to know what action an implementer
> should take in this case. A ref to a preexisting reference would be fine.

Added a note, I believe this is language and implementation specific

> Section 4.1.1.2, para 1, middle sentence: a typo? Should this be "R=X448(.."
> vice "R=25519(..."?

Good catch! Fixed.

> Section 4.2, second to last bullet: The session key is generated by the sender?

The generation of the session key is deferred to RFC 9580: it is usually generated by the sender, but there are cases for re-use.
We didn't want to open this Pandora vase. I added a note in the spec.

> Section 7.1: Please expand SEIPD on first use.

Done

> Section 9: Please add a section about ensuring that good quality random number
> generation is used (I believe at least one of the FIPS already referenced
> contains a section that can be referenced). In addition, if the session keys
> (used to encrypt the message content) are generated directly from a random
> source, please call that out specifically (or reference the base OpenPGP RFC
> 9580 Section 13.10).

RFC 9580 Section 13.10 requires this for all OpenPGP, and this is just an extension.
Added a note in the security considerations.

> Nit: public key or public-key, pick one and use it everywhere (I would choose
> public key). The same comment applies to other hyphenated phrases.

Done

Cheers,
Aron

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


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



On Sunday, 14 December 2025 at 12:56, Deb Cooley via Datatracker <[email protected]> wrote:

> Deb Cooley has entered the following ballot position for
> draft-ietf-openpgp-pqc-14: No Objection
> 

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

> 

> 

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

> Thanks to Brian Weis for their secdir review.
> 

> Section 1.4.2, second para: PKESK? please, spell out the first time.
> 

> Section 3.3, last para: (why not MUST) Under what circumstances would an
> implementation not consider a message correctly signed?
> 

> Section 3.4, para 1: It would be helpful to know what action an implementer
> should take in this case. A ref to a preexisting reference would be fine.
> 

> Section 4.1.1.2, para 1, middle sentence: a typo? Should this be "R=X448(.."
> vice "R=25519(..."?
> 

> Section 4.2, second to last bullet: The session key is generated by the sender?
> 

> Section 7.1: Please expand SEIPD on first use.
> 

> Section 9: Please add a section about ensuring that good quality random number
> generation is used (I believe at least one of the FIPS already referenced
> contains a section that can be referenced). In addition, if the session keys
> (used to encrypt the message content) are generated directly from a random
> source, please call that out specifically (or reference the base OpenPGP RFC
> 9580 Section 13.10).
> 

> Nit: public key or public-key, pick one and use it everywhere (I would choose
> public key). The same comment applies to other hyphenated phrases.
>

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