Hello OAuth working group,
Daniel Bleichenbacher had written to me about incompatibilities he discovered
among implementations using secp256k1 signatures. See the forwarded thread
below.
His proposed text change is:
My proposal would be to clarify the valid range of R, and S E.g. in Section
3.2. "ECDSA Signature with secp256k1 Curve" step 1 one could extend
The output will be the pair (R, S), where R and S are 256-bit unsigned integers.
to
The output will be the pair (R, S), where R and S are 256-bit unsigned
integers, satisfying 0 < R < N and 0 < S < N, where N is the order of secp256k1.
if non-canonical signatures are OK, rsp.
The output will be the pair (R, S), where R and S are 256-bit unsigned
integers, satisfying 0 < R < N and 0 < S < N/2, where N is the order of
secp256k1.
if non-canonical signature should be rejected.
The document has not entered IETF last call yet, so and it's fair game to make
this addition. I had a conversation with Deb Cooley and Rifaat during
yesterday's OAuth office hours call and they supported bringing this
possibility to the working group.
Your feedback?
-- Mike
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Tuesday, June 16, 2026 7:15 AM
To: Michael Jones <[email protected]>
Subject: Re: RFC 8812
Hi Mike,
I certainly don't mind if you forward this to any working group or anywhere
else. I'd also participate in discussions if there are any.
I'm generating test vectors because I'm testing cryptographic libraries.
The test vectors are here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbleichenbacher-daniel%2FRooterberg&data=05%7C02%7C%7Ce2b24d3213c9492add7008decbb1b998%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639172161340428330%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AdXSxkAQN0LwYyjKtXC%2B9u4%2F4QXzx8F9hggGtvbtJHg%3D&reserved=0<https://github.com/bleichenbacher-daniel/Rooterberg>
One of the library I'm interested in is jwt_rustcrypto
(https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.rs%2Fjwt-rustcrypto%2Flatest%2Fjwt_rustcrypto%2F&data=05%7C02%7C%7Ce2b24d3213c9492add7008decbb1b998%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639172161340459290%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V%2FMoiagP2YVytNCXij4H20f%2BO06O2crfmOHA2BK9y2A%3D&reserved=0<https://docs.rs/jwt-rustcrypto/latest/jwt_rustcrypto/>).
Rust libraries have this strange property that even if one has tested a large
number of packages then one can still not be certain that next package behaves
the same or similar to all previous ones. E.g. that is the case here all curves
use ordinary ECDSA signatures, but secp256k1 uses canonical ones. I don't have
a specific use case for secp256k1. Though one topic of interest are key
confusion attacks between secp256r1 and secp256k1 as this could lead to leaked
keys.
Another topic of interest is signature malleability. JWT/JWS implementations
often do not have strict parsing and hence allow some modifications of the
tokens. It is unclear to me how serious such issues are.
Best,
Daniel
On Monday, June 15, 2026 at 07:52:27 PM GMT+2, Michael Jones
<[email protected]<mailto:[email protected]>> wrote:
Hi Daniel,
Are you willing to have me forward your thread to the OAuth working group,
where this work is happening? I just talked to one of the chairs and our area
director and they support doing this update to the draft.
I won't forward this to the list, but I'm curious what your use case is that
motivated you to create test vectors for signing with the k1 curve.
As long as we're talking, is there anything else that you believe we should be
adding to the recommendations in the draft for safe use of JOSE and JWTs?
Best wishes,
-- Mike
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Friday, June 12, 2026 6:48 AM
To: Michael Jones
<[email protected]<mailto:[email protected]>>
Subject: Re: RFC 8812
Hi Mike,
thanks for the reply.
I don't have any preference whether secp256k1 should require canonical
signatures or not. I simply noticed during testing that different
implementations do not agree on the generation and verification. Hence some
implementations generate non-canonical signatures, and others reject them hence
creating some incompatible cases.
Many implementations do not implement strict parsing hence preventing signature
malleability is difficult to achieve anyway.
Furthermore, since some implementations generate non-canonical signatures it
can be expected that future implementations accept non-canonical signatures as
a fallback for such implementations even if the RFC is changed to require
canonical signatures.
My proposal would be to clarify the valid range of R, and S E.g. in Section
3.2. "ECDSA Signature with secp256k1 Curve" step 1 one could extend
The output will be the pair (R, S), where R and S are 256-bit unsigned integers.
to
The output will be the pair (R, S), where R and S are 256-bit unsigned
integers, satisfying 0 < R < N and 0 < S < N, where N is the order of secp256k1.
if non-canonical signatures are OK, rsp.
The output will be the pair (R, S), where R and S are 256-bit unsigned
integers, satisfying 0 < R < N and 0 < S < N/2, where N is the order of
secp256k1.
if non-canonical signature should be rejected.
On Friday, June 12, 2026 at 03:04:32 AM GMT+2, Michael Jones
<[email protected]<mailto:[email protected]>> wrote:
Hi Daniel,
I just reviewed the specification, and you're right, it's silent on whether the
signatures need to be canonical or not.
As you probably know, RFCs can't be changed but they can be replaced or updated
by other RFCs.
If we want to suggest that signatures should be canonical, one place to do it
could be the pending JWT Best Current Practices update, which is
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-rfc8725bis%2F&data=05%7C02%7C%7Ce2b24d3213c9492add7008decbb1b998%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639172161340484263%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=I6w1wb1o4y3oR07vnRhHHB6x5hUOg%2FrQpWcAqDxL%2FLU%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-oauth-rfc8725bis/>.
It already includes guidance about other algorithms. Guidance could be added
about using secp256k1. That said, if we're going to do this, it would need to
be soon, because that spec has completed working group last call and is about
to go to IESG review. Are you interested in pursuing that path?
If so, do you have a proposed sentence or two to add?
Best wishes,
-- Mike
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Sunday, May 31, 2026 10:47 PM
To: [email protected]<mailto:[email protected]>
Subject: RFC 8812
Hi Michael,
I'm currently generating test vectors for RFC 8812. While doing so I noticed
that RFC 8812 does not specify, whether ES256K signatures need to be canonical
or not. I.e., protocols using secp256k1 often require that ECDSA signatures
(r,s) satisfy the restriction 0 < s < n/2, rather than 0 < s < n to avoid one
case of signature malleability.
While testing against existing JWT implementations, I noticed that some
libraries require 0 < s < n/2, while others don't. Hence, some clarification
which signatures are valid and which are not would be very helpful.
Best,
Daniel
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
