Re: [Acme] kinds of proof

[Trevor Freeman <[e-mail]>]

 

 

-----Original Message-----
From: Acme [mailto:[e-mail]] On Behalf Of Paul Hoffman
Sent: Tuesday, December 02, 2014 9:30 AM
To: [e-mail]
Subject: Re: [Acme] kinds of proof

 

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

 

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.

[TF] Totally agree with the sentiment. However each ACME client will need
some minimal configuration and I stress minimal. I would submit it should be
possible to use:

1.       The URL of the ACME server

2.       An authenticator to prove this request belongs to a DV RA

That is all we need. The ACME client should be able to use this data to
learn when type of request(s) to build, what parameters to use, then summit
the request with a high confidence it will success because it used the
information from the ACME server to build the request, and install the
certified once issued. The small the bootstrap data set, the less scope for
misstates when repeating across multiple ACME clients. 

 

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

[TF] The ACME server would have previously verified the DV RA. The biding
between the RA and the individual request is a form of delegations i.e. this
request belongs to the DV RA. 

 

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

[TF] This relates to the type of proof and scope the DV RA used. If the DV
RA used a DNS based POC then the CA can issue names in any subdomain i.e. if
you validated foo.com then you can issue *.foo.com. If the POC was to a
specific URL, then the ACME server can only issue to that same domain name. 

 

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

[TF] an ACME server can tell an ACME client in detail what is causing the
ACME server to reject a particular certificate request.  Let's not assume
the only failures are policy.

 

 

_______________________________________________

Acme mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/acme>
https://www.ietf.org/mailman/listinfo/acme