JWS signature algorithms for RW

Issue #101 open
Takahiko Kawasaki
created an issue

"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 (7)

  1. 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?

  2. 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."

  3. 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;
  4. 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.

  5. 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.

  6. Log in to comment