[Lwip] Paul Wouters' No Objection on draft-ietf-lwig-curve-representations-23: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-lwig-curve-representations-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I fully support Roman's DISCUSS. I also agree with Lars, which is the
reason I'm balloting No Objection.

I feel the document is not telling the full story of the price to pay
for this code re-use effort.  After all, Section 10 and 12 is requesting
code points  JOSE / COSE, so this effort is not simply something that
is limited in scope to implementaton details. There is a price to
facilitate this.  The reason I am not objecting to the code points, is
that the registry defines a range for non-standard track "specification
required" entries. But I agree with Roman that these entries cannot have
"Recommended: Y".
   NOTE 2: At this point, it is unclear whether a FIPS-accredited module
   implementing the co-factor Diffie-Hellman scheme with, e.g., P-256
   would also extend this accreditation to the Montgomery versions
   X25519+ or X25519.  (For cryptographic module validation program
   guidance, see, e.g., [FIPS-140-2].)

This note should be re-evaluated as it is based on FIPS-140-2 which was
obsoleted by FIPS-140-3 about 4 years ago. If the note is still valid,
the reference should be updated.

   Note that storage would have reduced to a single 64-byte table if only the
   Curve25519 curve would have been generated so as to be isomorphic to
   a Weierstrass curve with hardcoded a=-3 parameter (this corresponds
   to l=1).

This feels like aimed at a discussion and/or implementer that is not in scope
for this document.

The Privacy Considerations text feels out of scope for this document.

Open IANA Expert issue:

Expert comments: OIDs have been approved. JOSE experts had approved
version 12, but new reviews are pending. A COSE expert writes that he
hasn't seen a detailed response to his February review and adds, "As I
remember the overall conclusion the COSE WG meeting Feb 17 confirmed
that registrations should follow current practice, and that, e.g.,
ES256K is an exception not to be followed."