Subject: Re: [Acme] Preconditions

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Jul 2016 11:01:44 -0400

In preparation for the impending draft deadline, I'm trying to finalize
close this out.  It seems like there's some positive reaction to the
"revise the flow" idea, so I wanted to make a concrete proposal:

1. Add a section specifying the order of operations for the client:
  - Register if you haven't done so before
  - Send a new-cert request
  - Get back preconditions; satisfy them
  - Retry the new-cert request
2. Remove the new-authz URL

Obviously (1) could make for some slightly complicated state management on
the CA side in some cases, if the CA needs to carry any state between the
first new-cert request and the second.  But it seems like this can be
managed, e.g., by carrying state in the authz URLs or the authorizations
themselves.  And it is technically possible to do it entirely statelessly.

Removing the new-authz URL isn't strictly necessary.  You could leave it
there as an optional service ("if new-cert in directory {...}"), but
removing it seems more in the spirit of Langley's "have one joint and keep
it well oiled" principle.  And while it's a hard breaking change, CAs can
migrate gradually by leaving it on for a while.

Obviously, the deadline is coming up quickly, so it would be great to get
feedback today-ish.  It's not critical that we get all the comments now; we
can discuss between now and the meeting.  This is just a non-trivial bit of
work, so I wanted to sanity check before I embarked on it.

Thanks,
--Richard

On Fri, May 6, 2016 at 3:19 PM, Richard Barnes <[email-masked]> wrote:

> Hey all,
>
> Just posted a PR with a sketch of the "precondition" idea that we
> discussed at the F2F in Buenos Aires:
>
> https://github.com/ietf-wg-acme/acme/pull/124
>
> This change seems pretty simple, and I think it lets us hit a few pain
> points:
>
> * Wildcards: Just send the CSR in and let the CA tell you what to validate
>
> * Payment: Specify an "out-of-band" precondition
>
> * CA issuance flows: If the CA won't tell you how to authorize until you
> send in a CSR, this now lets the ACME server lead the client to do
> authorization after the new-cert request comes in.
>
> We may need a little more machinery here, e.g., to be able to have the
> new-authz endpoint say "that's not going to work directly, just request the
> cert".  We may even want to just revise the flow, so that instead of
> reg-authz-cert, the default order is reg-cert-authz-cert.
>
> But I thought I'd go ahead and send this first pass out for feedback.
>
> What do people think?
>
> Thanks,
> --Richard
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jul 2016 15:07:55 +0000

Speaking as an individual, not a chair, this seems like the right trade-off (a bit of complexity for way more generality) to make.  I am in favor.

---

From: Jonathan Rudenberg <[email-masked]>
Date: Wed, 6 Jul 2016 11:08:18 -0400

> On Jul 6, 2016, at 11:01, Richard Barnes <[email-masked]> wrote:
> 
> In preparation for the impending draft deadline, I'm trying to finalize close this out.  It seems like there's some positive reaction to the "revise the flow" idea, so I wanted to make a concrete proposal:
> 

I like this flow, the precondition system is much cleaner than having the client figure out what authorizations are needed and strictly better in cases like wildcards, renewals, and multi-SAN certs. Once you have preconditions, there is no reason to have multiple paths through the API to do the same thing, so removing new-authz makes a lot of sense.

+1

Jonathan

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 6 Jul 2016 09:52:37 -0700

>   - Retry the new-cert request

I have the same concerns about this that I had in B-A. This seems to put
the client in a position of having to continuously fulfill new requirements
without any guarantee that it will ever lead to success. That seems bad.

-Ekr

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Jul 2016 14:33:01 -0400

> without any guarantee that it will ever lead to success. That seems bad.

It's not like the client was guaranteed of success in the original model,
except under simplistic assumptions about the CA's policies.  And it's not
like it's really in the interest of either party to end up in this
situation.

We already have examples of CAs that won't specify their requirements for
validation until you've sent a CSR (see the SSLMate API as a proxy for a
few of them).  I'm not sure how to accommodate that without ending up in
the situation you're concerned about.  I suppose you could require that the
server specify all of its preconditions in the first response, but it's
hard to see how to make that stick.

Maybe the best compromise here is to provide guidance: (1) when a server
issues preconditions, it should specify everything that's required, rather
than specifying them iteratively, and (2) clients should track how many
times they've gotten preconditions for the same request and abandon the
request if the server is being unreasonable.

--Richard

>> Obviously (1) could make for some slightly complicated state management
>> on the CA side in some cases, if the CA needs to carry any state between
>> the first new-cert request and the second.  But it seems like this can be

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 6 Jul 2016 11:38:25 -0700

I think the general concept is good, and if we go this route I agree
that it should replace new-authz. However, I think there are significant
details to be worked out, and Eric's feedback is good. I don't want to
rush this into the spec because we have a document deadline coming up.
I'd rather take the time to discuss it further and flesh it out better.
And my apologies for letting this sit so long.

Some more specific feedback:

I think problem documents aren't the right tool for the precondition
response, and 412 isn't the right status code. Requesting a certificate
and getting a list of preconditions is an expected, normal thing, not an
error. Let's split out the "ask for preconditions" step from the "I'm
done" step. Something like:

POST /acme/submit-csr
201 Created
Location: /acme/requests/123

GET /acme/requests/123
{
  requirements: [
     { type: authz, url: ..., status: completed },
     { type: authz, url: ..., status: pending },
   ]
}

... fulfill the requirements ...

POST /acme/finalize-csr

This avoids the loop that Eric describes, and makes it easy to see what
still needs to be done. It also means that issuing a certificate for
which all authz's are already validated follows the same flow as issuing
one where they are not. You submit the CSR, get back a request object
with all members "completed", and go on to post to the finalize-csr
resource.

Your example structure has a precondition of type registration. I think
we shouldn't treat registration as a precondition that can be returned
from submit-csr. Instead, it should be as it stands today - you must
register before you can submit any authenticated ACME requests. So we
should remove that example precondition.

More generally, if we're going to support preconditions with type other
than authz, we should have a more specific design for how they're going
to work. For instance, in the payment case, how does the client find out
when payment has been completed?

---

From: Jonathan Rudenberg <[email-masked]>
Date: Wed, 6 Jul 2016 14:54:40 -0400

It seems that there are potentially multiple valid sets of authorizations that are mutually exclusive.

Consider a request for a certificate that has three SANs: a.example.com, b.example.com, c.example.com

There are two valid paths to issuance: validate example.com, or validate the three SANs as specified in the CSR.

Under the precondition system, with ACME server/client implementations that were aware of this shortcut, the client could present a CSR that included example.com as one of the SANs, the server would return a single authorization request for example.com, and then after fulfilling that request, a subsequent request could be made with a CSR that did not contain the example.com SAN, only the subdomains, which would lead to immediate issuance without further authorization.

Does it make sense for the server to be allowed to return multiple exclusive sets of authorizations that could lead to issuance, in order to avoid knowledge of the issuance rules in the client?

Jonathan

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Jul 2016 15:05:22 -0400

> the three SANs as specified in the CSR.

Note that whether these paths are valid depends entirely on the CA's
policy.  For example, I believe that Let's Encrypt would not consider the
"validate example.com" path to be valid.

> Under the precondition system, with ACME server/client implementations
> that were aware of this shortcut, the client could present a CSR that
> included example.com as one of the SANs, the server would return a single
> authorization request for example.com, and then after fulfilling that
> request, a subsequent request could be made with a CSR that did not contain
> the example.com SAN, only the subdomains, which would lead to immediate
> issuance without further authorization.
>
> Does it make sense for the server to be allowed to return multiple
> exclusive sets of authorizations that could lead to issuance, in order to
> avoid knowledge of the issuance rules in the client?
>

I don't really find this all that appealing, to be honest.  But I would
note that we have the "combinations" notion in the authorization struct
right now, which we could import here if we think there's really a need to
support this use case.  I would prefer just having the CA tell the client
what to do; flexibility does not seem nearly as necessary here as it does
at the authorization/validation stage.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Jul 2016 14:16:47 -0400

> rush this into the spec because we have a document deadline coming up.

Agreed that we shouldn't rush this, but I do want to go ahead and get
something in a draft so we can have some more detailed discussion.

> with all members "completed", and go on to post to the finalize-csr

I think this pattern is generally sensible.  It moves us closer to what
SSLMate does today, where you "create a certificate object" (basically
register a CSR), then "buy" (== issue) the certificate.

https://sslmate.com/help/api/rest#cookbook

It's a little unfortunate that this imposes an extra RTT for clients that
are already authorized.  I guess we can land a first iteration that always
requires the client to finalize after submitting, then consider whether we
want to have a one-step process.

> should remove that example precondition.

That wasn't my intent.  Rather, I wanted the CA to be able to say, e.g.,
"you have to provide a contact".  Does that much seem useful?

> when payment has been completed?

That's up to the out-of-band system.  I feel pretty strongly that we need
this out-of-band thing, and we need it to be flexible.  It's the escape
valve for whatever else CAs might need to do before ACME does everything
they need.  For example, with OOB, you could move over your issuance stuff
(use new-reg / new-cert), but still use your old, web-based forms for
validating possession of domains.

--Richard

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 7 Jul 2016 12:10:59 -0700

> Does it make sense for the server to be allowed to return multiple
exclusive sets of authorizations that could lead to issuance, in order
to avoid knowledge of the issuance rules in the client?

This makes sense, but I think it would add a fair amount of complexity
for uncertain benefit. I'd rather not do this.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 7 Jul 2016 14:10:50 -0700

Re-adding the list. I dropped it by accident.

On 07/07/2016 01:50 PM, Richard Barnes wrote:
>
>
> On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 07/07/2016 11:16 AM, Richard Barnes wrote:
>     > That wasn't my intent.  Rather, I wanted the CA to be able to say,
>     > e.g., "you have to provide a contact".  Does that much seem useful?
>     Ah, now I get it. But why would that be part of the cert request flow?
>     It seems like a CA that has a "contact required" policy should enforce
>     that policy when the account is created. Similarly, the "terms
>     required"
>     is already enforced at the per-request level: Let's Encrypt won't
>     allow
>     any authenticated requests until the terms are agreed to.
>
>     > That's up to the out-of-band system.  I feel pretty strongly that we
>     need this out-of-band thing, and we need it to be flexible.
>
>     Agreed we need some system for out-of-band requests, but I think
>     we need
>     to flesh out a flow for a hypothetical out-of-band request in more
>     detail. In particular, we need to close the loop. The outbound
>     direction
>     is obvious - load this URL in a browser, expect something human
>     readable
>     with further instructions. However, we need the inbound direction as
>     well. How does the client know when a human has completed the
>     out-of-band instructions satisfactorily? That's why I added the status
>     field in my example.
>
>
> Oh yeah, totally fine having the status field.
>  
>
>     Unrelatedly: I think these request objects probably need a status
>     field
>     and an expiry, like authorizations, and the ability for server or
>     client
>     to deactivate them. For instance, status could be: in-progress,
>     completed, deactivated.
>
>
> Yeah, I was thinking something basically the same as authorizations:
> - pending: You still need to fulfill some requirements
> - invalid: This one is bad, you need to start over
> - valid: You can use this to issue certs
> - expired: You can't use this any more
>
> The only question I'm pondering is whether we need to separate "you
> can't use this any more because you didn't complete the requirements
> fast enough" from "... because you already issued all the certs you
> were allowed to issue" (maybe with "closed" for the latter).  I think
> I'm fine conflating them for a first pass.
I think there should be a one-to-one correspondence between these
"preconditions" or "requirements" objects (still trying to come up with
a good name) and certificates. I.e., you create one, and then you submit
it, and it's used up. To create another certificate you have to submit a
new request. There do wind up being some interesting interactions with
rate limiting: Do you check and decrement the rate limit before creating
the preconditions object, or when finalizing it? Nothing insurmountable,
I think.

Regarding out of band: In this PR you have "out-of-band" as a type of
object that can appear in a preconditions object, but we already have a
challenge type "out-of-band." We should reconcile those. For instance,
we could say that a preconditions object contains a list of
authorizations. The "doneness" of each item in the list could then be
expressed through each authorization's status field. Problem: For paid
CA's, I think payment is a property of an order rather than a property
of a domain name. One possible workaround would be for those CAs to
define a new identifier type, e.g. "order number", and create
authorizations for order numbers that have out-of-band payment URLs.

Alternately, we could remove the oob-01 challenge in favor of
implementing the out-of-band functionality at the preconditions level
instead.

Andrew, what are your thoughts?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 7 Jul 2016 14:50:22 -0700

(Resending mail where the list got dropped, to make the flow of
conversation clearer):

Ah, now I get it. But why would that be part of the cert request flow?
It seems like a CA that has a "contact required" policy should enforce
that policy when the account is created. Similarly, the "terms required"
is already enforced at the per-request level: Let's Encrypt won't allow
any authenticated requests until the terms are agreed to.

> need this out-of-band thing, and we need it to be flexible.

Agreed we need some system for out-of-band requests, but I think we need
to flesh out a flow for a hypothetical out-of-band request in more
detail. In particular, we need to close the loop. The outbound direction
is obvious - load this URL in a browser, expect something human readable
with further instructions. However, we need the inbound direction as
well. How does the client know when a human has completed the
out-of-band instructions satisfactorily? That's why I added the status
field in my example.

Unrelatedly: I think these request objects probably need a status field
and an expiry, like authorizations, and the ability for server or client
to deactivate them. For instance, status could be: in-progress,
completed, deactivated.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 7 Jul 2016 14:51:20 -0700

(Resending Richard's mail where the list was still dropped, to make the
flow of converstaion clearer):

On 07/07/2016 01:50 PM, Richard Barnes wrote:
> On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews <[email-masked] > <mailto:[email-masked]>> wrote: > > On 07/07/2016 11:16 AM, Richard
Barnes wrote: > > That wasn't my intent. Rather, I wanted the CA to be
able to say, > > e.g., "you have to provide a contact". Does that much
seem useful? > Ah, now I get it. But why would that be part of the cert
request flow? > It seems like a CA that has a "contact required" policy
should enforce > that policy when the account is created. Similarly, the
"terms required" > is already enforced at the per-request level: Let's
Encrypt won't allow > any authenticated requests until the terms are
agreed to. > > > That's up to the out-of-band system. I feel pretty
strongly that we > need this out-of-band thing, and we need it to be
flexible. > > Agreed we need some system for out-of-band requests, but I
think we need > to flesh out a flow for a hypothetical out-of-band
request in more > detail. In particular, we need to close the loop. The
outbound direction > is obvious - load this URL in a browser, expect
something human readable > with further instructions. However, we need
the inbound direction as > well. How does the client know when a human
has completed the > out-of-band instructions satisfactorily? That's why
I added the status > field in my example. > > > Oh yeah, totally fine
having the status field. > > > Unrelatedly: I think these request
objects probably need a status field > and an expiry, like
authorizations, and the ability for server or client > to deactivate
them. For instance, status could be: in-progress, > completed,
deactivated. > > > Yeah, I was thinking something basically the same as
authorizations: > - pending: You still need to fulfill some requirements
> - invalid: This one is bad, you need to start over > - valid: You can
use this to issue certs > - expired: You can't use this any more > > The
only question I'm pondering is whether we need to separate "you > can't
use this any more because you didn't complete the requirements > fast
enough" from "... because you already issued all the certs you were >
allowed to issue" (maybe with "closed" for the latter). I think I'm >
fine conflating them for a first pass.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Jul 2016 18:05:29 -0400

On Thu, Jul 7, 2016 at 5:10 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> On Thu, Jul 7, 2016 at 3:38 PM, Jacob Hoffman-Andrews < <[email-masked]>
> [email-masked]> wrote:
>
> The only question I'm pondering is whether we need to separate "you can't
> use this any more because you didn't complete the requirements fast enough"
> from "... because you already issued all the certs you were allowed to
> issue" (maybe with "closed" for the latter).  I think I'm fine conflating
> them for a first pass.
>
> "preconditions" or "requirements" objects (still trying to come up with a
> good name) and certificates. I.e., you create one, and then you submit it,
> and it's used up. To create another certificate you have to submit a new
> request. There do wind up being some interesting interactions with rate
> limiting: Do you check and decrement the rate limit before creating the
> preconditions object, or when finalizing it? Nothing insurmountable, I
> think.
>
> challenge type "out-of-band." We should reconcile those. For instance, we
> could say that a preconditions object contains a list of authorizations.
> The "doneness" of each item in the list could then be expressed through
> each authorization's status field. Problem: For paid CA's, I think payment
> is a property of an order rather than a property of a domain name. One
> possible workaround would be for those CAs to define a new identifier type,
> e.g. "order number", and create authorizations for order numbers that have
> out-of-band payment URLs.
>

Oh, please no hacks like that.  I think it's clear that we need some OOB
thing at the "application" / "requirements" level, precisely in order to
avoid hacks like this.  If we're going to remove one of these, we should
remove the OOB challenge type.  But I don't really think it's tragic to
have both; they serve slightly different purposes.

--Richard

> Alternately, we could remove the oob-01 challenge in favor of implementing
> the out-of-band functionality at the preconditions level instead.
>

---

From: Brad Warren <[email-masked]>
Date: Thu, 7 Jul 2016 15:21:39 -0700

I think there's a possibility we could implement a lot of the desired
functionality without preconditions or changing the reg-authz-cert flow.
The main benefits initially mentioned for preconditions were payments,
wildcards, and CA issuance flows.

To implement payments, it seems like we could use a generic out of band
challenge type. I agree that this needs to be more fleshed out.

For wildcards, we could build off of Ron's suggestion to allow clients
to include a wildcard domain in the authorization request. If we did
this, however, we'd probably want to modify the HTTP/DNS challenges to
allow the server to specify the exact domain where the client has to
complete the challenge.

For example, if the client requests an authorization for *.example.org,
the ACME server could say that the client needs to complete HTTP
challenges for a.example.org, b.example.org, and c.example.org.

Changes like those described above would still allow CAs to differ based
on what the client needs to do to be authorized for an identifier. The
big downside to this approach is it only allows that flexibility based
on the domain the client requested. If a CA wants to have different
preconditions based on values in the CSR other than the domains, this
won't work.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Jul 2016 18:27:48 -0400

So to be blunt: You're saying that some of what we want could be achieved
by hacks within the existing model, rather than getting all of what we want
by changing the model :)

I really think it's cleaner at this point to change the model.  There's not
that much deployed code yet, so we should go ahead and get things right.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jul 2016 23:01:47 +0000

> I really think it's cleaner at this point to change the model.  There's not that much deployed code yet, so we should go ahead and get things right.

Not as chair:  strongly agree.

---

From: Peter Eckersley <[email-masked]>
Date: Thu, 7 Jul 2016 17:05:15 -0700

> that much deployed code yet, so we should go ahead and get things right.

There are dozens of projects that will need to rework their code if we
restructure the protocol, including most of these and probably a lot that
aren't listed:

https://letsencrypt.org/docs/client-options/

That means we do unforuntately face some pretty painful tradeoffs between
trying to optimize the protocol for elegance vs forcing ACME servers to
speak multiple protocol versions simultaneously vs avoiding disruption to 
developer and user populations.

For that reason, I think we should strongly prefer solutions that preserve the
existing semantics and flows through the protocol. That seems possible by
having the new flow use new endpoints that strictly expand upon the existing
ones, or by following Brad's approach and allowing the results we want with
existing flows. Or perhaps both: aim to allow existing clients to get
wildcards (if they can request authz for them and solve a new challenge type)
and add /submit-csr as an endpoint that makes it easier to get through the
existing flow in an efficient way.

-- 
Peter Eckersley                            [email-masked]
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Jul 2016 00:18:37 +0000

> https://letsencrypt.org/docs/client-options/

That's the LetsEncrypt protocol, not the IETF ACME protocol.  We're not here to polish the staples and rubber-stamp.

	/r$, speaking as co-chair.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Jul 2016 21:58:35 -0400

OK, I have updated the preconditions PR to reflect this discussion.  It's
more invasive than I thought going in, but I think it hangs together.

If there are not major objections before tomorrow morning EST, I'm going to
go ahead and merge it.  We can always back it out if we have buyer's
remorse later.

On Thu, Jul 7, 2016 at 8:18 PM, Salz, Rich <[email-masked]> wrote:

> That's the LetsEncrypt protocol, not the IETF ACME protocol.  We're not
> here to polish the staples and rubber-stamp.
>

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 08 Jul 2016 12:07:19 +0000

You sent this at 7 PM Pacific which is after hours and are expecting
feedback by 9 AM Pacific. I don't think that's nearly enough time to vet
the latest changes you've made.
On Thu, Jul 7, 2016 at 6:58 PM Richard Barnes <[email-masked]> wrote:

> If there are not major objections before tomorrow morning EST, I'm going
> to go ahead and merge it.  We can always back it out if we have buyer's
> remorse later.
>

---

From: Jeff Hodges <[email-masked]>
Date: Fri, 08 Jul 2016 12:22:16 +0000

Oh, left out: or even enough time for people to read this email to know
they need to object. I just happened to be up.
On Fri, Jul 8, 2016 at 5:07 AM Jeff Hodges <[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Jul 2016 10:12:19 -0400

Don't fret.  There have already been several rounds of discussion on this,
and there will be several more.  Just giving people a chance.  Non-US folks
even had real work time.

--Richard

On Fri, Jul 8, 2016 at 8:22 AM, Jeff Hodges <[email-masked]>
wrote:

>>> OK, I have updated the preconditions PR to reflect this discussion.
>>> It's more invasive than I thought going in, but I think it hangs together.
>>>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 8 Jul 2016 13:07:45 -0700

On 07/07/2016 05:18 PM, Salz, Rich wrote:
> here to polish the staples and rubber-stamp. /r$, speaking as
> co-chair. -- Senior Architect, Akamai
I agree with this. Let's Encrypt has planned all along to make some
breaking protocol changes as the spec evolves. We will of course give
plenty of warning and a long transition period, but it's more important
to wind up with a well-designed protocol that can be implemented by
multiple parties than it is to preserve our first design forever.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 8 Jul 2016 13:59:03 -0700

Jeff raises a good point. There are a number of people here, including
myself, who are not active in the IETF in general, and so aren't aware
of upcoming meetings and deadlines. From this perspective, progress on
the spec seems to come in sudden spurts of activity without adequate
time for discussion.

Would you, or Rich as co-chair, be willing to give two weeks advance
notice on the list of upcoming document deadlines?

---

From: Peter Eckersley <[email-masked]>
Date: Fri, 8 Jul 2016 15:00:20 -0700

> notice on the list of upcoming document deadlines?

Yes, that would probably be useful. AFAICT we may still need to make a revision
that suggests a specific privileged port for Challenges, as one of the steps
for IANA allocating us such a port?

https://tools.ietf.org/html/rfc6335#section-8.1.1
https://tools.ietf.org/html/rfc6335#section-8.1.2
(pointint to the "IETF Review" section of https://tools.ietf.org/html/rfc5226)

With a bit of warning I might have been able to put that together for this
deadline.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jul 2016 11:29:09 +1000

> With a bit of warning I might have been able to put that together for this

Please don't treat meeting deadlines as anything special.  Generate
discussion and pull requests at any time.  The reason we have the
deadline is so that we can create a snapshot of where the working
group is at and to marshal efforts so that there can be productive
discussion, sometimes with a wider audience than the core group.

Given that this list is often quite productive outside of meetings,
I'm sure that a good amount of progress could be made on these issues
without being subject to the constraints around having face-to-face
time.

---

From: Andrew Ayer <[email-masked]>
Date: Sun, 17 Jul 2016 19:38:40 -0700

On Thu, 7 Jul 2016 21:58:35 -0400

> https://github.com/ietf-wg-acme/acme/pull/124

I like the direction that ACME is taking by introducing the application
object.  Let me take a stab at answering the two open issues.

> [[ Open issue: There are two possible behaviors for the CA here.
> Either (a) the CA automatically issues once all the requirements are
> fulfilled, or (b) the CA waits for confirmation from the client that
> it should issue.  If we allow both, we will need a signal in the
> application object of whether confirmation is required.  I would
> prefer that auto-issue be the default, which would imply a syntax
> like "confirm": true ]]

I favor auto-issuance as the only option, for client simplicity.  I
think the creation of an application should be sufficient confirmation
from a client that it wants to issue.  Also consider the case where an
account is already authorized for an identifier.  It would be nice if
the client could create an application and be able to immediately
download a cert without needing an additional round trip.

> [[ Open issue: Should this syntax allow multiple certificates?  That
> would support reissuance / renewal in a straightforward way,
> especially if the CSR / notBefore / notAfter could be updated. ]]

Yes, I think it should.  ACME would be a more valuable protocol if it
didn't just help people get a single certificate, but also helped them
manage a certificate application over its entire lifetime, including
across renewals.  All types of clients would benefit from this, but in
particular it would make the following use of ACME possible:

1. You request a certificate for the first time using a full ACME client
on a central, trusted server that has access to your account key and the
ability to complete challenges.

2. You configure lightweight ACME clients on your various servers and
devices with the URL of the application object created in step 1.  The
client would download new certificates as old ones expire.

The advantage of this architecture is that your account credentials
only need to be in one place (assuming that downloading doesn't require
authentication), and if you're using DNS challenges, the credentials to
modify your DNS only need to be in one place.  The lightweight client
would be very easy to implement and integrate into any sort of software
or device.  It could be as simple as making a single HTTP GET that
returns a certificate chain.  Imagine if instead of specifying a
filesystem path to your certificate, you specified an ACME URL!  It
also makes short-lived certificates a lot easier.

There are some questions to consider.

First, should the CSR field be mutable?  I think so.  It would be
convenient to be able to add a new subjectAltName to an existing
application from your central ACME client and have all your servers
and devices automatically pick up the new certificate once it's issued.
SSLMate supports this, since it's common for site operators to add SANs
to existing certificates as they bring new domain names online.

Second, if a renewal, or the addition of an identifier to the CSR,
requires the completion of new requirements, how should they be
expressed in the object?  What should the status of an application be
if it has a valid certificate, but there is a replacement certificate
pending?

Regards,
Andrew

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 18 Jul 2016 07:52:41 -0700

On Sun, 17 Jul 2016 19:38:40 -0700
Andrew Ayer <[email-masked]> wrote:

> I favor auto-issuance as the only option, for client simplicity.

It was noted in Berlin that the SSLMate API requires explicit
confirmation to issue.  The reason why is that SSLMate doesn't have
challenges as a separate concept, so in SSLMate the step to issue is
also the step to verify domain ownership.  ACME already has separate
challenges which need explicit completion, which is why I think an
explicit step to issue would be redundant for ACME.