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.
