On March 9, 2022, we began a three-week public discussion on DigiCert's request to include four new root certificates.[1] (Step 4 of the Mozilla Root Store CA Application Process[2]).
*Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:* One commenter noted that DigiCert had failed to maintain accurate records in the CCADB, based on information provided by https://crt.sh/mozilla-disclosures. DigiCert quickly updated those records so that they were accurate. Matthias van de Meent commented that DigiCert’s CP and CPS did not clearly identify which roots and intermediate CAs were governed by those policy documents. DigiCert responded that the information was provided in the CCADB. However, he was still concerned about the ability to locate that information outside of the CCADB. Matthias also asked, “Should a CA certificate be allowed to contain the subject of another company's name while this subordinate CA is (and will be) under full control of the CA, considering that leaf certificates signed with such CA will provide the (false) notion that the other company signed those leaf certificates?” The ensuing questions and comments asked whether DigiCert and other CAs should be allowed to “white-label” subordinate CA certificates for customer organizations. (A white-labeled CA certificate has the name of a customer organization in the subject “O” field as the “nominal CA” while the root CA operator holds the keys and operates the CA that issues certificates to end entities.) Section 1.6 of the Baseline Requirements defines “Certification Authority” as “An organization that is responsible for the creation, issuance, revocation, and management of Certificates.” It was argued that the practice of white-labeling was misleading, and that the customer organization should not be listed in the subject “O” field of the CA certificate, but that it should name the actual organization performing CA tasks and being audited. I do not believe that a resolution of this question is necessary for us to conclude discussion on DigiCert’s inclusion request. However, I am not trying to foreclose further discussion, which can continue in a separate thread if anyone desires. *Close of Public Discussion and Intent to Approve [Application Process, Steps 9-10]: * This is notice that I am closing public discussion on the inclusion request (Application Process, Step 9) and that it is Mozilla’s intent to approve DigiCert’s four root CA certificates (Step 10). This begins a 7-day “last call” period for any final objections. Thanks, Ben [1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/z3-sYPyykqc/m/RTnXIubVAgAJ [2] https://wiki.mozilla.org/CA/Application_Process#Process_Overview On Mon, Mar 28, 2022 at 5:52 PM Ryan Sleevi <[email protected]> wrote: > 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/CA%2B1gtaaFa-5KEn28pMLfZAeJBANvTL5bg7zhR437%3DibmLGDZ1Q%40mail.gmail.com.
