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

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]