Re: [Acme] kinds of proof

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 2, 2014 at 12:29 PM, Paul Hoffman <[e-mail]> 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.


Well we don't have a draft from the LetsEncrypt folk. But we have a
protocol for automated cert issue that has been in service for several
years now. It is tested and works. We also have plug ins to integrate
to all the major servers. This is a solved problem. The only new part
is making the issue a standard so that the plugin gets integrated into
the servers as native code. Which is of course key to making the
automatic part easy to use.

At the moment deployers have the following choices:

1) Install a certificate on their server following the instructions
provided (20 APP per renewal)
2) Install a plug in that automates the installation and renewal (30
APP one time effort)

If the plug in functionality is integrated to the server then the
number of APP (Administrator Pain Points) decreases significantly,
hopefully it becomes 5 APP or less.


Now I am not suggesting that we simply take the Comodo protocol as is.
It could probably use some work, people want JSON/REST type protocols
(whatever that might mean).

But we don't need to wait on some folk who have yet to set up a
service to document their proposal.


> 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.

That may be possible for the subset of cases where the commercial
provider provides the necessary access. I am not sure how automatic it
can be made without support from the hosting provider though.


> 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".

If you want cooperation from the hosting providers then ACME has to be
capable of meeting all the use cases of the providers. Which means EV
and OV certs. It also means being capable of integrating with whatever
account management tools they provide.


> 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.

Seems reasonable.

> - 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.

Seems we are assuming a particular deployment model here.

> - 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.

Again seems like this is mechanism, not requirements.

> - 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.

That seems reasonable.

Meeting that requirement could end up involving cases of the form
'Chosen CA can't issue cert because of CAA record, can't issue because
there is a minimum validation policy of EV, can't issue because of a
prior pinning requirement.'