On Wed, Apr 22, 2015 at 6:23 PM, Bruce Gaya <[email protected]> wrote: > > On 22 Apr 2015, at 15:10, Richard Barnes <[email protected]> wrote: > > > > On Tue, Apr 21, 2015 at 10:53 PM, Bruce Gaya <[email protected]> wrote: > >> >> On 21 Apr 2015, at 18:23, Salz, Rich <[email protected]> wrote: >> >> I understand that you want it to “just work” (you said that a couple of >> times :), but other folks have raised security concerns – do you understand >> or agree with them? >> >> >> I agree that client access to ports below 1024 usually requires more >> privileges and that’s generally safer than allowing any client port. >> > > So would you be OK with the spec saying that the server MUST reject > client-specified ports that are greater than 1023? > > > Yes. > > Because the ACME client code will run as root any unused port will work so > I am happy with this restriction. My intention is for the ACME client to > be as independent as possible from other running services. > > > >> One way forward is to say a client MAY specific a port, where the default >> is 443. An ACME server MAY reject requests for ports other than 443 if it >> is in violation of the operating policy. >> >> >> That would work. >> > > Let's return to the question of protocol, however. The CA needs to know > how to validate the challenge. Are you envisioning that this would be an > extension to the simpleHttps challenge, so that the validation would still > be done using an HTTP request to a .well-known URI, just on a different > port? > > > Yes. As a developer, it’s easier to have the ACME code be completely > separate rather than coordinate with another process. >
OK. That at least seems well-defined to me. I could probably live with it if others are comfortable. --Richard > > Bruce >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
