On 17/2/2022 5:50 μ.μ., Ryan Sleevi wrote:
On Thu, Feb 17, 2022 at 1:10 AM 'Brittany Randall' via
[email protected] <[email protected]> wrote:
This email begins a 3-week comment period, after which Mozilla is
expected to consider approval of GoDaddy’s request.
My individual position would be that GoDaddy does not perform this
signing unless, and until,
https://bugzilla.mozilla.org/show_bug.cgi?id=1727941 is resolved with
a positive disposition.
I think there's wide agreement and understanding that the security
risks to the community, and to end users, remains, at minimum, the
same whether introducing a root or an intermediate, as they both have
the same capability. Cross-signing an intermediate versus adding a
root largely only functionally differs in that rather than Mozilla and
the community reviewing the CA-to-be-signed, the cross-signer performs
that review. I don't think we have reason to be confident in the
general case that CAs are effective at upholding the same principles
or thoroughness as the current Mozilla process was designed to engage
and promote. I don't mean this as a slight against GoDaddy, but rather
the general principle.
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.
The public review policy for intermediates was designed to address
this gap, by ensuring intermediates and roots undergo the same level
of public review and consideration. It applies for two cases:
1) Where the CA-to-be-signed does not plan to operate as a root
2) Where the CA-to-be-signed does plan to operate as a root (as is the
case here)
Strangely, 1) is a bit academic, because there's very little
compelling reason to pursue that path given the above considerations,
so it's not surprising that we find ourselves in 2).
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.
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 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 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.
For this specific request, besides your good comments about Wayne and
his familiarity with existing policies, I will add that Fastly is a very
active Interested Party member in the CA/Browser Forum Server
Certificate WG with lots of contributions and not just from Wayne.
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.
Dimitris.
--
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/940cb19e-4c91-cc60-73be-2a05d988e4a2%40it.auth.gr.
