> 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.
The argument you're asserting is akin to someone saying that a CA certificate with serverAuth EKU is mis-issued if the subject Common Name is "Super Duper High Assurance Issuing CA", which is not a hostname in preferred DNS syntax. After all, the EKU definition for serverAuth in RFC 5280 states that certificates expressing that EKU value are used for TLS server authentication, and clearly that is a malformed hostname so the certificate can't be used for its intended purpose. In essence, the argument you're presenting applies the end-entity profile definition to the CA certificate profile for that EKU, which doesn't make sense. > 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. End-entity certificates and CA certificates will naturally have different KU values to constrain the allowed usages of the key. Again, the argument being presented here tries to assert that CA certificates need to fit the profile of the end-entity certificate for the corresponding EKU. >> 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. Ben's email from last evening [1] clearly stated that Mozilla has allowed ocspSigning alongside other EKUs and the concrete example given was a CA certificate that expresses the serverAuth and ocspSigning EKUs [2]. Notably, this certificate also lacks the digitalSignature KU bit. >> 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! If Mozilla Root Policy has historically allowed this as was stated last evening, then surely there is some way to do it in a compliant manner. > 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. I think there's a world of difference between these two cases. In the former case, there are technical controls for certificates used in a RFC 5280 PKI such that a CA certificate that expresses the ocspSigning EKU but no digitalSignature KU bit will not have any OCSP responses created by the CA trusted by clients. In the latter case, I entirely agree with you: the only assurance that a "Cross-Certificate" can't be used to issue end-entity certificates is pinky swears and promises and therefore must be treated as a Sub-CA, because it technically is a Sub-CA. Thanks, Corey [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/2WlxGVylBwAJ [2] https://crt.sh/?id=2472155 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
