>> It’s an obligation on the client, because the verb “processed” makes no sense if the intent were to restrict only CAs.
> They're processed independently. The usage requirement is on the CA. I don't see how this is relevant. The language clearly states that clients must process both the KU and EKU extensions when both are present. > I'll put it bluntly: Your argument is deeply troubling and I would have little hesitation arguing for the full and immediate distrust of a CA that made it, that's how extremely problematic I see it. I appreciate that we're discussing in the abstract, but I want to emphasize how ardently I reject this argument when it comes to CAs filing their incident reports, to make sure they don't point to this thread as if somehow you've made the argument for them. For the avoidance of doubt, allow me to state that I'm posting this in an entirely personal capacity :) > The same logic being applied here would say that a Subscriber certificate, which had a TLS serverAuth EKU, was not actually a "server" certificate if the KU is wrong. Worse, however, you'd similarly argue that if the KU *is* wrong, nothing else about the certificate could be considered misissued, because it's clearly "not a TLS server certificate". After all, 7.1.2.3(e) of the BRs only has KU as optional, and 1.1 of the BRs only applies to certificates "intended" for TLS, and your argument would say KU shows intent. This argument doesn't address the situation at hand, namely the interaction between CA certificates, EKU, and KU. If we were discussing OCSP EKU end-entity certificates that lack the digitalSignature KU, then I'd be in full agreement with you. But we're not; we're discussing CA certificates, which contain a set of KUs that restrict the usages of the CA Key Pair, namely the technical inability to sign OCSP responses by lack of the digitalSignature bit. > At the heart of our disagreement is that you'd like to read something like 4.2.2.2 of RFC 6960, which says "OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate", and add a clause "if and only if the KU is consistent". And I can understand why that'd be appealing, and certainly when we talk about client usage, why that would be desirable. But much like we talk about scoping issues, the mere act of including the EKU designates it as a Responder certificate. If the KUs are wrong, and if clients checked KUs, that would mitigate some of the harm, but doesn't change the fundamental fact that it's still been designated, by the CA, as an OCSP Responder. It may not be useful as one, but it still *is* a responder certificate, and 4.9.9 applies. Let's break this down: - RFC 5280 indicates that the digitalSignature KU is required for clients to verify signatures (e.g., OCSP response signatures) using the public key in the certificate - Mozilla Root Policy allows ocspSigning EKU in subCA certificates alongside other EKUs - The OCSP nocheck extension directs clients to not perform revocation checking for the certificate So if a given intermediate certificate has an EKU of serverAuth and ocspSigning: - If the certificate has the OCSP nocheck extension, then the certificate likely runs afoul of BR 4.9.7 and 4.9.10 as it is irrevocable - If the certificate does not have the OCSP nocheck extension, then according to your interpretation, it is a misissued OCSP delegated responder and thus runs afoul of BR 4.9.9 due to lack of the nocheck extension Ignoring the KU, it appears that it is impossible to create a compliant CA certificate, despite it being allowed by Mozilla Policy. However, if you consider that the digitalSignature KU is required for clients to process OCSP responses per RFC 5280, then a compliant profile that protects RFC 5280-adhering clients from errant OCSP responses would be: - KU without digitalSignature, which is a technical control that prevents OCSP responses signed using the CA Key Pair from being trusted by compliant clients. - EKUs of serverAuth and ocspSigning - No nocheck extension, to allow for revocability of the intermediate I would argue that certificates that adhere to the above profile are not mis-issued per the relevant policies and provide the proper technical protection (not just stated intent!) to RPs against OCSP responses signed by the CA key pair (assuming, of course, the client implements RFC 5280 correctly). Additionally, such a certificate is revocable. Thanks, Corey _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
