Re: [jose] High risk vulnerability in RFC 7515

[Thai Duong <[e-mail]>]

(cross-posting from another thread)

One thing to keep in mind is that the public key tag contains a raw public
key, not a certificate.

How can the receivers verify the public key? They'll have to compute a
fingerprint and compare with some existing key. But if they already have
the key, a keyID should be used. Do you agree?

In other words the public key is useless. It's also dangerous because
people might forget to validate it.

On Wed, Sep 14, 2016, 9:45 AM Nathaniel McCallum <[e-mail]>
wrote:

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