From: Eric Mill <e...@konklone.com> Sent: Sonntag, 5. Juli 2020 00:55 To: Buschart, Rufus (SOP IT IN COR) <rufus.busch...@siemens.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; r...@sleevi.com; mark.arno...@gmail.com Subject: Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Sat, Jul 4, 2020 at 3:15 PM Buschart, Rufus via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto: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. [>] Maybe I wasn’t able to bring over my message: those 700 k certificates that are hurting us most, have never been “WebPKI” certificates. They are from technically constrained issuing CAs that are limited to S/MIME and client authentication. We are just ‘collateral damage’ from a compliance point of view (of course not in a security pov). In the upcoming BRGs for S/MIME I hope that the potential technical differences between TLS certificates (nearly all stored as P12 files in on-line server) and S/MIME certificates (many of them stored off-line on smart-cards or other tokens) will be reflected also in the revocation requirements. For WebPKI (aka TLS) certificates, we are getting better based on the lessons learned of the last mass exchanges. 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. [>] But we are talking in S/MIME also about “public needs”: It’s about the interchange of signed and encrypted emails between different entities that don’t share a private PKI. -- Eric Mill 617-314-0966 | konklone.com<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkonklone.com%2F&data=02%7C01%7Crufus.buschart%40siemens.com%7Cf2f26fa2fbe34263c93808d8206d650e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637295001505543267&sdata=6H0qC1Ag9B1vuJ05d2BFrvaL0WBv5grib86q2NOSLuA%3D&reserved=0> | @konklone<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fkonklone&data=02%7C01%7Crufus.buschart%40siemens.com%7Cf2f26fa2fbe34263c93808d8206d650e%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637295001505543267&sdata=7MwPiz4jDprx9fNj8gcwq6W59s6VcZ46yotvY4dsqTs%3D&reserved=0> With best regards, Rufus Buschart Siemens AG Siemens Operations Information Technology Value Center Core Services SOP IT IN COR Freyeslebenstr. 1 91058 Erlangen, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens<http://www.twitter.com/siemens> www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> [cid:image001.gif@01D6526A.82B24320] Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
