On Thu, Jul 2, 2020 at 6:05 PM Pedro Fuentes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I understand your rational, but my point is that this is happening in the
> same infrastructure where the whole PKI is operated, and under the
> responsibility of the same operator of the Root. In my understanding the
> operator of the Root has full rights to do delegated OCSP responses if
> those responses are produced by its own OCSP responders.
>
> I'm failing to see what is the main problem you don't consider solved. As
> per your own dissertations in the related posts, there are two issues:
>
> 1. The certificate contains incorrect extensions, so it's a misissuance.
> This is solved by revoking the certificate, and this is done not only
> internally in the PKI, but also in OneCRL.
>

This solves *nothing* for anyone not using OneCRL. It doesn't meet the
obligations the CA warranted within its CP/CPS. It doesn't meet the BRs. It
simply "shifts" risk onto everyone else in the ecosystem, and that's a
grossly negligent and irresponsible thing to do.

"Revoking the certificate" is the minimum bar, which is already a promise
the CA made, to everyone who decides to trust that CA, that they will do
within 7 days. But it doesn't mitigate the risk.


> 2. The operator of the SubCA could produce improper revocation responses,
> so this is a security risk. This risk is already difficult to find if the
> operator of the subCA is the same operator of the Root... If such entity
> wants to do a wrongdoing, there are far easier ways to do it, than
> overcomplicated things like unrevoking its own subCA...
>
> Sorry, but I don't see the likeliness of the risks you evoke... I see the
> potential risk in externally operated CAs, but not here.


The risk is just the same! As a CA, I can understand you would say "Surely,
we would never do anything nefarious", but as a member of the community,
why should we trust what you say? Why would the risk be any different with
externally operated CAs? After all, they're audited to, like roots,
shouldn't the risk be the same? Of course you'd realize that no, they're
not the same, because the CA has no way of truly knowing the sub-CA is
being nefarious. The same is true for the Browser trusting the root: it has
no way of knowing you're not being nefarious.

Look, we've had Root CAs that have actively lied in this Forum,
misrepresenting things to the community they later admitted they knew were
false, and had previously been an otherwise CA in good standing (or at
least, no worse standing than other CAs). A CA is a CA, and the risk is
treated the same.

The line of argument being pursued here is a bit like saying "If no one
abuses this, what's the harm?" I've already shown how any attempt to
actually verify it's not abused ends up just shifting whatever cost onto
Relying Parties, when it's the CA and the Subscribers that should bear the
cost, because it's the CA that screwed up. I simply can't see how "just
trust us" is better than objective verification, especially when "just
trust us" got us into this mess in the first place. How would you provide
assurances to the community that this won't be abused? And how is the cost
for the community, in risk, better?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to