On Sat, 26 Mar 2022, 03:02 Peter Bowen, <[email protected]> wrote: > > Matthias, > > While I agree that this can be a little confusing at first, I don't > think it is contrary to the BRs or other requirements. See my > comments inline. > > On Fri, Mar 25, 2022 at 10:24 AM Matthias van de Meent > <[email protected]> wrote: > > > > Dear Rufus, > > > > I have several reasons why I think "white label" CAs (as seen in [0]) don't > > fit the BR: > > > > 1.) Misleading > > > > I think that "white label" CAs are at the very least misleading if the > > "white labeled CA" 's certificate contains no clear indication that this CA > > is not operated by the subject of the certificate. > > There is no requirement in the BRs that the subject information of any > certificate match that of the operator of the infrastructure using the > certificate. For example, it is very reasonable to have Example, Inc. > contract with a marketing agency to build their website and that > agency then contracts with a hosting provider to host the website. > The website has Example, Inc's contact information, orders placed on > their website are handled by Example Inc, etc. However the website > itself is on servers not owned by Example Inc and Example Inc likely > has no technical access to the servers. Are you suggesting that the > Example Inc website cannot have a certificate with Example Inc in the > subject identity information?
No, I'm not suggesting that; I was not suggesting anything related to server certificates. However, I find your indirect comparison between server (SSL) certificates and CA certificates to be distracting. The BR (and related documents such as MRSP) have special requirements regarding the handling, transfer and backup of CA key material and infrastructure. To the best of my knowledge, the only requirements for Subscribers are those in section 9.6.3 of the BR, and they are much more limited in what they require of the user. > > The certificate chain would imply (without _clear_ indication of the > > contrary) that the root CA found "WL company" to be trustworthy enough to > > operate an intermediate CA; and that this "WL company" then issued the leaf > > certificate. Because this implication is not true; the use of a "white > > label" CA certificate is misleading; and such CA would need to be revoked > > according to BR s4.9.1.2 (6). > > It seems reasonable that the case above could be changed to Example > Inc contracts with BigPKI Inc to run a CA on their behalf. It does > not seem misleading, as Example Inc contracted BigPKI. CA certificates imply that the subject of that certificate is a CA. 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. > > 2.) Incorrect subject information due to incorrect determination of > > Applicant. > > > > In BR section 1.6.1 for the definition of Applicant: "[...] For > > Certificates issued to devices, the Applicant is the entity that controls > > or operates the device named in the Certificate, even if the device is > > sending the actual certificate request". Although CA keys being signed is > > not an obvious fit for this description, I think this is similar enough to > > apply to CA certificates as well: CA keys are supposed to be inside > > (secured) devices after all. > > > > In the case of white-label CA certificates the Applicant is thus the CA > > providing the white-label services. Subject validation should therefore > > result in subject information of the operator, not the contracting party in > > need of white-label CA services. Any other information would be incorrect > > validation of subject information; thus requiring revocation as per BR > > s4.9.1.2 (5). > > I don't see why it is assumed that the Applicant is the HSM operator. 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. > > 3.) Invalid values in certificate fields due to WhiteLabeled Corp not being > > a CA. > > > > BR section 7.1.4.3 is clear about what information may be put in the > > subject:organizationName and subject:countryName fields of CA certificates. > > > > In an example, "WhiteLabeled Corp" consumes white-label CA services from > > RootCA (where all but the name on the certificate is managed by and > > operated by RootCA). WhiteLabeled Corp is not a CA for the BR in this case: > > it does not provide any of the required services (CP/CPS, OCSP, CRL, etc.) > > nor is it bound by the required contracts (subscriber / relying party > > agreement). WhiteLabeled Corp can thus not be considered the CA for > > validation of s7.1.4.3 field forms, and its details can thus not appear in > > the subject:organizationName and subject:countryName fields of the > > white-label CA certificates. > > Again, I'm not clear why WhiteLabeled Corp cannot contract RootCA to > run the CA on their behalf with part of the process being that > WhiteLabled Corp applies for a CA certificate. A CA has to have subscriber- and relying party agreements in place with their subscribers and relying parties (see BR s9.6.1). 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. > Would you feel differently if MegaCA operated MegaRoot and > Whitelabeled Corp contracted with MegaRoot to issue the certificate > for the CA and separately contracted RootCA to run the CA? I'd say it depends on whether Whitelabeled Corp is the legal owner of the keys, and whether Whitelabeled Corp is actually doing the tasks required from a CA (such as doing the 3% self-audits, signing Subscriber Agreements, etc). If all Whitelabeled Corp does is provide money to RootCA, then I'd say RootCA is the CA and should thus be the subject of the CA certificate. Note that this does not take into account potential transfers of key material through e.g. sale, lease or other methods; but by lack of contrary evidence (specifically; I have seen none of the notices that MRSP section 8(2) and section 8(3) requires; but then again absence of proof is not proof of absence) I believe no sub-CA signing for Cloudflare as a CA, nor transfer of CA from Cloudflare to Digicert has happened. 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. Kind regards, Matthias -- 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_OQvgCtp1t_S46SC-GfUAWRO79bTGu_GBPL0-Zv4Dq1DD5w%40mail.gmail.com.
