[openpgp] Re: Ketan Talaulikar's Discuss on draft-ietf-ope npgp-pqc-14: (with DISCUSS and COMMENT)
Ketan Talaulikar <[email protected]> Sun, 14 Dec 2025 19:50:58 -0800
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <CAH6gdPx0Kd+kaLeLuh3zq7R4rtzj2y0EcWVWmd=ygAGSReYXYw@mail.gmail.com> |
Hi Stavros, Thanks for considering that suggestion. Thanks, Ketan On Fri, Dec 12, 2025 at 11:51 PM Stavros Kousidis <[email protected]> wrote: > 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]