Before getting into specifics, I should say that you're likely to get a better answer to most of these question on the IETF ACME WG mailing list[1].
On 08/07/16 16:36, Peter Kurrasch wrote: > 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)? The IETF has a working group for ACME that's developing this protocol. The IETF process is hard to describe in a couple of words (you can read up on it on ietf.org if you're interested). Other related protocols such as TLS are developed in a similar fashion. > How are compatibility issues being addressed? Boulder (the only ACME server implementation right now, AFAIK) plans to tackle this by providing new endpoints (i.e. server URLs) whenever backwards-incompatible changes are introduced in a new ACME draft, while keeping the old endpoints available and backwards-compatible until the client ecosystem catches up. I imagine once ACME becomes an internet standard, future changes will be kept backwards-compatible (i.e. "extensions" of some sort), but that's just me guessing. > Has any consideration been given to possible saboteurs who might like > to introduce backdoors? The IETF process is public, which makes this harder (though not impossible) to pull off. A number of people have reviewed and audited the protocol (including a formal model[2]). > I personally don't see the wisdom in having the server > implementation details in what is ostensibly a protocol > specification. Which part of the specification mentions implementation details? > Will there be any sort of audit to establish compliance between a > particular sever implementation and this Internet-Draft? Someone could definitely build tools to check compliance, but who would enforce this, and what happens to a server/client that's not compliant? > 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? See the previous paragraph on compatibility: Server URLs can be considered backwards-compatible; there's currently no protocol version negotiation or something like that. > 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. That's certainly something to keep in mind, but not something that can be solved by the protocol. It's also not specific to ACME clients, the same concern applies to any software that touches keys in the course of normal operation. FWIW, functional ACME client implementations can be written in < 200 LOC, which would be relatively easy to review, and a client would not necessarily need access to the private key of your certificate - a CSR would be sufficient. [1]: https://www.ietf.org/mailman/listinfo/acme [2]: https://mailarchive.ietf.org/arch/msg/acme/9HX2i0oGyIPuE-nZYAkTTYXhqnk _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
