Re: [COSE] draft-ietf-lwig-curve-representations-13

[Rene Struik <[e-mail]>]

Questions/point of information:
a) where is the distinct step for "someone making a registration request 
of iana" described?
b) which algorithms for which I requested iana cose code points do not 
meet the security requirements?
c) which message structure requirements for said requested code points 
are not met?

{here, message structure refers to syntax, whereas security also deals 
with robust security properties}


On 2021-02-15 2:17 p.m., Benjamin Kaduk wrote:
> 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 <[e-mail]>
>>>> *Date: *Sunday, 14 February 2021 at 20:11
>>>> *To: *John Mattsson <[e-mail]>, Göran Selander
>>>> <goran.selander=[e-mail]>, "[e-mail]"
>>>> <[e-mail]>, "[e-mail]" <[e-mail]>
>>>> *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 <[e-mail]>
>>>>          <mailto:[e-mail]>
>>>>          *Date: *Wednesday, 13 January 2021 at 15:26
>>>>          *To: *John Mattsson <[e-mail]>
>>>>          <mailto:[e-mail]>, Göran Selander
>>>>          <goran.selander=[e-mail]>
>>>>          <mailto:goran.selander=[e-mail]>,
>>>>          "[e-mail]" <mailto:[e-mail]> <[e-mail]>
>>>>          <mailto:[e-mail]>, "[e-mail]"
>>>>          <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>>>>          *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 <[e-mail]>
>>>>                  <mailto:[e-mail]> on behalf of Rene
>>>>                  Struik <[e-mail]>
>>>>                  <mailto:[e-mail]>
>>>>                  *Date: *Friday, 6 November 2020 at 20:37
>>>>                  *To: *Göran Selander
>>>>                  <goran.selander=[e-mail]>
>>>>                  <mailto:goran.selander=[e-mail]>,
>>>>                  "[e-mail]" <mailto:[e-mail]>
>>>>                  <[e-mail]> <mailto:[e-mail]>,
>>>>                  "[e-mail]" <mailto:[e-mail]>
>>>>                  <[e-mail]> <mailto:[e-mail]>
>>>>                  *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
>>>>
>>>>                      [e-mail]  <mailto:[e-mail]>
>>>>
>>>>                      https://www.ietf.org/mailman/listinfo/cose  <https://www.ietf.org/mailman/listinfo/cose>
>>>>
>>>>                  --
>>>>
>>>>                  email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>>>
>>>>                  cell: [phone] | US: [phone]
>>>>
>>>>                  -->
>>>>
>>>>              --
>>>>
>>>>              email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>>>
>>>>              cell: [phone] | US: [phone]
>>>>
>>>>          --
>>>>
>>>>          email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>>>
>>>>          cell: [phone] | US: [phone]
>>>>
>>>>      --
>>>>
>>>>      email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>>>
>>>>      cell: [phone] | US: [phone]
>>>>
>>>> -- 
>>>> email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>>>> cell: [phone] | US: [phone]
>>>
>>> -- 
>>> email:[e-mail]  | Skype: rstruik
>>> cell: [phone] | US: [phone]
>>
>> -- 
>> email: [e-mail] | Skype: rstruik
>> cell: [phone] | US: [phone]
>>
>> _______________________________________________
>> COSE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cose


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]