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/CAPh8bk8stTeJevzTPRAJaQsYPDxoHbKhRKQ9r5ZwLtzotJwAYg%40mail.gmail.com.
