JWS signature algorithms for RW
"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?
Comments (14)
-
-
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
andES256
as the algorithm for JWS signatures. Algorithmnone
andRS256
shall not be used." -
- changed status to open
-
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
andES256
the implementation is software only or the HSM supports them; - shall implement
RS256
if the HSM deployed does not supportPS256
orES256
; - shall not support
none
;
- shall implement
-
- changed milestone to R3 - Nov 2017
-
assigned issue to
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 supportES256
norPS256
is not simple. I need more time to carefully construct it.Perhaps I can put a note for the time being.
-
- shall implement
PS256
andES256
- shall not implement Digital Signature with RSASSA-PKCS1-v1_5
- shall not implement
none
- may implement other algorithms that are deemed more secure than
PS256
andES256
Dave is going to add a NOTE: as well to explain the context.
- shall implement
-
-
assigned issue to
-
assigned issue to
-
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.
-
Updates?
-
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 ashall
would make a lot of existing implementations non-compliant. -
- changed status to resolved
Merged in dgtonge/fapi/signature-algorithms-101 (pull request #67)
Fix
#101Signature algorithmsApproved-by: Joseph Heenan joseph@authlete.com Approved-by: Brian Campbell bcampbell@pingidentity.com Approved-by: Nat Sakimura sakimura@gmail.com
→ <<cset 5588c034a748>>
-
- changed component to Part 2: Advanced
-
- changed component to FAPI 1 – Part 2: Advanced
-
- changed component to FAPI 1: Advanced
- Log in to comment
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?