I can't see significant differences in terms of transparency between a
new Root and an externally-operated subCA.
At the very least, in the new Root CA case, you *know* there is no
external oversight by another CA. In the externally-operated subCA we
*assume* there is some external oversight by the signing CA, which is
"better than nothing"? I agree that more details of this oversight
process would be useful -if not necessary- to be at least shared with
the community.
My understanding is that users are protected equally by both routes:
- new Root CA, where at least a Root Store Manager performs the initial
due diligence,
- externally-operated subCA, where the issuing CA performs the due
diligence.
In both cases the community has the same amount of time to review the
applications (at least 3 weeks) and dig into the CP/CPS and audit reports.
Dimitris.
On 20/2/2022 7:07 μ.μ., Ryan Sleevi wrote:
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/9afaf807-2ca1-8812-74d5-9337dfa2deba%40it.auth.gr.
