*Ryan,I understand your concern in principle. However, what you are proposing is at the very least a major new requirement, and could be interpreted as being in direct conflict with the existing Process for Review and Approval of Externally Operated Subordinate CAs that are Not Technically Constrained [1], which (as you described) states:When a root CA operator intends to sign a subCA certificate for use by an external, third-party operator that has not previously undergone this review process for the type of certificate that it will be authorized to issue, the root CA operator is responsible for collecting information and performing due diligence similar to that performed by Mozilla on root inclusion requests (i.e. Quantifying Value and other steps not outlined in this wiki page would not be required), and for initiating the public discussion on the Mozilla dev-security-policy mailing listYou will recall participating in the discussion of this policy in 2021 [2], at which time some similar ideas were suggested by others. I acknowledge that Mozilla has the right to perform whatever due diligence they deem appropriate to protect users; however, the decision to do so should not be arbitrary. What you are proposing amounts to a retroactive policy change.I suspect that Mozilla would consider your proposal as part of the related policy 2.8 discussions [3] [4]. That would be an appropriate forum to work out the details and then update the policy for externally operated subCAs.Wayne[1] https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained <https://wiki.mozilla.org/CA/External_Sub_CAs_not_Technically_Constrained>[2] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/mZBO_IIcBQAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/AA5G1bzOwZQ/m/mZBO_IIcBQAJ>[3] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/r9ZeggoH9KA/m/NZwE3TuYAwAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/r9ZeggoH9KA/m/NZwE3TuYAwAJ>[4] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/zBGXSngpwWw/m/aIm4sKXyAAAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/zBGXSngpwWw/m/aIm4sKXyAAAJ>*
On Thu, Feb 17, 2022 at 8:50 AM Ryan Sleevi <[email protected]> wrote: > > > On Thu, Feb 17, 2022 at 1:10 AM 'Brittany Randall' via > [email protected] <[email protected]> wrote: > >> >> >> This email begins a 3-week comment period, after which Mozilla is >> expected to consider approval of GoDaddy’s request. >> > My individual position would be that GoDaddy does not perform this signing > unless, and until, https://bugzilla.mozilla.org/show_bug.cgi?id=1727941 is > resolved with a positive disposition. > > I think there's wide agreement and understanding that the security risks > to the community, and to end users, remains, at minimum, the same whether > introducing a root or an intermediate, as they both have the same > capability. Cross-signing an intermediate versus adding a root largely only > functionally differs in that rather than Mozilla and the community > reviewing the CA-to-be-signed, the cross-signer performs that review. I > don't think we have reason to be confident in the general case that CAs are > effective at upholding the same principles or thoroughness as the current > Mozilla process was designed to engage and promote. I don't mean this as a > slight against GoDaddy, but rather the general principle. > > The public review policy for intermediates was designed to address this > gap, by ensuring intermediates and roots undergo the same level of public > review and consideration. It applies for two cases: > 1) Where the CA-to-be-signed does not plan to operate as a root > 2) Where the CA-to-be-signed does plan to operate as a root (as is the > case here) > > Strangely, 1) is a bit academic, because there's very little compelling > reason to pursue that path given the above considerations, so it's not > surprising that we find ourselves in 2). > > However, this means that the cross-sign review period is, in effect, a way > to "jump the queue", as it were, bypassing the priorities applied to CA > review in order to get to a state where certificates work with Mozilla > products (and broadly, the ecosystem). It's difficult to imagine a scenario > where a positive dispensation is given to a cross-signing, but then later > rescinded for the root; and, in that case, one would expect (as has > happened in the past), that the cross-sign itself would then be prohibited > as well. > > On the upside, the suggestion here is that GoDaddy has reviewed Certainly > to a level that they are satisfied, and given the substantial risk that > GoDaddy would be embracing, it might be reasonable to allow the queue jump > on the principle that GoDaddy is vouching for Certainly. On the downside, > there's likely a form of remuneration involved here, so it may simply be a > "pay for play", except that GoDaddy is the beneficiary for such scheme. > > It's possible for both of these things to be true, and I don't mean to > suggest that they are morally correct or incorrect, but it's worth careful > evaluation when considering the next steps. Certainly is not yet to the > public discussion phase, indicating that there are still a number of > factors to occur, including the detailed CP/CPS review. To try to "do this > right" would suggest that this process be compressed, and where normally > there would be three weeks of discussion *after* a lengthy discussion with > the CA in question (Certainly), that this all happen within three weeks. > Alternatively, it's to suggest that these things are not actually essential > for CA Root Inclusion, since it would be granting Certainly the same > privileges without these having occurred. > > I say this as someone who suspects that Certainly is in good hands, > especially given the stakeholders involved, which notably includes former > Mozilla CA Certificate Policy Owner Wayne Thayer. I realize that, in the > absence of a cross-sign, the widespread interoperability is not yet > achievable. However, it seems to be a feature, not a bug, to ensure a > process of multi-stakeholder review and comment occurs, and that's why I > think coupling the cross-sign to the dispensation of > https://bugzilla.mozilla.org/show_bug.cgi?id=1727941 is an ideal outcome. > It does mean that the benefit of a cross-sign is reduced from "skips the > root inclusion phase" into one of "updates quicker than a new Firefox > release, and works with those that haven't yet updated", but that's still a > hugely valuable outcome, and hopefully not too unreasonable a burden. > > From a prioritization perspective, it might be reasonable to consider > "Another CA has expressed a willingness to cross-sign" as a reason to > prioritize a given CA higher, precisely because it's a CA willing to risk > their reputation for the to-be-signed entity, and thus we can expect some > degree of self-interested due diligence. I have no objections to doing that > in this case, and further discussion later for any gotchas about making > that a general policy principle. But that would still suggest some period > longer than three weeks, to allow for the detailed information gathering > and CP/CPS reviews, and to treat Certainly as any other root from a > policy/process standpoint. > > Knowing Wayne's familiarity with policy and practices, I suspect this > would be a hopefully very streamlined process, as there have been for other > CAs (e.g. Amazon Trust Services) in which long-standing mdsp participants > were involved in the design and establishment. That said, we also have > counter-examples, in which CAs with long-standing participants repeatedly > demonstrate failures to adhere to the minimum expectation, so it's not a > guarantee, just a suspicion :) > > -- > 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%3DHG0ZYEGzVj40XA7c%3DVjjztfj-_qGzOA8BpNFK3n0aQbmw%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHG0ZYEGzVj40XA7c%3DVjjztfj-_qGzOA8BpNFK3n0aQbmw%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/CAPh8bk9SwirHqq0BipaT2GLTxxD9Pn02A8_UD%3D05K51JuM%2Bfzw%40mail.gmail.com.
