Subject: [Acme] acme in a firewalled environment

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Dec 2014 18:52:11 +0100

Question:

Are the myriad of enterprise servers in scope for ACME?  In those
environments it's not unreasonable to assume that a firewall exists to
prevent incoming connections, and DNS control is not available.  In fact
split DNS might introduce all sorts of fun resolution issues even if
control is possible from the inside.

Eliot

---

From: Ben Schumacher <[email-masked]>
Date: Tue, 02 Dec 2014 11:01:56 -0700

> control is possible from the inside.

Eliot-

I would say it is probably out of scope, with regard to public CAs, but 
there is nothing that would prevent an enterprise-wide CA that could be 
ACME enabled.

For example, ACME could be integrated into the Certificate Management 
functionality of your enterprise directory services / host management 
infrastructure.

Thanks,
Ben

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Dec 2014 10:07:49 -0800

Presumably, your web server (or whatever server you're going to use this
cert for) is going to need to accept incoming connections.

On Tue, Dec 2, 2014 at 10:01 AM, Ben Schumacher <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 13:36:40 -0500

I would assert that it is completely in scope because we have most
experience of meeting this requirement.

It is also the only model that is going to scale long term. Right now
I have 20 services running on 5 servers in my house and I am an
outlier. It won't be long before that is a commonplace situation for
Internet of Things. The consumer use case is going to look very much
like the enterprise.

If you want encryption everywhere then you have to support a mechanism
that allows one successful validation interaction to be amortized over
multiple certificate subscriptions.

It is easy enough to do. It is simply a matter of getting the
architecture right. And that isn't too difficult since we have at
least two tried and tested proprietary schemes that can be used as
starting points (OK I don't speak for Symantec's willingness to
contribute but Comodo would certainly like to be out of the server
plug in maintenance game.

On Tue, Dec 2, 2014 at 1:01 PM, Ben Schumacher <[email-masked]> wrote:
> there is nothing that would prevent an enterprise-wide CA that could be ACME
> enabled.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 13:40:14 -0500

> cert for) is going to need to accept incoming connections.

You assume that this is all going to be driven by the Web Server that
is going to use the certificate. That is a very limiting model.

If I am starting a cloud service, I want to be able to give it all the
data it needs to start when I tell it to spawn the virtual machine.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Dec 2014 13:55:52 -0500

> You assume that this is all going to be driven by the Web Server that is going
> to use the certificate. That is a very limiting model.

Yes, that is the model.  I don't think it's limiting.  It's deliberately not all-encompassing.

The first version of ACME should be very constrained to meet its initial requirements.  We don't want to boil the ocean or address EV certs or enterprise enrollment right away.  There are many existing methods for doing those things.  If some proprietary offerings are brought forward, we should look at reconciling them.

Also, some folks have complained that there is no I-D yet. Really?  Is it that important to have an individual I-D submission before there's even been a BoF about forming a WG?

	/r$

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Dec 2014 20:23:14 +0100

On 12/2/14, 7:07 PM, Richard Barnes wrote:
> Presumably, your web server (or whatever server you're going to use
> this cert for) is going to need to accept incoming connections.

Sure.  I think the only additional protocol aspect here is discovery. 
For the enterprise that case is easy (I think), which is to use an
optional SRV record.  From the service aspect, I do have another
question, which is whether name constraints can be used in combination
with an intermediate CA to avoid having to diddle browser cert caches. 
ACME already supports them, so that's not a protocol thing.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Dec 2014 23:01:56 +0000

Hi Rich,

On 02/12/14 18:55, Salz, Rich wrote:
> Is it that important to have an individual I-D submission before
> there's even been a BoF about forming a WG?

Sometimes it is, e.g. IPR and all that. Now while I'd be hopeful,
since I know the proponents well, that's not going to be true
for all the folks who might be interested in the proposal and
who prefer .well-known IPR arrangements.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Dec 2014 23:01:56 +0000

Hi Rich,

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 18:08:31 -0500

> who prefer .well-known IPR arrangements.

I think you have the wrong model of where the IPR problems are likely
to come from.

I very much doubt that the proposers of the ACME protocol will
establish a patent claim in the protocol. But that does not mean that
others haven't done so already.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Dec 2014 23:12:26 +0000

> others haven't done so already.

Sure, that too.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Dec 2014 10:27:18 -0500

Discovery is certainly an issue. The other issue is negotiation

If the proposal here is that the IETF only support one provider of the
certs then you don't need negotiation or discovery as both can just be
hard coded. But that would be a proprietary protocol getting a
standards imprimatur.

Given that this is not going to be a case where latency is critical,
one method on the protocol should probably be a service enquiry
allowing the potential subscriber to find out what issuing roots,
algorithms and validation mechanisms are offered.

At the protocol level, ev and ov don't actually have a lot of impact
since it is the applicant that is being validated above and beyond dv,
not the server. So all that is needed is a means to bind the request
to the account that has been or will be validated.

So the responses are not just accept/reject, there is also the
possibility of pending.

Pending is going to be needed in any case for corner cases that can't
be done manually.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Dec 2014 07:56:58 -0800

> algorithms and validation mechanisms are offered.

That's not a bad idea: https://github.com/letsencrypt/acme-spec/issues/36