Hey Benjamin, Thanks for the review, I’ve replied to your two comments inline:
> On Sep 30, 2019, at 6:06 PM, Benjamin Kaduk via Datatracker > <nore...@ietf.org> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-acme-ip-07: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-acme-ip/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 7 > > There's perhaps some "action at a distance" going on here, in that we > try to apply normative requirements on unrelated things. Perhaps it's > safer to just say "this document does not define any usage of the > 'dns-01' challenge to validate IP addresses. But if we can definitively > rule out any future use, then it doesn't really matter. There is currently no way to use the dns-01 method as specified in 8555 for IP addresses. Including a MUST NOT here was mainly a belt and bracers attempt to prevent future implementers from attempting to come up with a novel way of applying the method (there was initially some work in this document that did try to do this, but there were enough security concerns with the method proposed that the work was discarded.) > > Section 9 > > Is there anything to say about issuing certificates for > non-publicly-routable IP addresses in terms of ensuring that the ACME > server and client are in the same administrative domain [and enforcing > that by network topology]? > I feel like this gets into dictating a level of policy that I’m not comfortable with in this document, especially given the wide and varying topologies that exist within enterprise networks which we are unlikely to be able to properly document and restrict (and is likely better served by internally dictated policies rather than at the standards level). _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
