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. 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. El jueves, 2 de julio de 2020, 23:33:05 (UTC+2), Ryan Sleevi escribió: > On Thu, Jul 2, 2020 at 5:30 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hello Ryan, > > Thanks for your detailed response. > > > > Just to be sure that we are in the same page. My question was about > > reissuing a new CA using the same key pair, but this implies also the > > revocation of the previous version of the certificate. > > > > Right, but this doesn't do anything, because the previous key pair can be > used to sign an OCSP response that unrevokes itself. > > This is the problem and why "key destruction" is the best of the > alternatives (that I discussed) for ensuring that this doesn't happen, > because it doesn't shift the cost to other participants. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
