Forgive the top posting, but I want to be sure I understand something.  If
the client specifies a port that is below 1024 but canonically used for
something else, what is the specified behavior?  My reading of the thread
so far is that the server would expect to run ACME over it, even if were
specified for, say, LDAP (389).

Is that what folks expect?

Ted

On Wed, Apr 22, 2015 at 3:24 PM, Richard Barnes <[email protected]> wrote:

>
>
> 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
>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to