An interesting question was raised by our developers around the interpretation 
of JWK “use” and “key_ops” constraints when publishing a self-signed 
certificate for mTLS client authentication. In X.509 the KeyUsage extension 
distinguishes between keys intended for use for verifying general signatures 
(digitalSignature) and those used for verifying signatures on certificates 
(keyCertSign). The JWK spec doesn’t make this distinction, so there is only the 
generic “use”:”sig” and “key_ops”: [“verify”] indicators. So, is “use”:”sig” 
(or “key_ops”:[“verify”]) compatible with publishing an X.509 certificate (x5c 
claim) that asserts KeyUsage keyCertSign?

It seems plausible that an application might also choose to consume CA 
certificates from a central certificate management service that publishes them 
in JWK format on an internal HTTPS endpoint. So this question is potentially 
broader than just self-signed certs, although that is the only case discussed 
in RFC 8705.

In the course of trying to answer this question, I came across 
https://github.com/openssl/openssl/issues/1418 
<https://github.com/openssl/openssl/issues/1418> which has links to various 
relevant RFCs in the discussion. The conclusion appears to be that when 
processing self-signed certificates the KeyUsage check should be skipped. The 
reasoning appears to be that we don’t want self-signed certs to assert the 
keyCertSign bit, because this increases the risk of them being mistaken for 
genuine CA certs. In fact, the language from RFC 5280 suggests this check 
should be skipped for any trust anchor, whether self-signed or not.

RFC 8705 is silent on how to interpret use/key_ops in this case, and RFC 7517 
doesn’t discuss whether the signature-related use/key_ops are intended to cover 
certificate signatures or not. RFC 7517 also doesn’t say whether applications 
are even required to enforce use/key_ops constraints - it seems left to the 
discretion of the application. (There’s no language like “the application MUST 
NOT use the key for a use not specified”). In general, RFC 7517 is silent about 
how constraints on any X.509 certificate interact with constraints specified in 
the JWK itself.

My feeling is that “use”:”sig” and “key_ops”:[“verify”] probably shouldn’t 
imply that the key can be used to verify certificate signatures (danger lies 
that way), and that when processing a JWK specifically as a self-signed trust 
anchor we should follow the lead of RFC 5280 and instruct applications to 
ignore any use/key_ops constraints on the JWK. What do others think? (And how 
would we go about clarifying this? As an errata?)

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to