Re: [jose] High risk vulnerability in RFC 7515

[Nathaniel McCallum <[e-mail]>]

OTOH, removing the 'jwk' parameter means that all attributes of keys
need to be duplicated in the header namespace.

I concur that nobody should trust the contents of the jwk parameter
without additional verification. And I would support language of this
type in an errata. But I think the 'jwk' parameter does have real
value.

On Wed, 2016-09-14 at 08:34 -0700, Quan Nguyen wrote:
> 
> 
On Tue, Sep 13, 2016 at 8:43 PM, Quan Nguyen <[e-mail]>
> wrote:
Hi,

I'm Quan Nguyen, a Google Information Security Engineer.

RFC 7515, https://tools.ietf.org/html/rfc7515#section-4.1.3  "jwk"
> (JSON Web Key) Header Parameter allows the signature to include the
> public key that corresponds to the key used to digitally sign the
> JWS. This is a really dangerous option [1]

This option allows any attacker to just generate private key /public
> key pair, send the public key together with the signature and and
> signature will be valid. It means that the signature is meaningless
> and easily bypassed. Note that even if it's OPTIONAL, the attacker or
> MITM can always include that field. 

I'm aware that you have a section 6 and Appendix D talking about key
> trust decision. However:
     1.  There is no reason to trust this key
     2.  There is no way to verify public key's truthfulness to make
> trust decision, unless the receiver already knows the public key in
> advance (in that case, "kid" is enough).

I've seen library making this mistake, but they just followed the
> RFC, so it's hard to convince them to fix the issue. In the end of
> the day, users are vulnerable. Furthermore, I believe this is RFC's
> vulnerability, not the library.

Regards,

-Quan

[1] I'm aware that there may be a rare use-case that needs to send
> the public key, e.g., certificate signing request, but even in that
> case, the user can send the public key, e.g, in opaque field in JWT.


_______________________________________________
jose mailing list
[e-mail]
https://www.