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