Hi Ivylo:
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.
As an example, with [1], one would like to have "ES256fv"
(ECDSA/P-256/SHA-256 in fast-verify friendly way) in the "alg" field,
where currently batch verification and single verification speed-ups are
not possible. So, almost 17 years after this technique was introduced it
is about time to switch this on for those who (optionally) wish to get
~1.3x (single) to ~3x speed-ups (those who do not want to, can still
simply not use this but should not be spoke-in-the-wheelers for those
who do). This is just a single example (with JOSE); speed-ups apply
across the (universe) board, for all ECDSA deployments (passports, TLS,
SSH, etc.).
Ref: [1] https://spec.smarthealth.cards/#signing-health-cards
Each public key used to verify signatures is represented as a JSON Web
Key (seeRFC 7517 <https://tools.ietf.org/html/rfc7517>):
* SHALL have|"kty": "EC"|,|"use": "sig"|, and|"alg": "ES256"|
On 2021-11-07 10:38 a.m., 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
--
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
