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

These look good.  TYVM.

Deb

On Mon, Dec 15, 2025 at 7:46 AM Aron Wussler <[email protected]> wrote:

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