> On 8 Mar 2021, at 12:50, Neil Madden <[email protected]> wrote: > > 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.
I have this part backwards - RFC 5280 path validation skips the KeyUsage check for the end-entity certificate, not the trust anchor cert. This makes more sense. The rest of my comments/questions still apply though. > > 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
