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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
