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? > 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. > 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. > 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. 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? Thanks, Peter (speaking only for myself) > > Kind regards, > > Matthias > > [0] https://crt.sh/?id=2392142934 > > On Thu, Mar 24, 2022 at 4:05 PM Buschart, Rufus <[email protected]> > wrote: >> >> Dear Matthias! >> >> >> >> I believe it’s industry best practice for CA operators to operate ‘white >> labeled’ CAs on behalf of their customers. The operator of the CA is being >> identified in the Certificate Policy field and the owner of the CA is stated >> in the Subject field. Where do you see a problem with this? >> >> With best regards, >> Rufus Buschart >> >> IT IPS SIP ET >> Freyeslebenstr. 1 >> 91058 Erlangen, Germany >> Mobile: +49 (1522) 2894134 >> mailto:[email protected] >> >> Important notice: This e-mail and any attachment thereof contain corporate >> proprietary information. If you have received it by mistake, please notify >> us immediately by reply e-mail and delete this e-mail and its attachments >> from your system. Thank you. >> Siemens Corporation: Chairman of the Supervisory Board: Jim Hagemann Snabe; >> Managing Board: Roland Busch, Chairman, President and Chief Executive >> Officer; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, >> Judith Wiese; >> Registered offices: Berlin and Munich, Germany; Commercial registries: >> Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 >> >> >> >> >> >> From: [email protected] <[email protected]> On >> Behalf Of Matthias van de Meent >> >> Additionally, while not important for this inclusion request, it would be >> appreciated if DigiCert could provide their insights on the questions I >> raised in [0] on the subject of their practices; specifically the second >> question (reworded for brevity): 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? >> >> Kind regards, >> >> Matthias van de Meent >> >> >> >> [0] >> https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/JLxGhM1pJ9w/m/21jQN3tSAwAJ > > -- > 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_OQtw4xYUAG1KMMqqzQHtUDRe-FxzQF%3DjQUQGVyOK0SjktA%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/CAK6vND8q4GS_tbrit0jFsc4%3DuiDhNzisvO_b4NQ5Q8%2Bb9wa1zA%40mail.gmail.com.
