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.
