JWS signature algorithms for RW

[Takahiko Kawasaki]

"8.6. JWS algorithm considerations" in Part 2 simply says "JWS signatures shall use the PS256 or ES256 algorithms for signing."

Are other algorithms in the same categories (to be exact, PS384, PS512, ES384 and ES512 which are found in "3.1. "alg" (Algorithm) Header Parameter Values for JWS" in RFC 7518) excluded intentionally? If not, why don't you modify the sentence slightly to imply other algorithms in the same categories are allowed?

[Dave Tonge]

I agree that this is unclear, surely we would also support the other algorithms that are in the same category. Also, what is the rationale for not supporting the RS* family of algorithms?

[Nat Sakimura]

From the interoperability point of view, it is good to have a limited set of algorithms to support. From that point of view, PS256 and ES256 seem to be good options given it provides adequate protection. We have ruled out RS256 because PKCS1-v1.5 is broken and insecure. (We knew that even when we were writing JWS but at the time the library support for PSS was limited so we opted for PKCS1-v1.5.) Algorithm 'none' is also ruled out for an obvious reason.

I am OK with re-phrasing it as "Implementations shall implement PS256 and ES256 as the algorithm for JWS signatures. Algorithm none and RS256 shall not be used."

[Nat Sakimura]

Just recording the result of more discussions. While the rationale for not supporting RS256 is cryptographically sound, in the cases where HSM only supports RS256, that can become pretty much the only option and it would still be better to use HSM than just being software based.

So, the WG precipitated to the following conclusion.

• shall implement PS256 and ES256 the implementation is software only or the HSM supports them;
• shall implement RS256 if the HSM deployed does not support PS256 or ES256;
• shall not support none;

[Nat Sakimura]

I am postponing the resolution of this ticket to R3.

Constructing a correct language to permit RS256 only in the case of the using HSM that does not support ES256 nor PS256 is not simple. I need more time to carefully construct it.

Perhaps I can put a note for the time being.

[Nat Sakimura]

1. shall implement PS256 and ES256
2. shall not implement Digital Signature with RSASSA-PKCS1-v1_5
3. shall not implement none
4. may implement other algorithms that are deemed more secure than PS256 and ES256

Dave is going to add a NOTE: as well to explain the context.

[Dave Tonge]

we need to pick this up - I'll see if i can get to it this before the next meeting. PS256 support is lacking across many jwt libraries.

[Nat Sakimura]

Updates?

[Dave Tonge]

I've made a pull request: https://bitbucket.org/openid/fapi/pull-requests/67/signature-algorithms-101/diff

I changed shall not implement Digital Signature with RSASSA-PKCS1-v1_5 to should - we can discuss on the call, but I felt that having it as a shall would make a lot of existing implementations non-compliant.

[Nat Sakimura]

Merged in dgtonge/fapi/signature-algorithms-101 (pull request #67)

Fix #101 Signature algorithms

Approved-by: Joseph Heenan [e-mail] Approved-by: Brian Campbell [e-mail] Approved-by: Nat Sakimura [e-mail]

→ <<cset 5588c034a748>>