On Thu, Jul 2, 2020 at 9:32 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> 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. I don’t understand why you’re making a distinction as to CA certificates, which are irrelevant with respect to the Delegated Responder profile. That is, you’re trying to find a way that it’s compliant, but this introduction of the CA bit as somehow special doesn’t have any basis, as far as I can tell. When you throw that out, it seems we’re in agreement here? If it’s problematic to have the wrong KU for the EKU with basicConstraints:CA=FALSE, it’s problematic to have the wrong KU for the EKU with basicConstraints:CA=TRUE. They’re both restrictions on key usage, and it doesn’t matter that one is a CA key. 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 Where? It seems you’re reading this as inferred through omission of a prohibition in Section 5.3, but you’re using it in the remainder of your argument to argue why it’s proactively allowed. - 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. Yes, it’s impossible to create an Issuing CA that has id-kp-OCSPSigning. That’s not a “bug” or the “gotcha” moment you seem to suggest: it’s the intended result! This is ostensibly even clearer in Microsoft’s policy, but I understand that some want to debate that as well, and I defer to Microsoft to defend their policies and interpretation. 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. I can understand why a CA wanting to permit it might argue for this, but that’s not the status quo today, and not permitted today. At its heart, it’s another debate about intent: which signals “intent” and expectations more: the EKU or the KU. You’re seemingly arguing that EKU with wrong KU nullifies RFC 6960, but that doesn’t hold water. You’re arguing it should, because an unspecified aspect of EKU handling means that the CA bit should matter. Yet there’s nothing to support that, because of course it’s unspecified. I get the view that says “well, this is how we solved these problems back then”. We see CAs bring this out regularly with compliance incidents; internal server names and IP addresses were both manifestations of “well, it worked, so we assumed it was right”. Some CAs recognized the risk (good job Sectigo), some CAs recognize the risk (good job DigiCert), and some want to argue that this is all the clients’ fault, the CA did nothing wrong, and Denmark smells lovely, what do you mean it there’s an overturned Durian truck? But I can’t get the view that says, even in 2020, that a Thing is Not a Thing, which in this case is a Delegated Responder. Just like I can’t understand folks who say a Sub-CA is not a Sub-CA if it’s a Cross-Certificate. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
