The jwk parameter is required when doing ephermal-static ECDH as that is the only way to carry the ephemeral key from the sender to the recipient.
One always needs to validate the key no matter how it is obtained so I would have a hard time not saying that this is a library user problem. Jim > -----Original Message----- > From: jose [mailto:[email protected]] On Behalf Of Nathaniel McCallum > Sent: Wednesday, September 14, 2016 9:46 AM > To: Quan Nguyen <[email protected]>; Michael Jones > <[email protected]>; John Bradley <[email protected]>; 崎村夏彦 <n- > [email protected]>; Thai Duong <[email protected]>; [email protected] > Subject: Re: [jose] High risk vulnerability in RFC 7515 > > 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
