On Friday, July 1, 2016 at 3:26:52 PM UTC-5, Nick Lamb wrote: > ACME is a protocol intended to become an IETF Standards Track RFC. You are > welcome to read the existing discussions of the protocol, or to participate > (subject to usual IETF rules) https://www.ietf.org/mailman/listinfo/acme. As > with Mozilla's inclusion process the IETF process ends up partly being a test > of endurance, as even simple ideas are dragged out over several months with > posts that have some technical meat being mixed in with axe-grinding and > larger politics. > > Let's Encrypt's implementation of ACME, Boulder, is on github for anyone to > inspect. I am not aware of any independent formal analysis, but it's obvious > from the contributions to Boulder that people outside Let's Encrypt do look > at it.
We'll probably never be 100% sure that ACME or any other protocol doesn't contain serious flaws but we've done quite a bit to build up confidence that ACME is secure. Here's a list, in no particular order: 1) Clearly documented the spec in public. This allows anyone to read it and give us feedback, from day one and into the future. We know that people do look at it and provide valuable feedback (Andrew Ayer and Martin Thomson are good examples). Our server implementation of the spec is also open source. 2) We're working to get ACME standardized in the IETF. This gets us more high quality feedback. 3) We paid to have the cryptography and application security teams at NCC Group audit the spec. This is also true for our boulder software (at least annually). 4) We commissioned a review and formal modeling of the ACME protocol from Karthikeyan Bhargavan (INRA). 5) ACME has proven to be quite solid in production so far. It has been used to safely issue millions of certificates. 6) We have skilled technical staff, community, and partners who helped to build ACME and continue to review and think about it every day. These people are not only skilled, but have strong reputations in the security, cryptography, and open source communities. Like I said, we probably can't ever be 100% sure there aren't serious flaws in ACME, but I think this constitutes pretty reasonable due diligence. If/when the next flaw is found, it'll be found earlier than it might have been due to our transparency. I don't know enough about what StartCom is doing to comment on this thread's actual topic, but I do wish others would use ACME (if ACME doesn't work for someone, let's talk about what we might do to fix that in the IETF working group). If not ACME, then at least something with a well-written public specification. CAs ask the public to trust them and there is no trust without transparency. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
