I agree that we're converging on some rough consensus, but I would frame it (again) slightly differently:
1. ACME needs to validate domain control, not domain+port control, because (1) there is no current mechanism for issuing certificates for domain+port (vs. just domain), and (2) the primary use cases for ACME right now (DV certs, and possibly OV/EV) don't have any notion of ports. 2. Thus the port used for validation needs to be one such that control of the port is effectively control of the domain. If you look at what CAs do today, that basically means the port is 80/443. More generally, it means that the port needs to be specified by the challenge mechanism and not by the client. So that leaves us with 80/443 for the challenges we have today. If people want to define, say, a CalDAV challenge, they can argue for a new challenge type, but ISTM it'll be a hard sell. It's also worth noting that just because we define challenge types doesn't mean any particular CA will support them (that's the point of extensibility). For example, Let's Encrypt doesn't support the "dns-01" challenge. --Richard On Wed, Dec 2, 2015 at 9:43 AM, Salz, Rich <[email protected]> wrote: > Speaking as co-chair, I think Yoav's summary is more accurate. The consensus > in the room at Yokohama was that there is not real support for other than > 443, but that we need to discuss this on the list "one last time." I think > closing discussion is a bit premature, but at this point there seems rough > consensus to not require other than 443. > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
