On Thu, Jul 2, 2020 at 11:36 AM Corey Bonnell <cbonn...@securetrust.com> wrote:
> >> If a certificate contains both a key usage extension and an extended > > key usage extension, then both extensions MUST be processed > > independently and the certificate MUST only be used for a purpose > > consistent with both extensions. > > > > > You're reading an obligation on the CA, not an obligation on the client. > > > > 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 think it might be useful, if you'd like to talk about client > mitigation strategies, to start a separate thread. I agree, there's > definitely useful opportunities here, but there is no reasonable defense > that the CA has not introduced a meaningful security issue here by > violating the BRs. > > > > If there’s no digitalSignature KU, then the certificate is not a OCSP > responder certificate due to the technical inability to sign OCSP responses > that would be accepted by clients conforming to RFC 5280, section 4.2.1.12. > Therefore, section 4.9.9 is not applicable for those certificates that not > express the digitalSignature KU. This is directly relevant to the topic at > hand. > Alternatively: If the OCSPSigning EKU is present, and it lacks DigitalSignature, it's misissued by containing an invalidEKU. 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. 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. That's a fundamentally flawed argument, and deeply troubling. 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. If you're wondering why clients aren't checking the KUs, it's because of how widespread the failures to properly encode KUs were, even for CA certificates. Consider Golang's verifier, which skips over KU checks because of wonky CAs, and shares why. Consider that Chromium was not able to enforce id-kp-serverAuth consistency with the KU until **2019** because of how bad the ecosystem was [2]. None of this dismisses the fact that the CA was, and is, wrong for having issued invalid OCSP Delegated Responder certificates, but highlights why this idealistic appeal to KU purity disregards the security landscape that CAs are operating in, and should be aware of. [1] https://golang.org/src/crypto/x509/verify.go#L684 [2] https://bugs.chromium.org/p/chromium/issues/detail?id=795089 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
