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

Dear Ketan,

we will handle your suggestions here: 
https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/255

Best
Stavros

On 12/13/25 01:58, Ketan Talaulikar wrote:
> Stephen. Thanks for the discussion on the nature of changes and their 
> relation to the base RFC9580.
>
> Authors/WG, I would suggest that the following sentence be added at 
> the end of the Abstract and the Introduction to clarify this.
>
> "It does not change the base OpenPGP protocol as specified in 
> RFC9580." OR " This does not change the base OpenPGP protocol as 
> specified in RFC9580."
>
> The other option is to remove the "updates" RFC9580 metadata tag from 
> the document since this is an extension and not really changing the 
> base. That said, I realize that the "update" metadata tag is not used 
> consistently across the IETF [1] and so there is the suggested text above.
>
> Thanks,
> Ketan
>
> [1] For more context please see 
> https://datatracker.ietf.org/doc/draft-kuehlewind-rswg-updates-tag/
>
>
> On Fri, Dec 12, 2025 at 3:24 AM Stephen Farrell 
> <[email protected]> wrote:
>
>
>     Hiya,
>
>     On 11/12/2025 22:33, Ketan Talaulikar wrote:
>     > Hi Stephen,
>     >
>     > Please check inline below for KT.
>     >
>     > On Thu, Dec 11, 2025 at 1:15 PM Stephen Farrell
>     <[email protected]>
>     > wrote:
>     >
>     >>
>     >> Hiya,
>     >>
>     >> On 11/12/2025 19:08, Ketan Talaulikar via Datatracker wrote:
>     >>>
>     ----------------------------------------------------------------------
>     >>> DISCUSS:
>     >>>
>     ----------------------------------------------------------------------
>     >>>
>     >>> Thanks to the authors and the WG for their work on this document.
>     >>>
>     >>> I have one aspect of this document that I would like to
>     discuss. The
>     >> document
>     >>> is updating RFC9580, but is not specifying what is it that is it
>     >> modifying in
>     >>> that base OpenPGP spec. Is the introduction of new
>     algorithms/codepoints
>     >> and
>     >>> the use of composite/hybrid approach for KEM and certificates an
>     >> extension of
>     >>> OpenPGP or is updating (as in say fixing or changing the
>     working) of
>     >> OpenPGP?
>     >>> My impression (and I could be wrong) is that this is an
>     extension to
>     >> OpenPGP?
>     >>
>     >> This just adds new algorithms, using the planned extensibility
>     >> mechanism, which is an extremely common one for pretty much all
>     >> cryptographic protocols.
>     >>
>     >
>     > KT> So, this is an extension but it does not change the base
>     protocol spec?
>
>     Yes.
>
>     > Does the WG normally mark documents bringing in any new
>     algorithms with the
>     > "updates" tag on the base protocol spec?
>
>     Both have happened (for RFC4880). RFC5881 updated RFC4880 but the
>     more important RFC6637 did not. The sky didn't fall due to the IETF's
>     inconsistency, and you'll consistently find the same inconsistency
>     across lots of IETF protocols:-)
>
>     Having an 'udpates' is unimportant here, nobody who's implementing
>     either 9580 or this won't have heard of the other.
>     >>> In either case, a short summary or description of what is
>     being updated
>     >> in or
>     >>> done differently than what is in RFC9850 in the abstract and
>     >> introduction would
>     >>> help clarify for readers and address this discussion point.
>     >>
>     >> I'm not sure that's really needed - an implementer who is going
>     >> to make use of this spec will definitely not need that level of
>     >> introductory material.
>     >>
>     >
>     > KT> If a document is saying that it "updates" a base spec, I am
>     hoping that
>     > the WG wants to describe (even if briefly) what exactly is
>     changing the
>     > base spec?
>
>     That is described; no more text is needed, people understand how to
>     add ciphers to protocols already.
>
>     > Let's say I am not interested in this specific extension (and,
>     > so you don't get me wrong, I am not questioning the need for or
>     importance
>     > of PQC), the "updates" tag makes me wonder if there is something
>     broken in
>     > the base is being fixed or some strongly recommended base
>     improvement is
>     > being introduced. If so, I might want to jump on those even if
>     I'm not
>     > interested in the new functionality. Do you see a problem with
>     clarifying?
>     > Are you ruling out the possibility that this spec is read by
>     someone other
>     > than an implementer? Perhaps someone that is evaluating what
>     features of
>     > OpenPGP they might need/desire (say as a user)?
>
>     None of the above raises to a discuss-worthy point.
>
>     >> I'm also uncertain as to how this discuss matches the discuss
>     >> criteria. [1] Can you explain? (ISTM, the ask here is pretty
>     >> close to a bullet in section 3.2 of [1]: "The motivation for
>     >> a particular feature of a protocol is not clear enough. At the
>     >> IESG review stage, protocols should not be blocked because they
>     >> provide capabilities beyond what seems necessary to acquit their
>     >> responsibilities."
>     >>
>     >> But maybe I'm missing something here?
>     >>
>     >
>     > KT> It appears to me that you might be missing some things. I
>     would point
>     > out this IESG statement -
>     >
>     https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/
>     > - it might help clarify, especially since you got the impression
>     that I was
>     > blocking this specification despite my having provided
>     suggestions to
>     > address the discussion point.
>
>     You *are* blocking this specification at present. And on a basis that
>     I consider doesn't conform to the IESG's own DISCUSS criteria.
>
>     I am familiar with IESG ballot handling.
>
>     > KT> Regarding your question on the specific item on the list in
>     the IESG
>     > statement on DISCUSS criteria. I will draw your attention to -
>     "This cannot
>     > be an exhaustive list, but this set should be taken as exemplary
>     of the
>     > common causes for DISCUSSes seen by the IESG in the past." - and in
>     > case, if my responses above still leave any doubts, I am looking for
>     > clarity. That is somewhere on the lines of the second bullet in
>     terms of
>     > clarity in the sense of "am I missing the change/update in the
>     base spec?"
>
>     My opinion that your points do not meet the DISCUSS criteria is
>     unchanged;-)
>
>     Cheers,
>     S.
>
>     >
>     > Thanks,
>     > Ketan
>     >
>     >
>     >>
>     >> Thanks,
>     >> S.
>     >>
>     >> [1]
>     >>
>     >>
>     https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/
>     >>
>     >>>
>     >>>
>     >>>
>     ----------------------------------------------------------------------
>     >>> COMMENT:
>     >>>
>     ----------------------------------------------------------------------
>     >>>
>     >>>
>     >>> I have just one nit to bring to your attention. I believe the
>     correct
>     >> term is
>     >>> "public key" and not "public-key". This is the case even in
>     the base
>     >> RFC9850
>     >>> that is being updated.
>     >>>
>     >>>
>     >>>
>     >>
>     >>
>     >
>

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