I suppose a note or reference like that couldn't hurt. I'll look to add
something along those lines. Obviously, a spec like this can't restate
everything from the specs it builds on. But sometimes a call-out or pointer
is useful.

On Tue, Aug 29, 2017 at 11:10 PM, Vladimir Dzhuvinov <
vladi...@connect2id.com> wrote:

>
> On 29/08/17 18:14, Brian Campbell wrote:
> > Sec 4.7 of RFC 7517 <https://tools.ietf.org/html/rfc7517#section-4.7>,
> > which defines "x5c" for JWK, says that the "key in the first certificate
> > MUST match the public key represented by other members of the JWK." Thus,
> > how I read it anyway, the check you mention is already a requirement of
> the
> > JWK layer.
> Thanks Brian, I missed that bit!
>
> And just realised that the Nimbus lib doesn't check the x5c pub key when
> creating / parsing JWKs! I suppose other JOSE libs may have the same
> omission. A reason to add a note to the MTLS spec perhaps?
>
> Vladimir
>
> > On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com
> >> wrote:
> >> Aspects of this were previously discussed, on and off list.
> >>
> >> According to section 2.3, clients registering for public key bound mTLS
> >> auth must register their public keys as JWKs, or client X.509
> >> certificate (as x5c parameter in RSA and EC JWK).
> >>
> >> In the latter case, are there any security implications if there is
> >> mismatch between the registered x5c and the top-level public key JWK
> >> parameters? Should the AS perform some sanity checks on the JWK
> parameters?
> >>
> >> A client could for instance register a JWK where the top-level JWK
> >> public key doesn't match the public key in the x5c (as key type, or
> >> public key value).
> >>
> >> Thanks,
> >>
> >> Vladimir
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
>
> --
> Vladimir Dzhuvinov :: vladi...@connect2id.com
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to