Re: [Acme] kinds of proof

On Tue, Dec 2, 2014 at 9:29 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> Greetings. It seems that some people want ACME to force a higher level of assurance on the protocol than those of us who are trying to get more authenticated encryption everywhere would want. Given that we still don't have a published Internet Draft (ahem), it would be good to come to agreement early on what is going to be required.
>
> A specific use case that is important to me is someone running a web server on a commercial hoster should be able to get a TLS cert using ACME even if the hoster does not have its own ACME support. The site admin in that case should be able to run an ACME client on their laptop and be able to go through the ACME steps needed to get a cert that they can load into their web site, then tell the hoster to turn on port 443.
>
> If the hoster supports the ACME steps itself, the web admin might not even need to do anything: the hoster can run ACME for them to get the cert. Given that hosters are always trying to cut customer service costs, ACME should allow hosters to automate the cert process to the point where no human interaction is needed after the hoster decides "this site will now use HTTPS".

I would also encourage that the case be supported where the "hoster"
controls the DNS but not the content on the site.   This is the
situation for most CDNs and Load Balancing services.  Technically the
CDN/LB could special case responses for a well known path, as it is
handling the HTTP connection, but it is frequently easier to validate
control via DNS.

> Proposal:
>
> - ACME clients and servers can be run without human interaction during the ACME exchange itself. All configuration can be done before the ACME client initiates the session, as long as the system running the ACME client has control over the service for which the certificate is being issued. A human may need to make manual changes if their system does not have an ACME setup, but the ACME protocol supports full automation as well.
>
> - A CA must verify that the system on which the ACME client is running can control the service for which the certificate is being issued.

If the ACME client can change DNS, then it clearly can effectively
control the service (FQDN) for which the certificate is being issued.

> - The system running the ACME client does not have to have control over the DNS service that controls the domain name being used in the requested certificate; however, particular DNS control can be required by policy by an ACME server.

I would expect an ACME server can choose to support DNS-based
verification, HTTP-based verification, TLS-based verification, or some
combination thereof.

> - The ACME protocol has to have expressive enough semantics so that an ACME server can tell an ACME client in detail what policy is causing the ACME server to reject a particular certificate request.
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme