That just argues for adding for an "https-06" (which is always HTTPS) to go alongside "http-01" (which is always HTTP).
On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote: > But removing the restriction would mean that the CA is free to do either > HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 > is firewalled, I'm still not in good shape. > > Thanks, > > Yaron > > On 30/05/17 18:38, Richard Barnes wrote: > > > > On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <yaronf.i...@gmail.com> > wrote: > >> I'm not sure I understand why the section that describes HTTP validation >> so specifically forbids using HTTPS. >> > > This was because of the default-vhost attack. > > https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 > > Given that we don't really have any data on how common this vulnerability > is, I'm split on whether to keep the restriction. > > --Richard > > > >> On the other hand, I can think of use cases where I would want *only* >> HTTPS authorization: >> >> - The server only supports HTTPS, and perhaps port 80 is blocked by a >> firewall. This situation applies to many REST endpoints. >> - I am migrating from a non-ACME to an ACME cert, and so the server has a >> perfectly valid HTTPS cert. Or migrating from one ACME CA to a different >> one. >> - I would like to ensure (using CAA records) that my CA is not subject to >> a DNS cache corruption attack - a threat that the ACME Security >> Considerations specifically mention. >> >> I would suggest that we specify a HTTPS validation that's exactly like >> http-01, except that it runs over authenticated HTTPS. >> >> Thanks, >> Yaron >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
