Skip to main content

Last Call Review of draft-ietf-acme-integrations-12

Request Review of draft-ietf-acme-integrations
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-01-20
Requested 2023-01-06
Authors Owen Friel , Richard Barnes , Rifaat Shekh-Yusef , Michael Richardson
I-D last updated 2023-01-11
Completed reviews Dnsdir Last Call review of -14 by Ted Lemon (diff)
Dnsdir Last Call review of -15 by Ted Lemon (diff)
Dnsdir Telechat review of -16 by Ted Lemon (diff)
Dnsdir Last Call review of -12 by Ted Lemon (diff)
Artart Last Call review of -12 by John R. Levine (diff)
Secdir Last Call review of -12 by Joseph A. Salowey (diff)
Opsdir Last Call review of -12 by Bo Wu (diff)
Genart Last Call review of -12 by Tim Evens (diff)
Dnsdir Telechat review of -13 by Ted Lemon (diff)
Secdir Telechat review of -13 by Joseph A. Salowey (diff)
Assignment Reviewer John R. Levine
State Completed
Request Last Call review on draft-ietf-acme-integrations by ART Area Review Team Assigned
Posted at
Reviewed revision 12 (document currently at 17)
Result Ready w/nits
Completed 2023-01-11
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, 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, 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.