Hi Rene, While you may be an experienced enough cryptographer to be comfortable asserting that there is "no new crypto" in these procedures, I contend that being able to make that assessment does actually require some cryptographic knowledge. In particular, the question is not just that (r,s) and (r,-s) are either both valid solutions to the ECDSA signing equation or both not solutions; rather, it is whether making use of this property has any interaction with the ECDSA assumptions that must be taken into account for use in a protocol scenario. While the fact that it is a transform solely on public data suggests that there should not be any risk, I, for one, am not willing to risk the reputation of the IETF on just my own personal analysis of this case.
Furthermore, for a WG-consensus decision we never rely on just one individual's analysis and review, and I lack confidence that the COSE WG has sufficient cryptographic expertise to form a consensus assessment that aligns with your individual assessment. Likewise, the SECDISPATCH session at IETF 111 produced a conclusion that the IETF security area as a whole is unlikely to have that expertise, and suggested that CFRG would be an appropriate place to reach a consensus conclusion in an open and public forum that these techniques do not require any special handling in order to be safely used in protocols designed to use regular ECDSA. Is there anything blocking you from raising this question at the CFRG yourself? If it's just a matter of how to frame the question that is believed to be relevant for IETF usage of the technique, I think we can assist with that. The previous publication at SAC would, of course, be a useful input for the CFRG discussion (are there more specific links/references available?), though the IETF-78 presentation may be less so -- lots of things can get presented at an IETF session, including those which end up being a bad idea. Finally, in your follow-up you also note: > As to your question "what will be the purpose of the presentation?", the > answer is that one would like to have a simple code point to facilitate > fast verification, both in single- and batch-settings. If the goal is solely to have *a* codepoint, there does not seem to be a need to involve the WG at all, at least initially. It appears that the relevant IANA registries have ranges available for allocation based solely on the "Expert Review" procedure, which is something you can request directly from IANA without any IETF WG involvement. There may be other reasons to present to the WG, such as gaining visibility of the technique to the broader community, getting a codepoint from the "standards action" ranges, etc., but just having a codepoint does not require a presentation to the WG. Thanks, Ben On Sun, Nov 07, 2021 at 10:38:22AM -0500, Rene Struik wrote: > Hi Ivaylo: > > I do not understand what the role of the CFRG is with this: should they > confirm that if (r,s) is a valid ECDSA signature for message m with > signing key Q, then so is (r,-s)? Or, is there more to this? > > FYI - the ECDSA signing equation is e:=h(m)=s*k-d*r (mod n), where > r:=x(R) (mod n), R:=k*G, Q:=d*G, so r=x(R)=x(-R) and e=s*k-d*r (mod n) = > (-s)*(-k) - d*r (mod n). QED. > > Is the idea to have this one-line verification being blessed by someone > from CFRG (which I consider myself also part of), Scott Fluhrer or > anyone who can do modular arithmetic could do this one-line check. As I > already indicated in my email of July 27, 2021 [2], > > As already indicated in the email below (July 21st), the draft does not > contain new crypto and only uses a public and reversible (r,s) to (r,-s) > signature transformation, if need be. This should therefore allow for a very > quick start-to-finish project, where enabling this simply depends on defining > code points or another unique cross-reference and getting this out of the > door. > > This was published in the peer-reviewed SAC 2005 conference, used in SAC > 2010 again, presented at IETF-78 (July 2010, i.e., 11 years ago!), > presented at NIST in 2009 [1]. What more does one need? > > I think the time is there to move forward on this extremely simple > suggestion and get this done. IETF should be able to move fast if there > is no reason to let things linger forever. > > Rene > > > Ref: [1] > https://csrc.nist.gov/csrc/media/events/cryptographic-key-management-workshop-2009/documents/rene_struik_kmwjune09_5min.pdf > [2] > https://mailarchive.ietf.org/arch/msg/secdispatch/FXnznttsnNvlYcu_PX70itFJO_A/ > > On 2021-11-06 6:13 p.m., Ivaylo Petrov wrote: > > Hello Rene, > > > > Thank you for your email! It was brought to my attention that during > > IETF 111 secdispatch > > (https://datatracker.ietf.org/meeting/111/materials/minutes-111-secdispatch-00) > > > > it was decided no code points to be assigned before the CFRG reviews > > the document. Could you clarify if that has already concluded and if > > not, what will be the purpose of the presentation? > > > > Thanks, > > Ivaylo > > > > > > *Ivaylo Petrov* > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > > privileged material for the sole use of the intended recipient(s). > > > > It is strictly forbidden to share any part of this message with any > > third party, without the written consent of the sender. > > > > If you have received this message by mistake, please notify the sender > > immediately by email and delete the message and any file attached to > > it. Thank you! > > > > > > > > On Fri, Nov 5, 2021 at 7:03 PM Rene Struik <[email protected]> wrote: > > > > Dear Ivaylo: > > > > I would like to ask for a presentation slot for the COSE/JOSE > > meeting Wednesday next week. > > > > Title: code points for fast-verification friendly ECDSA > > Presenter: Rene Struik > > > > For context, please see my email of Tue Nov 2, 2021 below. > > > > Best regards, Rene > > > > On 2021-11-02 12:36 p.m., Rene Struik wrote: > >> Dear Ivaylo: > >> > >> I presented a mechanism for putting ECDSA signatures into a > >> format that facilitates verification speed-ups, both in > >> single-verify and batch verification settings [1]. While this > >> technique (known for more than 1 1/2 decades) is generally > >> applicable, I believe this would be especially useful to > >> implement with JOSE and perhaps COSE right now, given > >> Covid-vaccination records using ES256 in the smart healthcard > >> specifications [3] (proposed with IATA, etc.). For the main idea, > >> see [1]. For a JSON Web signature example, see [2]. > >> > >> Do you think I could briefly present? I would like to ask for a > >> code point for JOSE and others down the road. > >> > >> I think I could simply present the example of [2] and some > >> applications. > >> > >> Best regards, Rene > >> > >> ref: [1] > >> > >> https://datatracker.ietf.org/doc/html/draft-struik-secdispatch-verify-friendly-ecdsa-00#section-9.3 > >> > >> [2]https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-22#appendix-Q.3.4 > >> > >> [3]https://smarthealth.cards/ > >> > >> On 2021-10-31 10:06 a.m., Ivaylo Petrov wrote: > >>> Hello all, > >>> > >>> This is a call for agenda items for our session at IETF 112. > >>> Please > >>> send them to the chairs and/or this list. > >>> > >>> We have a slot for Wednesday, November 10, 2021 Session II > >>> (14:30-15:30 UTC). > >>> > >>> Thank you, > >>> > >>> -- > >>> COSE WG Chairs > >>> Matthew, Mike and Ivaylo > >>> > >>> _______________________________________________ > >>> COSE mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/cose > >> > >> > > > > -- > > 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 > > > > -- > 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
