On Mon, Mar 28, 2022 at 3:08 PM Jeremy Rowley <[email protected]> wrote: > > 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.
Allright, but that's CCADB providing that clarity, not DigiCert. CCADB itself is not publicly accessible, and the public export endpoints don't make it exactly easy to find the CP/CPS for intermediates; and the Cloudflare CAs' listings require you to go though their parent CA's listing first, which is extra effort (not exactly "easy"). > 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. Is that "<A>, excluding (<B>, which are not cross-certified or publicly trusted)" or "(<A>, excluding <B>), which are not cross-certified or publicly trusted"? Also, which root CAs and intermediate CAs are those? When I find any CA certificate, can I easily check which one of your CPSes applies to it (if any)? > 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. Again, but now written as a question: could you explain why you think that Cloudflare should be considered a CA [0], while it doesn't fit the definition of CA in the BR _at all_? I don't consider "there's a CA certificate with their name on it" to be a valid answer: > Certification Authority: An organization that is responsible for the > creation, issuance, revocation, and management of Certificates. The term > applies equally to both Roots CAs and Subordinate CAs. Cloudflare Inc. does not seem to be responsible for any of the tasks in this section (nor does it seem to have been) unless you squint very hard, in which case any hosting provider creating and forwarding certificate requests for their load-balanced website hosting service would be a CA. Insofar I understand it, those hosting providers are not CAs, and Cloudflare isn't either. > 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. Could you share which of the roles of a CA Cloudflare, Inc has or had (if any) in the context of public PKI, the BR, these two CA certificates and the leaf certificates that chain up to those Subordinate CA Certificates? I'm having trouble finding any using public information, unless donating their name for use on a certificate (and maybe a bucket of money) is what makes a company a CA, in which case I'd like to get a publicly trusted CA certificate with my company's name too. - Matthias [0] As Cloudflare seems to have been used as the Subject CA whose name or DBA was used, they must have been considered the Subject CA in this case; thus considered a CA by DigiCert Inc. > -----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/CAAT_OQuUVh%2BrsGTgtg35cvZgP_GNij6ZR_L3MotSCQKH2MTRzQ%40mail.gmail.com.
