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
