All, Public discussion and the 7-day last-call period recently ended[1], and Certainly's request to include its R1 and E1 root CAs in the root store has been approved[2]. The purpose of this email is to clarify that GoDaddy's request to cross-sign Certainly's issuing CAs[3] is similarly approved. GoDaddy and Certainly have successfully completed the Process for non-Technically Constrained Subordinate CAs[4].
Thanks, Ben [1] https://groups.google.com/a/ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/EhXhiHfWGC8/m/3PcJHizqAAAJ> mozilla.org/g/dev-security-policy/c/EhXhiHfWGC8/m/ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/EhXhiHfWGC8/m/3PcJHizqAAAJ> 3PcJHizqAAAJ <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/EhXhiHfWGC8/m/3PcJHizqAAAJ> [2] h <https://bugzilla.mozilla.org/show_bug.cgi?id=1727941> ttps://bugzilla.mozilla.org/show_bug.cgi?id=1727941 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1755851 [4] https://wiki.mozilla.org/CA/External_Sub_CAs On Thu, Apr 14, 2022 at 2:39 PM Wayne Thayer <[email protected]> wrote: > In a prior message > <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/bEnn98Dajzc/m/csngx9gOAwAJ> > I stated that Certainly would review Ryan's specific comments on our CP/CPS > and make improvements. We have drafted the changes described below and will > include them in the next version of our CP/CPS. > > On Sun, Mar 6, 2022 at 8:24 AM Ryan Sleevi <[email protected]> wrote: > >> >> 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) >> >> > There is no reason for the section title to deviate from RFC 3647 by > adding “and other delegated third parties”, so that will be corrected in > the next CP/CPS update. Certainly does rely on delegated third parties to > meet a few specific requirements. An example would be storing encrypted > backups offsite. A 3rd party penetration tester would be an example of a > vendor with access to confidential information. >> >> >> - 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]. >> >> Certainly certificates are not currently deployed to the Fastly CDN, or > any service that supports QUIC. This section of the CP/CPS will be updated > to eliminate any future conflict with QUIC. > >> >> - 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. >> >> Certainly’s CP/CPS will be updated to more closely mirror the BR > 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. >> >> We’ll remove this section from our CP/CPS. > >> >> - 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. >> >> We’ll remove the RFC references from this section. > >> >> - 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. >> >> While we do not currently envision a clear scenario in which this right > would be used, consistent with other CAs, we feel that it is important to > reserve this right in the event that we need it to address unforeseen > circumstances. > >> >> - 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. >> >> We’ll remove the final sentence referencing domain name disputes. > >> >> - 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 >> >> Correct. > >> >> - 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. >> >> We’ll add the omitted fields. > >> >> - 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. >> >> This section will be removed as Certainly does not currently perform > delegated OCSP signing, and thus has not signed and does not intend to sign > any OCSP signing certificates. > > Thanks, > > Wayne > -- 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%2B1gtaZhibBiUt%2BVOVK7Uftx_JK%3DxLgH-Yc46aipcE7rf9VX2g%40mail.gmail.com.
