| At Nick's request, I've changed the subject line. Also, for my part, my comments are not intended to single out ACME to the exclusion of other protocols or implementations to which my comments might equally apply. I see on the gitub site for the draft that updates are frequently and continuously being made to the protocol spec (at least one a week, it appears). Is there any formalized process to review the updates? Is there any expectation for when a "stable" version might be achieved (by which I mean that further updates are unlikely)? How are compatibility issues being addressed? Has any consideration been given to possible saboteurs who might like to introduce backdoors? I personally don't see the wisdom in having the server implementation details in what is ostensibly a protocol specification. Will there be any sort of audit to establish compliance between a particular sever implementation and this Internet-Draft? Will the client software be able to determine the version of the specification under which the server is operating? (I apologize if it is in the spec; I didn't do a detailed reading of it.) On the client side, is there a document describing the details of an ideal implementation? Does the client inform the server to which version of the protocol it is adhering--for example, in a user-agent string (again, I didn't notice one). Is there any test to validate the compliance of a client with a particular version of the Internet-Draft? One thought for consideration is the idea of a saboteur who seeks to compromise the client software. This is of particular concern if the client software can also generate the key pair since there are the obvious benefits to bad actors if certain sites are using a weaker key. Just as Firefox is a target for malware, the developers of client-side software should be cognizant of bad actors who might seek to compromise their software.
On Wednesday, 6 July 2016 09:50:46 UTC+1, Peter Gutmann wrote: > Oh dear God, another one? We've already got CMP, CMC, SCEP, EST, and a whole > slew of other ones that failed to get as far as RFCs, which all do what ACME > is trying to do. What's the selling point for ACME? That it blows up in your > face at the worse possible time? In the examples I've reviewed the decision seems to have been made (either explicitly or tacitly) to leave the really difficult problem - specifically achieving confidence in the identity of the subject - completely unaddressed. ACME went out of its way to address it for the domain we care about around here. Your work on SCEP is probably appreciated by people who aren't interested in that problem, but this forum is concerned with the Web PKI, where that problem is pre-eminent, and this thread is about another provider, StartCom trying and failing to solve that problem. So the answer to your question is that ACME's selling point is that it solves the problem lots of people actually have, a problem which was traditionally solved by various ad hoc methods whose security (or more often otherwise) was only inspected after the fact rather than being considered in advance. I presume the "blows up in your face" comment was purely because of ACME's hilarious choice of name, but if not please elaborate _in a thread about ACME_ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
