On Fri, Feb 18, 2022 at 1:36 AM Dimitris Zacharopoulos <[email protected]>
wrote:
> I believe this is not correct. The security risks to the community are
> different because in the cross-signing/externally-operated subCA model, the
> Subordinate is under the close supervision of the signing (already
> publicly-trusted) CA, compared to the individual Root which stands on its
> own.
>
In the event it was not clear, I very much disagree with this position,
which is why I do not think it advisable to proceed at present.
1. Root CAs have significantly less experience reviewing the inclusion
of CAs, including CP/CPS reviews.
2. Root CAs are primarily focused on their perceived risks, which are
indirect proxies for user risk, as opposed to being directly focused on
user risks
3. Root CAs do not generate the same degree of transparency, artifacts
and records as the public review process.
1. For example, we have no such record of a detailed CP/CPS review
(although, to the prior two points, it's questionable to what extent it
would be aligned with community needs)
2. We have no discussion and/or transparency as to Root CAs'
processes for conducting such reviews
3. We have no transparency into any commitments and/or
representations made
4. In practice, the risk is greater, not less, because any issues now
present two CAs to remediate, rather than one.
If we accept the conclusion that the risks are different, then similarly,
it would seem that any restrictions upon Super CAs, or any concerns with
Trust Service Lists, are unfounded, because they cannot be reasonably held
positions when delegation of subordinate signing is seen as less risky. In
all three cases, it works out the same: the delegation of security
functions to external parties. While in theory, differences can be
suggested ("Super CAs aren't as experienced", "the TSL isn't accountable"),
those arguments don't stand up under scrutiny.
At fundamental question is whether the goal of a Root Program is to ensure
a thorough supervision and vetting of all CAs in the program, in order to
protect from user risk. If that is the argument, then it stands to reason
that subordinate CAs from new entities should not be introduced unless and
until that vetting has occurred, to the same level of detail, and with the
same processes in place to ensure the right result. To do otherwise is to
effectively secure a loan of "trust" based on collateral that is
exceedingly difficult (technically and policy) to repossess if mistakes are
made, and relying on some undocumented, opaque assurance that due
dilligence has occurred. If we were trying to develop real estate in New
York, that might be the norm, but this isn't the Big Apple.
> There are cases where a CA wants to operate independently, without any
> third-party supervision. This is the most common scenario that's why option
> 2 is what we usually see. However, there are cases where a company wants to
> operate a subCA under the guidance and supervision of another CA, which
> uses option 1. CCADB includes cases that prove that both options exist
> today.
>
While this is true, exceeding from the incident reports has been an active
discouragement for option 1, because it does not, in practice, work. The
past decade has been very much towards Option 2 as the only option, which
is exactly why unaudited sub-CAs were sunset, why technically constrained
CAs are still required to be audited by some root programs (independent
of/despite the BRs carve outs), and overall, why cross-signing is being
limited in favor of direct integration of the root.
> This is not to say that the trust impact of an externally-operated Sub CA
> vs a Root CA are not similar, but it is reasonable to assume that when an
> already-trusted CA member of this community (in good standing)
>
> - accepts the liability and reputational risks,
> - places sufficient controls to monitor the operations/compliance program
> of an externally-operated SubCA,
>
It's reasonable to state it's reasonable, but it's not actually reasonable.
The suggestion here of reputational risks is somewhat suspect, given that
certificates are undifferentiated fungible commodities, in which reputation
plays little overall effect in the selection. The extent reputational
concern is an issue is developing a "bad reputation" that might lead to
distrust, and that's precisely why the risk is greater, because it's an
activity that carries with it profoundly high risk. For example, do we
believe that it would at all be a labor-free endeavour to contemplate
removing trust in GoDaddy if Certainly routinely violated requirements? I
think the significance of GoDaddy's extant operations in the broader
Internet at large would, if anything, suggest that Certainly would have far
more opportunities to make mistakes that are overlooked, precisely because
of the desire to avoid distrusting GoDaddy.
The second point here is that we should assume controls are sufficient,
when we have shown repeatedly, through a variety of CA incidents, the lack
of controls. To that end, GoDaddy's discussion has failed to even detail
the controls, such as those learned from other CAs, and based on GoDaddy's
past incidents regarding being unaware of other CAs' remediations, it seems
unlikely to just assume those controls exist. However, even if controls
existed, the degree of transparency around those controls and their routine
functioning doesn't exist.
Would it be better if GoDaddy regularly engaged in Detailed Control
Reports, required those of Certainly, and made both of those publicly
available? Sure, that might be a path towards a sufficient degree of
transparency. But we won't see that within the next few weeks, and that
still fits in the broader question about what it should look like for all
CAs.
Neither of these points holds up under scrutiny, and equally, they don't
hold up with made generic across all CAs. To the extent we cannot assume
that the small CA with only 5,000 certificates is capable and
knowledgeable to fully audit new entrants, we shouldn't assume the CA with
50 million certificates is any more, because they are different skills than
traditional issuance.
> it is sufficient for the community to accept. Taking it one step further,
> I would say that this scenario (operating under the guidance/supervision of
> an already-trusted Root CA) is actually MORE trustworthy than an
> independent Root being accepted for which the community has no visibility
> about internal operations/compliance program apart from an audit report and
> self-evaluation.
>
I hope I have put to bed how flawed this conclusion is, but since
sometimes, the horse must be beaten to glue for the argument to stick: by
this logic, it would suggest that the ecosystem would be better without any
root review, and instead delegate to a set of Super CAs, with each Super CA
accountable to the browser. I think most folks would recognize that as the
antithesis of the direction we should go in, but that's logically where a
conclusion of MORE trustworthy takes things.
> I assume that GoDaddy and any CA that plans to cross-sign a CA that is new
> to this community, performs a similar analysis/due diligence as Ben and the
> community does in Root inclusion requests. Three weeks should be sufficient
> for additional review/scrutiny by any other member but if more time is
> needed, people can just ask.
>
There is no basis for that assumption, nor data to support it.
> I believe it would be unfair to delay this application more than the
> current Mozilla Policy dictates on the grounds that there is a pending Root
> inclusion request by Certainly. They could just as well not have applied
> for a Root inclusion.
>
The goal is to protect users, not "fairness". Transparent, consistent
processes, aligned with the policy objectives, but that does not mean a
dispensation towards assuming inclusion, or that "If you did the work, and
got an audit, you should be trusted". This process is one of risk
management, and that cannot and should not be abdicated.
Had Certainly not applied for a Root Inclusion, I would be actively
encouraging that the request be rejected entirely, precisely for the same
reasons here: the risk of a subordinate is indistinguishable to end users
from that of a root, while the risk to the process and policies is even
greater. The march has been towards containing that risk, and, consistent
with concerns raised about delegating trust to third-parties such as
governments, not one that should be lightly abdicated, least of all because
"of a misguided goal to fairness over security.
--
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%3DHGFgA3QbG9SrqYy2P7BxiE6p7gkBsTCk-ka1LPfU_cD8g%40mail.gmail.com.
