On Sat, Jul 4, 2020 at 3:15 PM Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> ...especially since many of those millions of certificates are not even > TLS certificates and their consumers never expected the hard revocation > deadlines of the BRGs to be of any relevance for them. And therefore they > didn't design their infrastructure to be able to do an automated > mass-certificate exchange. > This is a clear, straightforward statement of perhaps the single biggest core issue that limits the agility and security of the Web PKI: certificate customers (particularly large enterprises) don't seem to actually expect they may have to revoke many certificates on short notice, despite it being extremely realistic that they may need to do so. We're many years into the Web PKI now, and there have been multiple mass-revocation events along the way. At some point, these expectations have to change and result in redesigns that match them. As Ryan [Sleevi] said, neither Mozilla nor Google employ some binary unthinking process where either all the certs are revoked or all the CAs who don't do it are instantly cut loose. If a CA makes a decision to not revoke, citing systemic barriers to meeting the security needs of the WebPKI that end users rely on, their incident reports are expected to describe how the CA will work towards systemic solutions to those barriers - to project a persuasive vision of why these sorts of events will not result in a painful crucible going forward. It's extremely convenient and cost-effective for organizations to rely on the WebPKI for non-public-web needs, and given that the WebPKI is still (relatively) more agile than a lot of private PKIs, there will likely continue to be security advantages for organizations that do so. But if the security and agility needs of the WebPKI don't align with an organization's needs, using an alternate PKI is a reasonable solution that reduces friction on both sides of the equation. -- Eric Mill 617-314-0966 | konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
