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 <[email protected]> > 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 [email protected] https://www. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
