Pursuant to the procedure outlined in the wiki for externally operated
CAs[1], three weeks ago GoDaddy initiated public discussion[2] announcing
its intent to issue two externally operated intermediate CAs to Certainly,
LLC.[3]
*Background*
In evaluating roots for inclusion, we are bound by the Principles of the
Mozilla Manifesto[4] and the Mozilla Root Store Policy (MRSP) [5]. We use
an open, public, and transparent procedure, and we evaluate the risks to
users’ security and privacy.
Under section 8 of the MRSP (v.2.7.1), “All CAs whose certificates are
included in Mozilla's root program MUST notify Mozilla if: … an
organization other than the CA obtains control of an unconstrained
intermediate certificate (as defined in section 5.3.2 of this policy) that
directly or transitively chains to the CA's included certificate(s).” The
procedure for performing the review of externally operated subordinate CAs
was published in the wiki[1] relatively recently. Previously, there had
only been a requirement to notify Mozilla.
The above-referenced procedure makes it clear that the “Quantifying Value”
step and other steps not outlined in the procedure are not required. Such
additional steps are reserved for when we process a root inclusion request.
*Summary of Discussion *
Ryan Sleevi argued that Mozilla's approval of the two intermediate CAs
should be withheld until Certainly had been approved as a root CA operator
pursuant to its pending root inclusion application.[6] His primary argument
has been that the security risks to the community are equal under either
case and that the approval of Certainly allows it to "jump the queue" and
avoid some of the due diligence that would otherwise be required (e.g.
CP/CPS review and a risk-vs-value justification).
Wayne Thayer on behalf of Certainly responded that Ryan was asking for a
process that would be new and different from the existing process.
Ryan responded that accepting the sub CAs would be "functionally no
different than accepting the root CA without those processes being
completed."
I responded that two different trust decisions were involved – one was
trusting the root(s) and the other being to allow GoDaddy to issue the sub
CAs to Certainly.
Dimitris Zacharopoulos argued that the situation at hand involves an
existing CA operator (i.e. GoDaddy), which had performed due diligence and
was taking on liability and reputational risks and was placing controls to
monitor the compliance. He also argued that procedurally, it would be
unfair to delay the application more than the current Mozilla Policy
dictates.
Ryan responded that the risks are the same for Mozilla users, and that the
level of vetting and review should be the same under either scenario. He
argued that security of users should outweigh the "fairness"
considerations. He also said, "Transparent, consistent processes, aligned
with the policy objectives, but that does not mean a dispensation towards
assuming inclusion, or that 'If you did the work, and got an audit, you
should be trusted'. This process is one of risk management, and that cannot
and should not be abdicated."[7] In that list posting, Ryan also raised
the following four points:
1. Root CAs have significantly less experience reviewing the
inclusion of CAs, including CP/CPS reviews.
2. Root CAs are primarily focused on their perceived risks, which are
indirect proxies for user risk, as opposed to being directly focused on
user risks
3. Root CAs do not generate the same degree of transparency,
artifacts and records as the public review process.
1. For example, we have no such record of a detailed CP/CPS review
(although, to the prior two points, it's questionable to what extent it
would be aligned with community needs)
2. We have no discussion and/or transparency as to Root CAs'
processes for conducting such reviews
3. We have no transparency into any commitments and/or
representations made
4. In practice, the risk is greater, not less, because any issues now
present two CAs to remediate, rather than one.
Matt Palmer argued that initial due diligence by a Root CA operator would
not be as thorough as one done by the module owner.
In support of the argument that Mozilla cannot rely on the due diligence of
the root CA operator, Andrew Ayer pointed to a statement in the Certainly
CP/CPS concerning domain control validation ("In exceptional cases control
may be validated using methods similar to those employed by ACME, but
performed manually.") That sentence was subsequently deleted from the
Certainly CP/CPS.
Brittany Randall, on behalf of GoDaddy, provided documentation of the due
diligence performed by GoDaddy. (See Comment 9 in Bug 1755851
<https://bugzilla.mozilla.org/show_bug.cgi?id=1755851#c9>.)
An updated CP/CPS was posted Certainly, and I reviewed that CP/CPS, the
Compliance Self-Assessment, and GoDaddy's review documents and found that
they conformed to MRSP and BR requirements.
Ryan asked whether the level of review conducted was appropriate for the
risk posed to the community, both Mozilla users and those that rely on
Mozilla's process. He argued that GoDaddy's ability to issue external CAs
was the equivalent of a "trust list" or "Super CA". He asked whether a
value quantification needed to be performed. He also noted problems with
the Certainly CP/CPS (which Certainly and GoDaddy have since committed to
address). In conclusion, Ryan stated, "Unless we're willing to say that
we're predisposing the conversation and biased in Certainly's favor, then
it seems the only way to mitigate that risk is to treat the intermediate
signing with the same degree of care and caution as the root, and to accept
that any decision about the intermediate is functionally, technically, and
procedurally identical to a decision about the root. If we're not willing
to say 'OK, we can skip all root discussion' based on this thread, then I
don't believe it should proceed here. And I don't believe we should skip
the root discussion."[8]
*Close of Public Discussion and Intent to Approve **Request*
Mozilla appreciates the many who have reviewed the documentation and made
comments on this matter. Mozilla is open to suggestions that will improve
the process going forward. However, we currently see two distinct processes
– the root inclusion process and this new process for approving externally
operated unconstrained subordinate CAs. While the risks presented by a root
and an intermediate may be very similar, they are not identical. For
example, a root certificate can issue other CA certificates, which
introduces the risk that a CA certificate will be mis-issued. While the
intermediate CA certificates proposed here cannot be used to issue CA
certificates, and can only be used to issue DV server certificates. They
can also be easily distrusted by adding them to OneCRL, unlike a root,
which must be removed from the trust store. Therefore, we are not inclined
to require that Certainly complete the root inclusion process before moving
forward as a sub CA.
This is notice that I am closing public discussion and that it is Mozilla’s
intent to approve GoDaddy's request for the reasons explained
below. (Certainly will still need to complete the root inclusion process
and provide a risk-vs-value justification for inclusion of its roots.)
Certainly has been audited under the WebTrust for CAs principles and
criteria[9]. GoDaddy has conducted thorough policy, compliance, and risk
management due diligence related to the cross-signing of the Certainly sub
CAs.[10] Because GoDaddy is putting its own root at risk, such reviews have
gone beyond the minimum requirements of Mozilla and the CA/Browser Forum's
Baseline Requirements. GoDaddy's well-documented onboarding of Certainly
has included multiple reviews of its audit reports, risk assessments,
CP/CPS, training materials, and other documentation. GoDaddy has conducted
a CP/CPS alignment review to compare the Certainly CP/CPS with its own CPS
and has tracked changes to be made in both parties' CP/CPSes to not only
ensure consistency, but to also address the comments that have been
received during this public discussion process. GoDaddy's risk management
department will conduct ongoing oversight of Certainly's compliance with
requirements and hold quarterly touch-point meetings with Certainly.
GoDaddy will also be responsible for ensuring that the CCADB is kept up to
date with current audits and CP/CPSes for the subCAs, and its Governance
and Policy Committee (GPC) will also review updates to the Certainly CP/CPS
to ensure ongoing compliance.
As noted in the above-referenced procedure[1], this begins a 7-day “last
call” period for any final objections.
Thanks,
Ben
[1] https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained
[2]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/bEnn98Dajzc/m/32NwZHWSAAAJ
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1755851
[4] https://www.mozilla.org/en-US/about/manifesto/details/
[5]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1727941
[7]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/bEnn98Dajzc/m/61wX1hOiAQAJ
[8]
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/bEnn98Dajzc/m/58uqrxV7AgAJ
[9] https://bugzilla.mozilla.org/attachment.cgi?id=9264323
[10] https://bugzilla.mozilla.org/attachment.cgi?id=9266002
On Thu, Mar 10, 2022 at 9:15 AM Wayne Thayer <[email protected]> wrote:
> Ryan,
>
> I want to acknowledge that Certainly and GoDaddy are aware of your
> feedback on the CP/CPS and we plan to use it to make improvements. Thank
> you.
>
> Regarding the question of staying current with Boulder releases: Certainly
> automatically tracks new tags and has established a process in which we
> review the changes and deploy updates on a weekly cadence. In practice this
> means that Certainly is typically one Boulder release behind Let’s Encrypt.
> GoDaddy worked with us to understand this process as part of their due
> diligence.
>
> - Wayne
>
> On Sun, Mar 6, 2022 at 8:24 AM Ryan Sleevi <[email protected]> wrote:
>
>>
>>
>> On Fri, Mar 4, 2022 at 5:07 PM Ben Wilson <[email protected]> wrote:
>>
>>> All,
>>>
>>> Today I read through the Certainly CP/CPS and reviewed the Compliance
>>> Self-Assessment and GoDaddy's review documents. I did not see anything in
>>> the CP/CPS that did not conform to the Mozilla Root Store Policy or the
>>> CA/B Forum's Baseline Requirements.
>>>
>>> I also looked at the GoDaddy-Fastly cross-certificate profiles and did
>>> not see anything that concerned me.
>>>
>>> The public comment period will close next Wednesday, 9-Mar-2022. Please
>>> provide any additional comments you may have by then.
>>>
>>
>> Ben,
>>
>> Do you feel this level of review is appropriate for the risk that is
>> posed to the community, both Mozilla users and those that rely on Mozilla's
>> process?
>>
>> Mozilla highlights the thoroughness of its reviews, and the importance in
>> providing careful analysis, as part of the reason that it disallows
>> super-CAs and does not blindly accept third-party trust lists. However,
>> it's difficult even for me to discern what functional difference there is
>> between, say, an EUTL, and what this is: a GoDaddy Trust List. If Mozilla
>> is providing unique value above and beyond a cursory review, then it
>> suggests that value needs to be applied equally, because as widely
>> understood, every new CA introduces risk to the ecosystem.
>>
>> Having worked with Wayne for years, I am sure that, in the long run, this
>> may be a net positive. However, I'm personally uncomfortable with the
>> premise here that this is either lower risk or an appropriate level of
>> review. From Andrew's remarks going unaddressed (until the reping), from a
>> lack of feedback from GoDaddy about their own processes for review, it
>> doesn't seem like things were prepared for total transparency in mind. As a
>> simple example of one of the *many* ways in which the risk is the same,
>> but this parallel process bypasses those checks, is that there has not
>> been, AFAICT, any quantification of value [1] yet. Is the view that somehow
>> intermediates don't need this?
>>
>> When we look at risk, I cannot help but look at recent issues with CAs
>> operated by cloud providers and CDNs, and wonder if perhaps they introduce
>> more risk, rather than less. When I look at [2], which is from a different
>> CA, we see a large cloud provider prioritizing "zero impact", by wholly
>> ignoring their compliance obligations and proposing to, effectively, do
>> nothing to remediate. In the past, this sort of approach has lead to CAs
>> being distrusted, but when it's a CA this large, the risk calculus makes
>> having such a frank conversation more difficult, both because the size of
>> the organization and the size of the userbase impacted. It equally
>> demonstrates the challenge of having a CA tightly integrated with a hosting
>> provider, as it may limit the ability to quickly replace certificates,
>> either from the same CA or from a new CA, a situation we also saw with
>> WoSign/StartCom (and Azure China) and which complicated the removal of
>> trust in that CA.While it's good to see Certainly is based on ACME, there's
>> a real risk that the integration, by virtue of only targeting a single user
>> base, may end up a "bespoke" ACME (tied to a particular implementation),
>> and limit and impair agility at the parent organization (Fastly).
>>
>> Do not get me wrong: I think that the ecosystem has the potential to
>> benefit here. However, I do think that this push for inclusion seems
>> inconsistent with past and recent statements about the value provided by
>> Mozilla through the Mozilla Root Program, and see it difficult to square in
>> consideration for super-CAs and trust lists, in which each individual CA
>> must go through the Root Inclusion Process for consideration. Why would
>> this not apply to new entities and new CP/CPSes, given they are
>> functionally identical?
>>
>> I have not done a detailed CP/CPS review as I would normally do, in part,
>> because there are not the supporting materials that normally exist by the
>> point that I would do such a thing. I am concerned that the
>> "Self-Assessments" may have moved from a "thing to benefit the CA" and into
>> a "thing the Root Program relies on," and I do worry about that. I do want
>> to make it clear: Despite the thoroughness of my comments here, I did not
>> do my normal deep review here, and I would not rely on this as a "Hey, this
>> is proof that if this is all he found, we're fine" - it's simply a quick
>> scan of concerns:
>>
>> - 1.3.2 notes that RA functions are not delegated, but the section is
>> titled "Registration Authorities and other delegated third parties". In
>> Section 1.3.5, it notes that "Certainly vendors and service providers that
>> have access to confidential information or privileged systems ...",
>> suggesting that there may be at least some functionality that is delegated
>> to third parties. 1.3.2 of the BRs allows for delegating the RA functions
>> (Section 3.2) to DTPs, but the definition within 1.6.1 of the BRs makes it
>> clearer that a DTP applies to any delegation of function. That is, the BRs
>> allow for either 3.2 functionality (e.g. as supported by 4.2.1 of the BRs)
>> or any other function other than 3.2.2.4/3.2.2.5 (supported by 5.3.7
>> and 5.4.1 - related to ISMS and not just RA functions)
>> - 1.4.1 limits the certificates to use with the TLS protocol, and
>> 1.4.2 prohibits any other use. What does this mean for QUIC, which Fastly
>> supports [3]? I realize the extent that QUIC repurposes the TLS handshake,
>> but it is a different protocol [4].
>> - A brief scan of 1.6.1 shows that there are subtle differences in
>> the definitions between Certainly's CP/CPS and the BRs. That's _not_
>> problematic in and of itself, but requires careful scrutiny to review that
>> the meaning and obligations are preserved throughout the entire document
>> and are consistent under these modified definitions.
>> - 1.6.3's references are unversioned. There are various semantic and
>> syntactic differences in X.509, for example, up to and including the
>> recent
>> changes to the underlying model [5], that these differences may matter,
>> even if there is a "common sense" understanding one might take.
>> - 3.1.4 gives conflicting advice in terms of understanding the
>> construction of names. With respect to DNs, this is the opportunity to be
>> unambiguous about the name forms employed (presumably, C and CN) and their
>> interpretation - and limits.
>> - 3.1.6 states "Certainly reserves the right to refuse to include a
>> domain name within a Certificate". This right seems to go beyond those
>> otherwise enumerated by the BRs (e.g. scenarios contemplated within
>> 4.9.1),
>> and so it's unclear when, why, and how this right might be exercised. I
>> anticipate that Certainly wouldn't want to give up this right, even if
>> it's
>> not strictly necessary, but it perhaps bears elaborating why this
>> reservation is seen as necessary and how it might be exercised.
>> - 3.1.6 seems to suggest that, independent of the UDRP, Certainly may
>> make its own determinations about the right or authorization to use a
>> domain name. That seems suboptimal.
>> - 3.2.5 appears that Certainly have read the BRs 3.2.5 as [If A then
>> (B, C, and D)], rather than [(If A then {B, C}), and D]. That is, whether
>> the "In addition" in the terminal paragraph joins to the first condition
>> (if the Applicant ... is an organization), or whether it states an
>> procedure that is applicable for all Applicants, and not just those that
>> are organizations. While understandably the BRs can benefit from clarity
>> here, it bears calling out, because as a consequence, they provide no such
>> method to limit accounts that can request certificates, made explicit in
>> 4.2.1
>> - 7.1 does not list all of the RFC 5280-required fields and
>> extensions within the relevant profiles. This raises the question of
>> whether they are "permitted, but unspecified", "prohibited, but not
>> omitted, violating the CP/CPS", or "prohibited, but omitted, violating
>> 5280". Taking the more generous first interpretation, on the basis of the
>> first sentence in this section, it seems clearer to explicitly document
>> the
>> fields that will be included within the profile, and ensure no fields are
>> included without a corresponding CP/CPS update.
>> - 7.1 uses a rather long OCSP signing certificate (5 years), without
>> documentation (AFAICT) of the corresponding key protection. Given the
>> description of the tradeoffs of OCSP no-check, it seems like a shorter
>> lifetime reduces risks/concerns.
>>
>> Yes, there are positives to Certainly, and I do want to acknowledge that:
>>
>> - 1.4.1 makes it clear that they only issue DV certificates
>> - 2.1 gives a very clear SLO for Repository services
>> - 3.1.4 makes it clear that homographs are not a PKI-layer problem
>> - 7.2 provides a CRL profile that is meaningful
>>
>> Further, I think there are elements of operational transparency that
>> would be addressed by Certainly. For example, as far as I know, Boulder
>> does not have any "release" process, but rather works through an
>> iterative CI/CD workflow with weekly tags. It's unclear how Fastly tracks
>> changes within Boulder, and how frequently and quickly they are deployed.
>> Obviously, this concern exists in equal measure for non-Boulder CAs (e.g.
>> EJBCA), and we've seen a number of CAs have very poor processes around such
>> management, so it's reasonable to understand how Certainly is doing things
>> different.
>>
>> I realize this sounds like I'm making a purely process argument, but I do
>> sincerely believe that it would be a net-negative for Mozilla users to
>> continue this intermediate inclusion without the corresponding broader root
>> discussion, and in particular, the discussion of both value and risk, to
>> understand how Certainly is addressing this. The current policies around
>> intermediates were developed both on the perceived risk to the ecosystem,
>> and the actual risk demonstrated by a CA who failed to meet the criteria
>> for inclusion of its root, but which had already obtained and was operating
>> an intermediate. Unless we're willing to say that we're predisposing the
>> conversation and biased in Certainly's favor, then it seems the only way to
>> mitigate that risk is to treat the intermediate signing with the same
>> degree of care and caution as the root, and to accept that any decision
>> about the intermediate is functionally, technically, and procedurally
>> identical to a decision about the root. If we're not willing to say "OK, we
>> can skip all root discussion" based on this thread, then I don't believe it
>> should proceed here. And I don't believe we should skip the root discussion.
>>
>> [1] https://wiki.mozilla.org/CA/Quantifying_Value
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1743943
>> [3] https://www.fastly.com/blog/state-of-quic-and-http3-2020
>> [4] https://www.fastly.com/blog/quic-is-now-rfc-9000
>> [5] https://www.itu.int/rec/T-REC-X.501-202110-I!Amd1/en
>>
>> --
>> 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/CAErg%3DHEJ1g1GA6QnwJ2G5a3cXRL7Jcvu%2Bs4JZbAeZYipQkdXxQ%40mail.gmail.com
>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEJ1g1GA6QnwJ2G5a3cXRL7Jcvu%2Bs4JZbAeZYipQkdXxQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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/CAPh8bk_nUp_F9TB35AtwNZ8%2Bi%3Df66g1y3jvGNS%2BQfUy_j9b7_Q%40mail.gmail.com
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPh8bk_nUp_F9TB35AtwNZ8%2Bi%3Df66g1y3jvGNS%2BQfUy_j9b7_Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CA%2B1gtabKNVjVtCer8RW318nFVRQ7b6_tFAhVbPq6LFfm%2BLkbiA%40mail.gmail.com.
