Reviewer: John Levine Review result: Ready with Nits This is the ARTART review for draft-ietf-acme-integrations-12. The document is ready with nits. When reading the review keep in mind that your reviewer has limited experience with ACME and none with EST, BRKSI, or TEAP. In each of the four examples, I gather that the servers are already configured to handle subdomains of example.com, per the second para of 7.5 that says it's an error if a client asks for anything else. This is likely obvious if you know about EST, BRKSI, and TEAP, but it would be a kindness to us newbies to note it perhaps just before section 3. In the four examples, EAP and TEAP have pre-authorization as the first step, while the two BRSKI ones just say it's complete. It's not clear whether there's something different about BRKSI pre-auth. If there is, it would be nice to note why, if not, perhaps the TEAP one could take it out and say the first step is complete as the BRSKI ones do. Other than that, the diagrams are quite clear even though they are long. In the Security Considerations, it says that it is expected that the registrar wil use RFC 3007 updates to put records into the DNS. In my admittedly limited ACME experience, it's more common to use a local API to talk to whatever is managing the DNS. (I rolled my own API for my own DNS toaster and acme.sh, because I could.) Is it really limited to RFC 3007 updates? If not, you might want to reword it more generally to say it's going to use something to update the DNS, and if the credentials leak, that would be bad. I agree with the advice to limit the name scope of updates, and if possible the RRTYPEs. My API only lets the ACME client update CAA and TXT records since that's all ACME needs. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
