For the CPS doc, I said the links are all in CCADB. You can see how each CPS doc relates to a CA there. This is the relevant one for all publicly trusted certificates issued by DigiCert: https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cps-v5-10.pdf. The applicability is stated in the first paragraph and as a description on the webspage hosting the CPS. "This document is the DigiCert, Inc. (“DigiCert”) Certification Practices Statement (CPS) that outlines the principles and practices related to DigiCert’s certification and time-stamping services. This CPS applies to all entities participating in or using DigiCert’s certificate and time-stamping services, excluding participants in DigiCert’s Private PKI services, which are not cross-certified or publicly trusted. This CPS only addresses the actions of DigiCert and not those ofthird parties operating with cross certificates issued by DigiCert."
I suppose if none of those methods sufficiently identify the scope of the CPS, we can rename the CPS to "CPS for all Publicly Trusted Certificate". Implied rules aren't real rules. Instead, here is what the BRs say about sub CA names (section 7.1.4.3.1): Certificate Field: subject:organizationName (OID 2.5.4.10) Required/Optional: Required Contents: This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section 3.2.2.2. The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”. In all cases, the org name is present and verified. There's nothing misleading about it. -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Matthias van de Meent Sent: Monday, March 28, 2022 5:28 AM To: Jeremy Rowley <[email protected]> Cc: Peter Bowen <[email protected]>; Buschart, Rufus <[email protected]>; Ben Wilson <[email protected]>; [email protected] <[email protected]> Subject: Re: Public Discussion of DigiCert's Inclusion Request Replies inline. On Mon, Mar 28, 2022 at 7:03 AM Jeremy Rowley <[email protected]> wrote: > > "CA certificates imply that the subject of that certificate is a CA." > - This isn't true. Baltimore isn't operated by Baltimore. Starfield isn't > operated by Starfield. There's a long history of this not being true. That the implication is false doesn't mean that the implication doesn't exist. Similar to how advertising "Apple Pie: Improved Recipe; without Asbestos" implies that the previous applie pie recipe contained asbestos, while that is not necessarily the case. I will note that it is indeed possible that a CA key (and thus: CA operations under that key) is transfered between companies and that the CA certificate continues to contain the previous company's name, but I'm not taking issue with that: The right to use that name was transfered with the certificate; and the validation of that certificate was at the moment of issuance correct. What I'm taking issue with, however, is that in this case Cloudflare, Inc. seemingly has not been the CA in any meaningful form. > "Transitively, this also implies that the subject should ensure that the > tasks of a CA are all handled, as an example, I fail to see how you can > outsource IP / DNS validation under the BR, or outsource the quarterly > at-least-3% audit." > - This is also incorrect. Section 1.3.2: With the exception of Section > 3.2.2.4 and Section 3.2.2.5, the CA MAY delegate the performance of all, or > any part, of Section 3.2 requirements to a Delegated Third Party, provided > that the process as a whole fulfills all of the requirements of Section 3.2. As you might note; self-audits are part of the requirements under section 8.7 (thus do not fall under the Section 1.3.2 allowed delegation to third parties); and section 8.7 explicitly requires the CA's internal validation specialist to check the validation for those three percent of certificates. Furthermore, seeing that validations in sections 3.2.2.4 (Validation of Domain Authorization or Control) and 3.2.2.5 (Authentication for an IP Address) are excluded from the allowed delegation to third parties; I fail to see why you say my statement is incorrect. Note that "ensuring that all the tasks of a CA are handled" could indeed include delegating to third parties those tasks that can be delegated (that is indeed also ensuring that the task is handled); but as noted IP and DNS validation cannot be delegated and must be done by the CA. > " Because I see no reason why (other than gross negligence) a CA would sign a > CA Certificate for an Applicant that has not shown or proven ownership of, > nor control over, the private key of the certificate request and its HSM." > - Why? There's no basis for this in the BRs or the Mozilla policy. Mozilla policy section 8 is clear that trust should not be assumed to be transferable. Although there are no precise details in BR nor MRSP, I think that signing CA certificates on keys that you don't know the ownership status of is not doing your due diligance in determining who this trust is transfered to. Additionally; the MRSP in section 8 also require that "throughout any change, CA operations MUST continue to meet the requirements of this policy". This heavily implies that any key material being included in intermediate CA certificates must also be compliant with the BR (and related documents). I find it difficult to believe that it is possible to check this compliance without also checking ownership and posession. > "In this case of DigiCert's Cloudflare CAs there is no relying party > agreement for the Cloudflare subordinate CA that refers ro Cloudflare Inc., > so Cloudflare is either not to be considered the Certificate Authority, or > DigiCert has an external subordinate CA that is failing to comply with the BR > and that is not correctly registered in CCADB." > - Source? This isn't supported in the BRs or Mozilla policy. A CA is expected to have their own CPS and test websites, and is required to do self-audits (BR s8.7). The information in the Cloudflare certificates all refers to Digicert, and considering that the Cloudflare CA certificates contain Digicert's OIDs, I don't think that Cloudflare ever had their own public CA operations set up, nor do I think that Cloudflare ever considered to do the tasks of a CA. At this point, there's two options: 1.) Cloudflare Inc. is the CA for those certificates. In this case CCADB must be updated to contain that information, and Cloudflare Inc. should start complying with the requirements of the BR; i.e. validating domains; doing self-audits; and publishing their CP/CPS, test domains, and other CA-related documentation. 2.) Digicert Inc. is the CA for those certificates. In this case, the information included in the certificates is misleading for the reasons I noted before. Digicert is fully capable of issuing certificates from less misleading CAs; and should stop using these intermediate certificates. > " Either way, I'd prefer if Digicert could reply to my previous question > regarding the lack of clear indicator which CP/CPS is applicable for which > (subordinate) CA." > - I already replied to this. I can't seem to find your reply, so could you please repeat it? [0] - Matthias [0] It's not in my inbox, nor in my spambox, nor as a reply to my initial e-mail in private to [email protected], nor as a mail related to the subsequently created case (number 02896081), nor on this thread's Google Groups page: the e-mail I'm replying to seems to be your only post on that page -- 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/CAAT_OQvav%2B8U3oxOPbhLRWt%2B5ago7-Yep8Hczn%2BCoYOPi6OpnA%40mail.gmail.com. -- 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/BYAPR14MB26005F5C1BDB5844D106FCF38E1D9%40BYAPR14MB2600.namprd14.prod.outlook.com.
