On Fri, Jul 3, 2020 at 10:49 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > 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. > I appreciate the comparison, but we both know that it's a flawed one. You're inventing a distinction - the CA bit - that doesn't exist, within the BRs or the RFCs. Nothing in the RFCs specifies the profile you describe for commonName. That's something the BRs do, and they explicitly do it contingent upon the CA bit (Subordinate CA vs Subscriber Cert) You're inventing a fiction that, no doubt, reflected a belief of some CAs when they did it. But no such distinction exists within the profiles, and it was, as far as I can tell, only Mozilla, and only in one of the three verifiers (i.e. not applying to Thunderbird/S/MIME) that took the step to profile things further. The distinction you make, about KU, falls apart when you realize the distinction you're making here, about CAs, is also made up. > > 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. > I think this is dangerously close to divination. Mozilla did not chase down non-compliance. That didn't mean it wasn't non-compliant, just that Mozilla didn't enforce it, just like Microsoft didn't enforce their policy. That doesn't mean it was/is allowed by the BRs, and it doesn't mean that the non-compliance doesn't pose serious security risk. > > 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. "will not have any OCSP responses created by the CA trusted by clients". I can literally show you the clients that do trust this, including Major Ones. Even Mozilla doesn't check the Key Usage - https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/mozpkix/lib/pkixocsp.cpp#127 We've already shown, however, that your argument about the "invalid" key usage is still a Mozilla Program Violation, in that it violates what you're declaring a defense mechanism (RFC 5280) by including an EKU not consistent with the extensions. This isn't a question about the BRs allowing such violations: they make no such statements. However, I'm more concerned by your latest message, in which you dismiss the very real security concern. That's something I think truly is dangerous here, especially for CAs following, because you're simply not correct to dismiss the concern. I also don't think it's correct to come up with a fiction that, because something not written in any spec (that responder certs are CA:FALSE) makes it OK to include the EKU to facilitate another behaviour not written in any spec (EKU chaining), and to do so ignoring both the RFC's profile (requiring KU) and the BRs profile (requiring nocheck). You're just making things up now. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
