On Wednesday, 8 July 2020 05:02:56 UTC+2, Ryan Sleevi wrote: > On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx66669--- via > > dev-security-policy wrote: > > > Can't the affected CAs decide on their own whether to destroy the > > > intermediate CA private key now, or in case the affected intermediate CA > > > private key is later compromised, revoke the root CA instead? > > > > No, because there's no reason to believe that a CA would follow through on > > their decision, and rapid removal of trust anchors (which is what "revoke > > the root CA" means in practice) has all sorts of unpleasant consequences > > anyway. > > > > Er, not quite? > > I mean, yes, removing the root is absolutely the final answer, even if > waiting until something "demonstrably" bad happens. > > The question is simply whether or not user agents will accept the risk of > needing to remove the root suddenly, and with significant (e.g. active) > attack, or whether they would, as I suggest, take steps to remove the root > beforehand, to mitigate the risk. The cost of issuance plus the cost of > revocation are a fixed cost: it's either pay now or pay later. And it seems > like if one needs to contemplate revoking roots, it's better to do it > sooner, than wait for it to be an inconvenient or inopportune time. This is > why I meant earlier, when I said a solution that tries to wait until the > 'last possible minute' is just shifting the cost of misissuance onto > RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to > shift costs onto the ecosystem like that seems like it's not a CA that can > be trusted to, well, be trustworthy.
Wouldn't be enough to check that OCSP responses are signed with a certificate which presents the (mandatory, by BR) id-pkix-ocsp-nocheck? I've not checked, but I don't think that subordinate CA certificates have that extension _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
