> On 15 Jan 2017, at 15:29, Ilari Liusvaara <[email protected]> wrote:
>
> On Sun, Jan 15, 2017 at 03:11:32PM +0100, Dirk-Willem van Gulik wrote:
>>
>>> On 15 Jan 2017, at 15:03, Ilari Liusvaara <[email protected]> wrote:
>>>
>>> On Sun, Jan 15, 2017 at 02:50:37PM +0100, Dirk-Willem van Gulik wrote:
>>>> ….
>>>
>>> That's not a new version. It is pre-WG version, published about 1.5
>>> years ago.
>>
>> Ok - so I’ll ignore git - and will take the IETF latest as leading.
>
> There actually is another git repo (ietf-wg-acme/acme) that contains the
> WG draft work. That one is a bit newer than ietf-04 (but shouldn't have
> significant changes).
>
>>> Currently in acme spec, the only ways to do verification without port
>>> 80 are TLS-SNI-02 (uses port 443) and DNS-01 (no connections at all,
>>> relies on DNS exclusively).
>>
>> Ok - and is there any reason why allowing one to specify the port
>> would not be an option/bad idea ?
>
> The list of ports public CAs can use is pretty short (5 ports in fact).
>
>> I am looking at the typical old school unix case - i.e. apache — where
>> one starts up as root and quickly chroots/setuid()s - and where the
>> servers are commonly deployed on port > 1024 by end users.
>
> There actually are restrictions on what ports public CAs can use for
> authentication. These are:
>
> - 80 (HTTP)
> - 443 (HTTPS)
> - 115 (SFTP; no, not _that_ SFTP [1])
> - 25 (SMTP)
> - 22 (SSH)
>
> These limits are exactly so that unprivileged users don't bind
> daemons to the ports and use those to obtain certificates (the
> certificates are valid for all ports).
Just to make sure I understand the reasoning:
CA Policy prohibits an ACME CA Server from fetching the token
(authenticating) from a subscriber port > 1024 (or a port not an element of
[80,443,115,25,22)) because an (on common flavours of unix) an
un(der)privileged) user may run a daemon on such a port.
Correct ? Just so I understand the tradeoffs made correctly when
implementing/mitigating the root-risk on the webserver side.
You would not happen to know where these are documented (I’ve scanned CPS, SA
and policy but no cookie yet).
Dw
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
