Public Discussion of DigiCert's Inclusion Request

[Ben Wilson]

All,

This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process (https://wiki.mozilla.org/CA/Application_Process#Process_Overview - Steps 4 through 9) for DigiCert’s inclusion request (Bug # 1706228, CCADB Case # 743) for the following root CA certificates:

DigiCert TLS RSA4096 Root G5  (websites trust bit, EV)

Download –  https://cacerts.digicert.com/DigiCertRSA4096RootG5.crt.pem

crt.sh - https://crt.sh/?SHA256=371A00DC0533B3721A7EEB40E8419E70799D2B0A0F2C1D80693165F7CEC4AD75

DigiCert TLS ECC P384 Root G5 (websites trust bit, EV)

Download – https://cacerts.digicert.com/DigiCertECCP384RootG5.crt.pem

crt.sh – https://crt.sh/?SHA256=018E13F0772532CF809BD1B17281867283FC48C6E13BE9C69812854A490C1B05

DigiCert SMIME RSA4096 Root G5 (email trust bit)

Download – https://cacerts.digicert.com/DigiCertSMIMERSA4096RootG5.crt.pem

crt.sh - https://crt.sh/?SHA256=90370D3EFA88BF58C30105BA25104A358460A7FA52DFC2011DF233A0F417912A

DigiCert SMIME ECC P384 Root G5 (email trust bit)

Download – https://cacerts.digicert.com/DigiCertSMIMEECCP384RootG5.crt.pem

crt.sh - https://crt.sh/?SHA256=E8E8176536A60CC2C4E10187C3BEFCA20EF263497018F566D5BEA0F94D0C111B

Mozilla is considering approving DigiCert’s request to add these four (4) roots as trust anchors with the trust bits and EV-enabled as indicated above.

Repository: The DigiCert document repository is located here: https://www.digicert.com/legal-repository

Relevant Policy and Practices Documentation:

Certificate Policy, v. 5.9, dated January 21, 2022

https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cp-v5-9.pdf

Certification Practices Statement, v. 5.9, dated January 21, 2022

https://www.digicert.com/content/dam/digicert/pdfs/legal/digicert-cps-v5-9.pdf

Self-Assessments and Mozilla CPS Reviews are located as attachments in Bug # 1706228:

Mozilla Review of DigiCert CP/CPS and Compliance Self-Assessment (xls)

DigiCert Replies to CP/CPS Review and Compliance Self-Assessment (xls)

 

Audits:  Annual audits have been performed by BDO.  The most recent audits were completed for the period ending September 30, 2021.  See https://www.digicert.com/webtrust-audits.

Incidents

DigiCert has no open incidents in Bugzilla. In the past year, there have been five incidents involving DigiCert, which are now closed satisfactorily:

1727963		DigiCert: Truncation of Registration Number
1744795		DigiCert: Issuance of certs with weak keys (ROCA)
1710444		DigiCert: Invalid stateOrProvinceName
1710856		DigiCert: Invalid localityName
1714439		DigiCert: Incorrect RegNumber-Org Type combination

 

I have no further questions or concerns about DigiCert’s inclusion request; however, I urge anyone with concerns or questions to raise them on this list by replying directly in this discussion thread. Likewise, a representative of DigiCert must promptly respond directly in the discussion thread to all questions that are posted.

This email begins the 3-week comment period, which I’m scheduling to close on or about March 31, 2022, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10).

Sincerely yours,

Ben Wilson

Mozilla Root Program Manager

 

[Ryan Sleevi]

I happened to note that DigiCert has, once again, a set of incomplete disclosures - https://crt.sh/mozilla-disclosures#disclosureincomplete

This has happened in the past - [1] [2] [3], with a more fuller history of previous incidents in [4].

DigiCert folks: Could you comment and explain?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1499585

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1451950

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1650910

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1650910#c30

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYXwMGTf4kxr7KhWr5fWd-aiJss4S0rjOz6F4-3wfFGEA%40mail.gmail.com.

[Brenda Bernal]

Dear Ryan,

 

Thank you for pointing out your observation, and we have identified the issue to be related to how CCADB is chaining for cross signed roots. All intermediates and roots that are publicly trusted are included in our last WebTrust audit and have the proper CP/CPS pointers in CCADB.

 

The Root certificates that these hierarchies were cross signed under were our legacy Symantec ones that have been distrusted and an expired root. Unfortunately, CCADB was taking the path to those roots rather than to the trusted root which is correct.

 

We were following the Mozilla recommended process of having all intermediate and ICAs same as parent for audit and CPS.  As this Root was one of the ones distrusted in 2021, it did not get the policy updates in our annual audit submission.

 

We have discussed the issue with Ben and have used a "re-parenting" process that fixed this chaining issue.

 

Thank you,

Brenda Bernal on behalf of DigiCert

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG9YxHBGf9ERxvf%3D3z3ZtfQi8%3DB2JgdAnZZwhmCsZ%3D%3DVg%40mail.gmail.com.

[Ryan Sleevi]

Brenda:

I’m glad to hear this was trivially resolved, but what I’m unclear of is how it happened and wasn’t detected until it was raised. That is, given DigiCert’s past issues in failing to notice this, my understanding of DigiCert’s past commitments is that they incorporated review of that very page as part of the CCADB update procedures, in addition to the CCADB update automation.

I bring it up now, in the discussion of root inclusion that I do believe would be an overall net positive to users, because it highlights that past problems are still unfortunately repeating. The severity of the problem, which based on the provided explanation seems quite minor, is less the issue, but rather, the repeat nature of such issues and the failure of past efforts to remediate and prevent such issues.

Do I think it should block inclusion of these roots? No, not at all - if anything, it highlights the value of such separation of purposes, to greater isolate the risk from unmitigated systemic issues. However, I do think it leads to the next question: namely, given such past patterns are still happening, what’s the timeline to transition new certificate issuance to these new paths? Are we talking an order of weeks, months, or years?

Presumably, removal of any old roots cannot occur with zero disruption until after the expiration of the extant certificates, so figuring out the timeline is useful. Similarly, have variants of these roots been cross-signed from the existing roots? If so, that might allow for a sooner transition, independent of any decision here, but which can further highlight the value of such a transition.

[Matthias van de Meent]

Last week I privately contacted DigiCert about the lack of clarity about which CP/CPS is applicable to which root / intermediate CA; to which I've not yet received any meaningful reply. Right now, the repository that DigiCert's leaf certificates link to in their CPS field does not have a clear mapping of root- or subordinate CA to CPS; nor do the CP/CPSs in that repository themselves contain this information.

MRSP 3.3(6) requires that CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates. Could DigiCert comment on when they expect this issue to be resolved?

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

--

[Buschart, Rufus]

[Brenda Bernal]

Ryan,

 

We are actively working on getting our new roots trusted.  In parallel, we plan to create new ICAs from the G5 Roots this year – that process has already started.  By the end of 2022, DigiCert plans to have G5 issued ICA replacements available to our customers.

 

We have not started building the cross-signs yet from existing roots but we are working on plans for that in parallel with our root inclusion efforts here.  We hope to limit the number of cross-signed certificates needed to support the transition effort but realize that we may have to cut cross-certs from many (if not all) of the old roots to the new roots. 

 

Our cross-signs will correspond to our plan to ensure ubiquity and root segmentation by purpose.  For example, we will likely cross-sign using the Assured ID G2 root for S/MIME.

 

Thanks, Brenda

[Matthias van de Meent]

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.
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).

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).

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.

Kind regards,

Matthias

[0] https://crt.sh/?id=2392142934

On Thu, Mar 24, 2022 at 4:05 PM Buschart, Rufus <rufus.b...@siemens.com> 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:rufus.b...@siemens.com

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

[Peter Bowen]

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
<matt...@thisisntrocket.science> 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 <rufus.b...@siemens.com> 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:rufus.b...@siemens.com
>>
>> 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: dev-secur...@mozilla.org <dev-secur...@mozilla.org> 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 "dev-secur...@mozilla.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

> 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.

[Matthias van de Meent]

On Sat, 26 Mar 2022, 03:02 Peter Bowen, <pzb...@gmail.com> 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
> <matt...@thisisntrocket.science> 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

[Jeremy Rowley]

"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.

"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.

" 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.

"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.

" 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.

Jeremy

-----Original Message-----
From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Matthias van de Meent

Sent: Saturday, March 26, 2022 10:24 AM
To: Peter Bowen <pzb...@gmail.com>
Cc: Buschart, Rufus <rufus.b...@siemens.com>; Ben Wilson <bwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Public Discussion of DigiCert's Inclusion Request

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Matthias van de Meent]

Replies inline.

On Mon, Mar 28, 2022 at 7:03 AM Jeremy Rowley
<jeremy...@digicert.com> 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 sup...@digicert.com, 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

[Jeremy Rowley]

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: dev-secur...@mozilla.org <dev-secur...@mozilla.org> On Behalf Of Matthias van de Meent
Sent: Monday, March 28, 2022 5:28 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Peter Bowen <pzb...@gmail.com>; Buschart, Rufus <rufus.b...@siemens.com>; Ben Wilson <bwi...@mozilla.com>; dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Public Discussion of DigiCert's Inclusion Request

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

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.

[Matthias van de Meent]

On Mon, Mar 28, 2022 at 3:08 PM Jeremy Rowley
<jeremy...@digicert.com> 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.

[Buschart, Rufus]

Hello Matthias!

> From: Matthias van de Meent <matt...@thisisntrocket.science>
> Sent: Friday, 25 March 2022 18:24
> Subject: Re: Public Discussion of DigiCert's Inclusion Request
>

> 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 a very clear indication: the CP field of the certificate includes a link to a CP/CPS. This CP/CPS describes who the operator of the CA is. I believe that we can expect someone who wants to dive so deep into the heart of the operating model of the publicly trusted PKI ecosystem to understand the meaning of the CP field of a certificate.

/Rufus

[Jeremy Rowley]

Our CP for publicly trusted certificates applies to all publicly trusted certificates. We are the ones who provide the link in CCADB, which meets the requirement: "CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates." We provide that info via CCADB and via our repository. I mean, technically, without me verbally telling every single person personally what the link is, there's always an intermediary. "You're not telling me the CPS, my browser is", "DigiCert isn't telling me the CPS, their CDN is", etc.

As for the Cloudflare question. The entity is verified and controls issuance and revocation of the certs. We are the service provider of those certs, operating the CA for Cloudflare. I'd actually like to expand the organizations that have a whitelabeled CA. Makes it super easy to tell who the real requester and revoker of certs are and tells you who is controlling the keys issued under the Sub CA.

[Ryan Sleevi]

Matthias,

For what it's worth, I think I may somewhat agree with Jeremy here. The requirement for any of the fields of the certificate, today, to have any bearing at all to who possess the key material isn't true, and hasn't been functionally true for the history of the Web PKI, because we don't really use Distinguished Names, and that's a Good Thing [1].

In general, we can replace the Subject and Issuer of certificates - for CAs and end-entity certificates alike - with random values, and still have the same functional system envisaged by protocols like TLS, and RFCs like the PKIX series (2459/3280/5280). This is because the system we have is predicated on machine entity of the end-entity certificate, not user-visible strings [2], and again, that's a Good Thing.

I understand your desire to identify who is in possession of the Key Material, but as it stands today, there are no "Know Your CA" rules in the BRs. The closest you get is Root Program policies, and you can see that Mozilla's Root Program places that requirement on CCADB. Again, this is a Good Thing - there's no need for every TLS connection and every certificate to convey this supplemental information, especially information that changes. Taken to its logical conclusion, at the point an organization rebrands, renames, or is acquired, it would need to revoke all of its extant certificates, to issue new intermediates (notwithstanding new roots as well), and every site operator replace their certificates. That's not ideal - and doesn't necessarily further the goal of ubiquitous strong TLS and security everywhere (... although it might hasten CAs' and site operators investments in automation, should that become a requirement).

That's not that I disagree with you on the principle of this being silly rubbish. The notion of branding intermediates is, I think, not necessarily something that helps us move towards that goal. While I appreciate Jeremy's point about the useful bookkeeping aspect of that, I'm not sure I agree that such information needs to be conveyed in every certificate, versus the use of tools like CCADB, or CAs' own tools (to match issuers to customer relationships). Indeed, if we were to "redesign" X.509 today, you could easily imagine replacing or eliminating many fields, and such branding would, I would hope, be the first to go. To that end, even the CP/CPS (let alone the userNotice statements) feels a bit excessive, but such is the world we live in: a world that half embraces the archaic silliness of X.400/X.500, and half embraces modern, automated, strong validation via domain names.

To that end, even X.500 is slowly changing; X.501 (10/21) Amendment 1 [3] finally exploits the CHOICE that is the Name type, allowing the use of DNS names or opaque values, rather than DNs. While this is not supported by RFC 5280, nor by the common Web PKI implementations, it can be read at least some as an admission that there are more ways to name things than via a globally unique directory overseen by the ITU.

That said, I do think you raise some good points, with the way the BRs are written, today, especially with respect to the definition of CA, and where such organizations fit. I think that, historically, it's been interpreted somewhere between the relationship of "management of certificates" (e.g. can Cloudflare request revocation for those certificates issued to its customers? AFAICT/AFAIK, "yes") and, in some cases, the entity acting as a Delegated Third Party of the CA. So although I'm not sure I agree with your end goal (ensuring things are unambiguously labeled in the cert), I also think you raise an interesting point worth considering.

[1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b4f

[2] https://datatracker.ietf.org/doc/html/rfc5280#section-2.3

[3] https://www.itu.int/rec/T-REC-X.501-202110-I!Amd1/en

[Ben Wilson]

On March 9, 2022, we began a three-week public discussion on DigiCert's request to include four new root certificates.[1]  (Step 4 of the Mozilla Root Store CA Application Process[2]). 

Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:  

One commenter noted that DigiCert had failed to maintain accurate records in the CCADB, based on information provided by https://crt.sh/mozilla-disclosures. DigiCert quickly updated those records so that they were accurate. Matthias van de Meent commented that DigiCert’s CP and CPS did not clearly identify which roots and intermediate CAs were governed by those policy documents.  DigiCert responded that the information was provided in the CCADB. However, he was still concerned about the ability to locate that information outside of the CCADB.

Matthias also asked, “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?” The ensuing questions and comments asked whether DigiCert and other CAs should be allowed to “white-label” subordinate CA certificates for customer organizations. (A white-labeled CA certificate has the name of a customer organization in the subject “O” field as the “nominal CA” while the root CA operator holds the keys and operates the CA that issues certificates to end entities.) Section 1.6 of the Baseline Requirements defines “Certification Authority” as “An organization that is responsible for the creation, issuance, revocation, and management of Certificates.” It was argued that the practice of white-labeling was misleading, and that the customer organization should not be listed in the subject “O” field of the CA certificate, but that it should name the actual organization performing CA tasks and being audited.

I do not believe that a resolution of this question is necessary for us to conclude discussion on DigiCert’s inclusion request. However, I am not trying to foreclose further discussion, which can continue in a separate thread if anyone desires.

Close of Public Discussion and Intent to Approve [Application Process, Steps 9-10]: 

This is notice that I am closing public discussion on the inclusion request (Application Process, Step 9) and that it is Mozilla’s intent to approve DigiCert’s four root CA certificates (Step 10). 

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/z3-sYPyykqc/m/RTnXIubVAgAJ

[2] https://wiki.mozilla.org/CA/Application_Process#Process_Overview