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.
