Sec 10.6 and 10.7 of JWS also touch on algorithm substitution.

Allowing keys to be used with multiple algorithms is a general problem, and 
almost always turns out unhappily.

I think that using a RSA key for HMAC is the most extreme case of that 
principal.

I do think that outside of the JOSE and JWT specs we need more implementer 
guidance encouraging the use of "alg" and "use" in JWK 
as well as propagating that information into local key stores so that the wrong 
key is not selected.

The problem applications in question simply took the "iss" and or the "kid" and 
retuned a key without looking at the "alg".

A given issuer may be allowed to sign using both ECDSA and RSA PKCS 1.5 and 
that would not be a problem until one of them is deprecated.  
Having libraries assume that there can only be one alg per issuer would not 
lead to useful crypto agility in my experience.

John B.

> On Apr 2, 2015, at 3:42 PM, Mike Jones <[email protected]> wrote:
> 
> This warning is already in place in 
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-7.2.  
> It says:
> 
>   Finally, note that it is an application decision which algorithms may
>   be used in a given context.  Even if a JWT can be successfully
>   validated, unless the algorithm(s) used in the JWT are acceptable to
>   the application, it SHOULD reject the JWT.
> 
>                               -- Mike
> 
> -----Original Message-----
> From: OAuth [mailto:[email protected]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, April 02, 2015 11:28 AM
> To: Tim McLean
> Cc: [email protected]; [email protected]
> Subject: Re: [OAUTH-WG] [jose] Security research on JWT implementations
> 
> [[adding [email protected]]]
> 
> On 04/02/2015 08:01 PM, Tim McLean wrote:
>> However, I do think one way of gauging the success of JWS/JOSE is to 
>> measure how many implementers actually get the security details right.
> 
> I agree with you.
> 
> If several people got this wrong then it is a good idea to write about it. Of 
> course, it was a bit difficult to foresee this issue at the time of writing 
> the specification.
> 
> At a minimum we should put a version of your article at oauth.net.
> 
> Since the JWT spec (which you reference in your article) is still in
> Auth48 state we can still add a warning remark to Section 7.2 of 
> https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to