Matthias, For what it's worth, I think I may somewhat agree with Jeremy here. The requirement for any of the fields of the certificate, today, to have any bearing at all to who possess the key material isn't true, and hasn't been functionally true for the history of the Web PKI, because we don't really use Distinguished Names, and that's a Good Thing [1].
In general, we can replace the Subject and Issuer of certificates - for CAs and end-entity certificates alike - with random values, and still have the same functional system envisaged by protocols like TLS, and RFCs like the PKIX series (2459/3280/5280). This is because the system we have is predicated on machine entity of the end-entity certificate, not user-visible strings [2], and again, that's a Good Thing. I understand your desire to identify who is in possession of the Key Material, but as it stands today, there are no "Know Your CA" rules in the BRs. The closest you get is Root Program policies, and you can see that Mozilla's Root Program places that requirement on CCADB. Again, this is a Good Thing - there's no need for every TLS connection and every certificate to convey this supplemental information, especially information that changes. Taken to its logical conclusion, at the point an organization rebrands, renames, or is acquired, it would need to revoke all of its extant certificates, to issue new intermediates (notwithstanding new roots as well), and every site operator replace their certificates. That's not ideal - and doesn't necessarily further the goal of ubiquitous strong TLS and security everywhere (... although it might hasten CAs' and site operators investments in automation, should that become a requirement). That's not that I disagree with you on the principle of this being silly rubbish. The notion of branding intermediates is, I think, not necessarily something that helps us move towards that goal. While I appreciate Jeremy's point about the useful bookkeeping aspect of that, I'm not sure I agree that such information needs to be conveyed in every certificate, versus the use of tools like CCADB, or CAs' own tools (to match issuers to customer relationships). Indeed, if we were to "redesign" X.509 today, you could easily imagine replacing or eliminating many fields, and such branding would, I would hope, be the first to go. To that end, even the CP/CPS (let alone the userNotice statements) feels a bit excessive, but such is the world we live in: a world that half embraces the archaic silliness of X.400/X.500, and half embraces modern, automated, strong validation via domain names. To that end, even X.500 is slowly changing; X.501 (10/21) Amendment 1 [3] finally exploits the CHOICE that is the Name type, allowing the use of DNS names or opaque values, rather than DNs. While this is not supported by RFC 5280, nor by the common Web PKI implementations, it can be read at least some as an admission that there are more ways to name things than via a globally unique directory overseen by the ITU. That said, I do think you raise some good points, with the way the BRs are written, today, especially with respect to the definition of CA, and where such organizations fit. I think that, historically, it's been interpreted somewhere between the relationship of "management of certificates" (e.g. can Cloudflare request revocation for those certificates issued to its customers? AFAICT/AFAIK, "yes") and, in some cases, the entity acting as a Delegated Third Party of the CA. So although I'm not sure I agree with your end goal (ensuring things are unambiguously labeled in the cert), I also think you raise an interesting point worth considering. [1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b4f [2] https://datatracker.ietf.org/doc/html/rfc5280#section-2.3 [3] https://www.itu.int/rec/T-REC-X.501-202110-I!Amd1/en -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEMiHKn1pSJMtYYYLA45dKKrSppn-xCpP7ydktEHkfa3Q%40mail.gmail.com.
