Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Benjamin Kaduk <[e-mail]>]

Hi Rene,

On Wed, Feb 17, 2021 at 08:27:41PM -0500, Rene Struik wrote:
> Dear colleagues:
> 
> I uploaded v20 of this document. It is my sincere hope that this will 
> help in making swift progress.
> 
> Changes (compared to previous version v19):
> - removed the cose iana requests subsections, so as to avoid further 
> pollution of discussion of this document (which is long overdue to get out).

Is there WG consensus for this action?

Note that once the draft was adopted by the WG, change control passed to
the WG/the IETF, and your role becomes that of an editor, tasked with
realizing the consensus positions (even when they disagree with your own).
While you retain significant editorial latitude in editorial matters, I
would have expected that matters such as whether or not to request
allocation of IANA codepoints would be a consensus decision.

> [Excerpt email RS of Feb 16, 2021, 11.50am EST; see 
> https://mailarchive.ietf.org/arch/msg/lwip/9SH1J3OZoiwMZ8jx49OhOlZOtAg/ ]
> 
> The iana cose "bickering" is about the value of 6 one-word character strings, in an otherwise quite voluminous, since 137 pages, document, where the value could be "new" or "reuse existing" (i.e., at most six bits of entropy). The current iana cose request may not be perfect. If it requires improvement, I can write some text to accommodate this *in parallel* to the IESG review.

For the record, I dispute this characterization on several counts.

You say "bickering" where I see legitimate technical concerns that remain
unanswered.  (Yes, there was a statement made by one individual about
previous IANA review of the COSE registrations and that statement turned
out to be inaccurate.  I note that the statement in question was prefaced
with "to my undersanding" and the author of the statement was quick to
acknowledge the correction.)

I believe that the technical issues raised involve more than just the
character strings (that also correspond to integer values for the CBOR
encoding).  In addition to the topic of what class of semantics those
values are to convey, there was also a question raised relating to ECDSA on
Wei25519 and the need to truncate the hash function output to a number of
bits not divisible by 8.  In what review of the document I have done so far
I do note a fastidious (possibly excessively so) attention to bit-order of
encoding, but it is not clear to me that proper prominence has been given to
the need to pay attention to this concern as it relates to ECDSA over a
curve that requires truncation to a non-multiple of 8 bits, and whether the
behavior of the existing COSE ECDSA codepoints (which indicate specific
hash functions) has been fully specified in terms of the bits to select for
signature input.  I do not recall seeing technical discussion to indicate
that this issue has been closed (but I am only human, and would welcome a
pointer to where such discussion has occurred).

You say that you could write some text in parallel to the IESG review, but
this document is intended to be published on the IETF stream, and per RFC
8789 all documents on the IETF stream require IETF consensus.  I think it
is clear from the ongoing discussions on the COSE WG list that further
effort is needed to determine the consensus position on these proposed IANA
registrations, and thus that it is premature for the IESG to evaluate text
that is in flux and has undetermined consensus status.

Thank you,

Ben