On Sun, Jul 5, 2020 at 4:35 PM Corey Bonnell <cbonn...@outlook.com> wrote:
> > > 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) > > I mean, that’s exactly how SSL/TLS hostname verification is done. This > profile of serverAuth certificates regarding subject CN is explicitly > specified in RFC 6125 and other application-specific protocol > specifications (such as RFC 2818), not just in the BRs. > > > The distinction you make, about KU, falls apart when you realize the > distinction you're making here, about CAs, is also made up. > > A CA certificate expressing solely the certSign and crlSign KU bits is > expressing through technical constraints it’s only an issuer of > certificates and CRLs for issued certificates that share the same EKU value > and cannot be used for any other purpose, such as OCSP response generation. > I don’t see how this concept is made up. > > > 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’m not dismissing the security concern at all and I’m not sure how you > arrived to the conclusion that I was. > You've repeatedly, incorrectly, misleadingly stated certain things "cannot" happen, on the basis of unsupported interpretations that show they can indeed. I can understand if you believe they "should not", if clients worked the way you envision, but simply stating they cannot, ergo there is no issue, is at best false, and at worst, outright dismissive of the security concerns, because as you say, they "cannot" happen. > My understanding was that we are discussing the relevant standards and > policies; the security issue is obvious. As Jeremy said above, discussion > of the relevant policies and potential improvements are also important. The > intention of this and previous messages is to point out is that the > security issue has not been precipitated by policy violations/mis-issuance > in at least a subset of the CA certificates involved and that > clarifications and policy improvements are sorely needed to provide clarify > to better prevent a recurrence of the security issue. > Hey Corey, This is my last message on this, because I'm afraid we're not making any useful progress on this. As I've said, you've continued to make things up to support your interpretation, and I don't think there's much left I can say that good-faith engages on this. I'm not going to debate this further, because the plain and simple rule is that it is a violation of the BRs, full stop. Continuing to invent requirements to try to make it sound like you're making a compelling argument is, unfortunately, not productive. Your most recent message continues this demonstration. When you make such statements like "cannot be used", despite clearly being shown they can be used, you do a great disservice to your argument, but an even greater disservice to CAs affected by this, who might be confused as to think you're saying the security concerns are non-existent. The core of your current argument rests on two fictions that you've invented, and any CA that were to rely on such fictions would, in my mind, be so dangerously bad-faith as to warrant distrust. Corey's Fictional/Non-Existent Specification 1) That the keyUsage bit being incorrect makes this "something other than" an OCSP Responder, and ergo not misissued. As mentioned before, this is a dangerous fiction to invent. It's the same fiction that would argue that an id-kp-serverAuth certificate, with a KU of certSign, a basicConstraints CA:FALSE, and a SAN of "google.com" is 'clearly' not a misissuance because the keyUsage proves it's not a server certificate and proves it can't be used for TLS. As I said, this fiction invents a new set of requirements that are not placed within the BRs, to suggest that keyUsage is somehow part of technically constraining a profile. The solution for this has already been known and identified: A specific profile of certificates in which any use of any extension outside of the allowed semantics is misissuance. Much like was done for signature algorithms, that appears to be the only way to avoid the problem of CAs not reading the specifications and understanding their interplay. Corey's Fictional/Non-Existent Specification 2) That despite no RFC saying otherwise, and the BRs certainly not saying so, that the presence of id-kp-OCSPSigning within a CA:TRUE certificate is somehow distinct from within a CA:FALSE certificate This tries to fit the concept of EKU chaining semantics as if to counteract those of RFC 6960. At best, you're reading RFC 5280's 4.2.1.12's "In general, this extension will appear only in end entity certificates" as a statement that the semantics are, at best, undefined for a CA:TRUE, and ergo all of the semantics defined within that section, or any subsequent RFC, are relevant iff CA:FALSE. Further, in doing so, you're arguing both that the semantics for the KU matter (as part of Corey's Fictional/Non-Existent Specification 1) and that the clause in 4.2.1.12 "If a certificate contains both a key usage extension and an extended key usage extension" doesn't matter, at least with respect to Mozilla Policy, because of this hypothetical duality based on the CA bit. Here again, the solution is simple: an explicit profile on responder certificates to make it clear "What is a responder" and that any other interpretations, outside of this, are misissued. Both of these made up interpretations are not ones that are worth any further time debating, because we continue to go around in circles where you won't acknowledge that you simply made them up. I don't think our discussion has, in any meaningful sense, improved the policy issues, especially when they rest on made-up fictions. That part already has a clear solution, one which was already proposed as part of SC31 and now shifting to the "Cleanups and Clarifications" ballot to follow. You're more than welcome to engage on the precise policy language, to see whether I have sufficiently and adequately addressed your concerns, but these e-mails have not helped improve those proposals in any way. At the end of the day, there will always be bad-faith attempts to reinterpret the requirements in order to fit a narrative that a CA has not misissued. While they are interesting attempts at creative writing new fiction, they aren't useful in providing concrete guidance for CAs. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
