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

Stephen Farrell <[email protected]> Fri, 12 Dec 2025 11:24:34 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
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]
OpenPGP_signature.asc (application/pgp-signature, 236 B)