All good points. I wonder if we need to start with something more basic: setting expectations.
Maybe we need to communicate to all participating CA's that we expect them to perform a security scan of all Internet-facing interfaces. That we expect each interface to be able to pass the OWASP Top Ten. That we expect a scan to be performed at least once per year. To be sure, that's a pretty low bar but I don't know that all CA's could pass even that minimal benchmark today. If so, that's a big problem. Original Message From: Tom Ritter Sent: Thursday, June 30, 2016 11:57 AM On 30 June 2016 at 11:10, Peter Kurrasch <fhw...@gmail.com> wrote: > Very interesting. This is exactly the sort of thing I'm concerned about with > respect to Let's Encrypt and ACME. > > I would think that all CA's should issue some sort of statement regarding the > security testing of any similar, Internet-facing API interface they might be > using. I would actually like to see a statement regarding any interface, > including browser-based, but one step at a time. Let's at least know that all > the other interfaces undergo regular security scans--or when a CA might start > doing them. > > Anyone proposing updates in CABF? In theory I would support this, in practice it has no teeth. There is no (real) accreditation for security reviews, and the accreditations that exist do not, in practice, ensure one with the accreditation is skilled. You can say "APIs must have a security review" or an "adversarial security scan" or a "vulnerability scan", or "manual penetration test", or a "red team assessment" - but the definition of the terms and the skillsets of people performing them vary so widely that it would not guarantee very much in practice. I believe that the CAs who want to be a leader in this niche already are, and the CAs who cannot afford to do so (because I assume every CA wants to take security seriously, but is confined in practice) will wind up meeting the requirement in a way that does not significantly improve their security. (And various shades in between) But I'm biased, being a security consultant and all. -tom _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
