Hi Rene,
Section 16.11 discusses what the IANA Designated Experts should do upon
receipt of a registration request, which is a distinct step from what
someone making a registration request of IANA should do.
I further note that the final bullet of the section says that "Algorithms
that do not meet the security requirements of the community and the
messages structures should not be registered"; it seems natural to me that
a Designated Expert would choose to consult the COSE WG email list in order
to get feedback from the community.
-Ben
On Mon, Feb 15, 2021 at 02:13:15PM -0500, Rene Struik wrote:
> Hi John:
>
> I would be eager to have an answer to the question I posed earlier:
>
> /I could not find the procedure you seemingly had in mind below in
> RFC 8152 (a search in RFC 8152 on the term "email" also did not
> yield this info). Isn't this all described in Section 16.11 [1]? If
> you could point me to what I am apparently missing, please let me know!/
>
>
> Since you seem to know much more about IETF processes than I do, any
> timely help much appreciated! {I am sure it would also help others more
> verses into technical matters than procedural questions.}
>
> Best regards, Rene
>
> On 2021-02-14 4:56 p.m., Rene Struik wrote:
> > Hi John:
> >
> > To my knowledge, I followed the steps described in Section 16.11 [1]
> > (Expert Review Instructions), already in April 2019 (almost 2 years ago):
> >
> > 16.11. Expert Review Instructions
> > All of the IANA registries established in this document are
> > defined as expert review. This section gives some general
> > guidelines forwhat the experts should be looking for, but they are
> > being designated as experts for a reason, so they should be given
> > substantial latitude.
> >
> > Expert reviewers should take into consideration the following points:
> >
> > [snip (enumeration of four aspects to consider)]
> >
> > I could not find the procedure you seemingly had in mind below in RFC
> > 8152 (a search in RFC 8152 on the term "email" also did not yield this
> > info). Isn't this all described in Section 16.11 [1]? If you could
> > point me to what I am apparently missing, please let me know!
> >
> > In all fairness, I think you would have to agree that I did reach out
> > to the relevant actors at the time, in good conscience, in a timely
> > manner (in contrast to the language you used in your forelast email).
> >
> > Best regards, Rene
> >
> > Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11
> >
> > On 2021-02-14 4:08 p.m., John Mattsson wrote:
> >>
> >> Hi Rene,
> >>
> >> True, Jim used to be one the experts. My comment that you did not
> >> talk to any of the experts is not true.
> >>
> >> The only IANA history I know of started on 6 Nov 2020 when Göran (one
> >> of the experts) followed the procedure and sent a mail to the COSE
> >> mailing list commenting and asking about the COSE registrations. I
> >> and several other people in COSE WG seem to share Göran’s concerns.
> >> You cannot expect COSE WG to read your draft before somebody send it
> >> to the list. If I had written the draft I would personally had sent
> >> in to COSE a long time ago. I wish someone would have helped you with
> >> that.
> >>
> >> You need to ask Göran and the other two experts on the status but to
> >> me it seems like the COSE WG is aligning on the technical aspects of
> >> the IANA registrations:
> >>
> >> https://mailarchive.ietf.org/arch/browse/cose/?gbt=1&index=IEx4C67-IGkQ9BpI8DUFxhElcwA
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> *From: *Rene Struik <[email protected]>
> >> *Date: *Sunday, 14 February 2021 at 20:11
> >> *To: *John Mattsson <[email protected]>, Göran Selander
> >> <[email protected]>, "[email protected]"
> >> <[email protected]>, "[email protected]" <[email protected]>
> >> *Subject: *(small timeline correction) Re: [COSE]
> >> draft-ietf-lwig-curve-representations-13
> >>
> >> Correction: LWIG WGLC was in August 2019 and not August 2020, as I
> >> mistakenly put in my previous note (i.e., already 18 1/2 months or
> >> more than 1 1/2 years ago).
> >>
> >> See
> >> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/
> >>
> >> <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/history/>
> >>
> >> On 2021-02-14 2:04 p.m., Rene Struik wrote:
> >>
> >> Hi John:
> >>
> >> I did have a brief look at my past correspondence on iana-cose
> >> code points, where I discussed this with Jim Schaad (designated
> >> iana cose expert over the relevant time period):
> >>
> >> - email correspondences {March 27, 2019; April 12, 2019; April
> >> 15, 2019};
> >>
> >> - f/u. discussions w/ Jim Schaad (triggered by trying to help out
> >> Pascal Thubert on his ap-nd Editor queue draft): phone call {Thu
> >> March 16, 2020}; email correspondence {April 6/7/22/25, 2020}
> >>
> >> History of iana sections in curve-draft document:
> >>
> >> - iana/cose section has been in there since April 14, 2019 (v04
> >> of the draft). See
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/
> >>
> >> <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/04/>
> >>
> >> - WGLC LWIG group: August 6, 2019;
> >>
> >> - IETF Last-Call: August 24, 2020 (two-week);
> >>
> >> - your comment: Nov 9, 2020
> >>
> >> - your (nontechnical) email below: today, Feb 14, 2021 (32 days
> >> after my last email to the list).
> >>
> >> Contrary to what you seem to suggest below, my records above
> >> indicate I have reached out to the relevant people already almost
> >> two (!) years ago, in good conscience (where email and phone
> >> conversations with Jim Schaad were productive, with 1-2 days
> >> feedback loop). I have trouble understanding why during all this
> >> time the technical points you seem to take issue with have not
> >> been narrowed down (as I repeatedly suggested offline and which
> >> is good engineering practice). Please note that even something as
> >> simple an uncontroversial as registering Wei25519 and Wei448 has
> >> not been stricken off the list since the November 2020 note. I
> >> think one should reflect why this (in an Internet *Engineering*
> >> Task Force).
> >>
> >> Best regards, Rene
> >>
> >> On 2021-02-14 3:13 a.m., John Mattsson wrote:
> >>
> >> Hi Rene,
> >>
> >> >I value your feedback, even though you brought up your points
> >> more than two months after the
> >>
> >> >IETF Last-Call.
> >>
> >> All the comments has been purely regarding the IANA
> >> registrations for COSE. To my understanding you did not
> >> discuss these registrations with the dedicated IANA experts
> >> or the COSE WG beforehand. The suggested COSE registration
> >> are quite strange. Any delay is purely due to you not
> >> discussing and anchoring these registrations. I have
> >> suggested that that this issue is discussed at the interim on
> >> Tuesday, but it is not my job to drive your registrations. I
> >> am just commenting on the questions from the dedicated IANA
> >> experts.
> >>
> >> You can always remove the COSE registrations, but I think
> >> that would be sad. I agree with you that a registration for
> >> Wei25519 is good to have. Another alternative is to move the
> >> registration to a separate draft.
> >>
> >> >I uploaded a new version of the lwig curve draft [1], changing the
> >> intended status to "standards track". I hope
> >>
> >> >this helps.
> >>
> >> You cannot just change the status from “informational” to
> >> “standards track”. They are very different things.
> >> Informational is just general information, while standards
> >> track means IETF consensus and recommendation. Changing the
> >> status would (I assume) require wg consensus and then redoing
> >> the last calls.
> >>
> >> /John
> >>
> >> *From: *Rene Struik <[email protected]>
> >> <mailto:[email protected]>
> >> *Date: *Wednesday, 13 January 2021 at 15:26
> >> *To: *John Mattsson <[email protected]>
> >> <mailto:[email protected]>, Göran Selander
> >> <[email protected]>
> >> <mailto:[email protected]>,
> >> "[email protected]" <mailto:[email protected]> <[email protected]>
> >> <mailto:[email protected]>, "[email protected]"
> >> <mailto:[email protected]> <[email protected]> <mailto:[email protected]>
> >> *Subject: *Re: [COSE] draft-ietf-lwig-curve-representations-13
> >>
> >> Hi Goran, John:
> >>
> >> Please let me know if my response to the COSE mailing list
> >> (Dec 19th) works for you. If you have comments, please
> >> suggest constructive improvements.
> >>
> >> I really would like to get closure on this.
> >>
> >> I value your feedback, even though you brought up your points
> >> more than two months after the IETF Last-Call. I hope we can
> >> move forward without undue delays.
> >>
> >> Thanks for your help, Rene
> >>
> >> On 2020-12-19 11:01 a.m., Rene Struik wrote:
> >>
> >> Dear John:
> >>
> >> Based on your review and other feedback received, I
> >> slightly updated the draft and posted the latest revision
> >> as [1].
> >>
> >> Your review below (of Nov 6, 2020) seems to bring up
> >> three topics, viz.: (1) definition of Wei25519 and Wei448
> >> vs. verbiage in NIST docs; (2) need for iana
> >> registrations for ECDSA25519 and ECDSA448; (3) need for
> >> iana registrations ECDH25519 and ECDH448.
> >>
> >> Please find below some feedback.
> >>
> >> General feedback:
> >>
> >> Please bear in mind that the specifications of ECDSA25519
> >> and ECDH25519 in the lwig curve document aim to yield
> >> schemes that are strictly NIST-compliant (i.e., these
> >> would allow FIPS 140-2 accreditation if the curves would
> >> be in the "NIST recommended" set). See also Note 2 of
> >> Section 4.1 of [1]. A similar remark applies to ECDSA448
> >> and ECDH448.
> >>
> >> Detailed feedback:
> >>
> >> (1) Definition of Wei25519 and Wei448 vs. verbiage in
> >> NIST docs.
> >>
> >> Draft NIST SP 800-186 indeed defines a short-Weierstrass
> >> version of Curve25519 [dubbed W-25519] and FIPS 186-5
> >> allows its use; similar for Curve448 [dubbed W-448
> >> there]). I have now added references to these draft
> >> specifications in the lwig-curve draft. I have
> >> double-checked all domain parameters, mappings between
> >> curve models, tables of isogeny details in the lwig draft
> >> and provided Sage scripts for the CFRG crypto panel
> >> review at the time. I do anticipate that NIST will arrive
> >> at the same values in their final publication when they
> >> decide to publish this. (I am happy to share Sage scripts
> >> for this purpose.)
> >>
> >> (2) Need for iana registrations for ECDSA25519 and ECDSA448.
> >>
> >> ECDSA is determined by an instantiation of hash function,
> >> curves, and representation conventions for inputs and
> >> outputs (i.e., message representation, curve point
> >> representation, and signature representation).
> >> a) ECDSA448 uses SHAKE256 under the hood, which is
> >> currently not defined with COSE. Hence, my request to
> >> register ECDSA w/ SHAKE256 and Wei448 as "ECDSA448".
> >> b) ECSA25519 uses SHA256 and Wei25519 under the hood. I
> >> thought to request to register "ECDSA25519" since this
> >> would allow referencing the quite careful write-up
> >> (Section 4.3), including bit/byte ordering, checks, and
> >> nondeterministic behavior (and, thereby, keeping this
> >> concise). Please note that this is very similar to the
> >> COSE IANA registry for "ES256k1" (ECDSA w/ SHA256 and
> >> Bitcoin curve secp256k1).
> >>
> >> (3) Need for iana registrations ECDH25519 and ECDH448.
> >>
> >> ECDH25519 and ECDH448 are co-factor Diffie-Hellman key
> >> establishment schemes and can, therefore, not be based on
> >> (cofactorless) Diffie-Hellman, as defined in RFC 8152.
> >> (Please note that there is no difference for the NIST
> >> curves, which all of co-factor h=1, but in our case one
> >> has h=8 and h=4, respectively). Here, one should note
> >> that the ECDH25519 and ECDH448 write-ups (Section 4.1 and
> >> 4.3) quite carefully cross-reference co-factor ECDH in a
> >> NIST-compliant way. Apart from the co-factor ECDH vs.
> >> ECDH issue and objective to comply with all strict NIST
> >> validation checks, the objective was also to make sure
> >> that ECDH25519 and ECDH448 can be used in settings where
> >> either or both parties uses ephemeral keys (which is more
> >> flexible than what RFC 8152 allows). Hence, the request
> >> to register "ECDH25519" and "ECDH448", to make sure this
> >> covers the intent of these schemes accurately and with
> >> precise description.
> >>
> >> It is possible that I overlooked something in this
> >> assessment. If so, any constructive suggestions are welcome.
> >>
> >> Ref: [1]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-19>
> >>
> >> Best regards, Rene
> >>
> >> On 2020-11-06 5:04 p.m., John Mattsson wrote:
> >>
> >> Hi,
> >>
> >> I looked through this draft again. I think it is a
> >> very good draft and I think it will be a solution to
> >> some of the problems IoT devices have with Ed25519. I
> >> will bring up this draft for discussion in the LAKE
> >> WG at IETF 109.
> >>
> >> I find it strange that the IANA registration has not
> >> been coordinated with COSE WG at all. I am a bit
> >> surprised to see IANA registrations for
> >> COSE/JOSE/PKIX/CMS at all in a LWIG draft (is that in
> >> charter?). If LWIG wants to register new algorithms,
> >> I think LWIG at a minimum should coordinate with COSE
> >> WG and other groups. I think this draft should be
> >> presented at the next COSE WG meeting.
> >>
> >> I support registration of W-25519 and W-448 curves as
> >> long they agree with NIST. I would like answers to
> >> the questions why ECDSA25519 and ECDH25519 are needed
> >> at all. There is no ECDSAP256 and no ECDHP256, so why
> >> are specific algorithm registration needed for
> >> W-25519? It makes no sense to me that a special
> >> signature registration is needed for COSE but not for
> >> PKIX? If PKIX can use ecdsa-with-SHA256 why cannot
> >> COSE use ES256?
> >>
> >> I don't think ANSI X9.62 is an acceptable normative
> >> reference. NIST just removed the normative reference
> >> to ANSI X9.62 in SP 186-5.
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> *From: *COSE <[email protected]>
> >> <mailto:[email protected]> on behalf of Rene
> >> Struik <[email protected]>
> >> <mailto:[email protected]>
> >> *Date: *Friday, 6 November 2020 at 20:37
> >> *To: *Göran Selander
> >> <[email protected]>
> >> <mailto:[email protected]>,
> >> "[email protected]" <mailto:[email protected]>
> >> <[email protected]> <mailto:[email protected]>,
> >> "[email protected]" <mailto:[email protected]>
> >> <[email protected]> <mailto:[email protected]>
> >> *Subject: *Re: [COSE]
> >> draft-ietf-lwig-curve-representations-13
> >>
> >> Hi Goran:
> >>
> >> Please find below some brief feedback on your note:
> >>
> >> - the naming wei25519 has been around since the first
> >> draft (Nov 13, 2017, i.e., 3 years minus 1 week ago),
> >> see [1]. NIST indeed produced two draft documents,
> >> viz. Draft NIST SP 800-186 and Draft FIPS Pub 186-5
> >> (on October 31, 2019), which generated lots of (to my
> >> knowledge still unresolved) comments during public
> >> review. It is hard to refer to that document, since
> >> it is only a draft and unfortunately has quite a few
> >> errors.
> >>
> >> - earlier versions of the lwig draft have received
> >> reviews by the crypto review panel (Stanislavslav
> >> Smyshlyaev), iotdir early-review (Daniel Migault);
> >> the sections on COSE/JOSE code point assignments
> >> resulted from a phone call and various email
> >> exchanges with Jim Schaad; the section on PKIX/CMS
> >> was suggested during IETF Last-Call secdir-review
> >> (Russ Housley) and reviewed by him. The document had
> >> IETF Last-Call Aug 24, 2020. See, e.g., the status
> >> pages [1].
> >>
> >> - ECDSA has been around since 1999, has been widely
> >> standardized, and has seen lots of analysis, where
> >> ECDSA25519 is simply yet another instantiation.
> >> Signature generation and verification times for
> >> ECDSA25519 should be similar to those of Ed25519
> >> (since timing is dominated by scalar multiplication,
> >> where one could simply use Montgomery arithmetic
> >> [3]). In my personal view, ECDSA25519 may be more
> >> secure than Ed25519 (if only because it is
> >> non-deterministic, see Security section [6]); similar
> >> side-channel care has to be taken in either case.
> >>
> >> - As mentioned in the draft, one can easily switch
> >> between Wei25519 and Curve25519 (which requires a
> >> single field addition or subtraction only, i.e.,
> >> <.01%, see Appendix E.2 [7]). As mentioned in the
> >> draft, one could use Wei25519.-3 with an existing
> >> generic implementation that hardcodes the domain
> >> parameter a=-3, but needs to compute an isogeny and
> >> dual isogeny for this (adding 5-10% cost, see
> >> Appendix G.2 [8]]) and a ~9.5kB table (see Section
> >> 5.3 [4]). However, if one already has generic
> >> hardware support, one may still have a significant
> >> win (see Section 6 [5]).
> >>
> >> - The isogeny for Wei25519.-3 has odd degree l=47,
> >> which is co-prime with the order of the curve, so is
> >> in fact invertible. With Wei448.-3, the isogeny has
> >> degree l=2, so is not invertible; however, this does
> >> not really matter, since it is invertible with
> >> correctly generated public-private key pairs (which
> >> have prime/odd order) and the factor two is absorbed
> >> with co-factor ECDH, where h=4 then.
> >>
> >> I hope this helps.
> >>
> >> (*) For ease of tracking, it would help if iana
> >> related comments are flagged in the subject line
> >> (e.g., include (iana) in the beginning hereof).
> >>
> >> Best regards, Rene
> >>
> >> Ref with hyperlinks:
> >>
> >> [1]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00>
> >>
> >> [2]
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/
> >>
> >> <https://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representations/>
> >>
> >> [3]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3>
> >>
> >> [4]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-5.3>
> >>
> >> [5]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-6>
> >>
> >> [6]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-8>
> >>
> >> [7]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.2>
> >>
> >> [8]
> >>
> >> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2
> >>
> >> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-G.2>
> >>
> >> On 2020-11-06 11:19 a.m., Göran Selander wrote:
> >>
> >> Hi,
> >>
> >> Apologies for cross-posting LWIG and COSE. I had
> >> a brief look at
> >> draft-ietf-lwig-curve-representations-13 and
> >> noticed it registers a lot of new COSE(andJOSE,
> >> PKIX, and CMS) algorithms. Has this draft been
> >> discussed in COSE(JOSE/CURDLE)? If not, perhaps
> >> it should be before being progressed?
> >>
> >> 1.The draft needs to manage the overlap with NIST
> >> SP 800-186, which should be referenced and
> >> mappings, name of curves, etc. aligned. The draft
> >> defines Wei25519 and Wei448. It is unclear if
> >> these are identical to W-25519, W-448 as defined
> >> in NIST SP 800-186. We probably would not want
> >> two slightly different definitions and/or names,
> >> multiple COSE code points, etc.
> >>
> >> 1.The draft registers the COSE algorithm
> >> "ECDSA25519" as "ECDSA with SHA-256 and curve
> >> Wei25519". That is not how the other COSE
> >> signature algorithms work. They work like PKIX
> >> where the curve is given by the public key. Also,
> >> why cannot W-25519 be used with the existing
> >> ES256 signature algorithm?
> >>
> >> 2.The draft registers the COSE algorithm
> >> "ECDH25519". There are no COSE ECDH algorithms
> >> for P-256, why is anECDH algorithm for W-25519 be
> >> needed?
> >>
> >> Other questions. I may have missed it, but
> >>
> >> 2.is it described what are the expected security
> >> properties of ECDSA25519(including mapping)
> >> compared to Ed25519? For example w.r.t. side
> >> channel attacks?
> >>
> >> 3.has any performance measurements been made
> >> comparing ECDSA25519 (including mapping) and Ed25519?
> >>
> >> 4.similar questions on security and performance
> >> with Wei25519.-3 instead of Wei25519. If I
> >> understand right, the former mapping is not
> >> reversible, but could benefit from optimized code
> >> with hardcoded domain parameters.
> >>
> >> 5.ANSI X9.62-2005 was withdrawn in 2015 and is
> >> behind a paywall, is this reference necessary?
> >>
> >> Göran
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> COSE mailing list
> >>
> >> [email protected] <mailto:[email protected]>
> >>
> >> https://www.ietf.org/mailman/listinfo/cose
> >> <https://www.ietf.org/mailman/listinfo/cose>
> >>
> >> --
> >>
> >> email:[email protected]
> >> <mailto:[email protected]> | Skype: rstruik
> >>
> >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >>
> >> -->
> >>
> >> --
> >>
> >> email:[email protected] <mailto:[email protected]> |
> >> Skype: rstruik
> >>
> >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >>
> >> --
> >>
> >> email:[email protected] <mailto:[email protected]> |
> >> Skype: rstruik
> >>
> >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >>
> >> --
> >>
> >> email:[email protected] <mailto:[email protected]> | Skype:
> >> rstruik
> >>
> >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >>
> >> --
> >> email:[email protected] <mailto:[email protected]> | Skype:
> >> rstruik
> >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >
> >
> > --
> > email:[email protected] | Skype: rstruik
> > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
>
> --
> email: [email protected] | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
