Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme

[Ilari Liusvaara <[e-mail]>]

On Sun, Jan 15, 2017 at 03:11:32PM +0100, Dirk-Willem van Gulik wrote:
> 
> > On 15 Jan 2017, at 15:03, Ilari Liusvaara <[e-mail]> 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).


[1] This is likely a mistake (but it is still allowed). The "SFTP"
is not _Secure_ File Transfer Protocol (shares port 22 with SSH) but
instead _Simple_ File Transfer Protocol... Described in three-digit-
number historic-status RFC, from the 80s...




-Ilari