Subject: [Acme] Proactive vs On-Finalization Certificate Issuance

From: Daniel McCarney <[email-masked]>
Date: Thu, 25 Aug 2016 13:57:25 -0400

Hi folks,

I wanted to revisit a discussion on the server proactively issuing
certificates. Section 4, "Protocol Overview"[0] currently has a paragraph
that
reads:

> Once the validation process is complete and the server is satisfied that
the
> client has met its requirements, the server can either proactively issue
the
> requested certificate or wait for the client to request that the
application be
> “finalized”, at which point the certificate will be issued and provided
to the
> client.

There is also an "Open Issue" remark related to proactive issuance in
Section
6.1.3[1].

I think the specification should decide whether proactive issuance or
on-finalization issuance should be used instead of allowing both with no
indication to the client which will happen.

It's the preference of Let's Encrypt that the specification only support
on-finalization issuance. This is cheaper to implement and seems to be the
path
of least surprise. It also seems to better support large volume issuance
when
the client may want explicit control over when the certificates for multiple
applications are issued.

In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to
agree
that there should be only one issuance method to simplify client behaviours,
though he favours proactive issuance instead of on-finalization issuance.
While
it saves a round-trip message I'm not sure that this alone is convincing
enough
to choose proactive issuance as the one issuance method.

What are the thoughts of other list members?

- Daniel/cpu

[0]
https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#protocol-overview

[1]
https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#application-objects

[2] https://www.ietf.org/mail-archive/web/acme/current/msg01160.html

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Aug 2016 14:48:38 -0400

Hey Daniel,

Thanks for doing the research so I didn't have to find those threads :)

I admit to also being in the "go-ahead-and-issue" camp.  To recap, that
would mean:

1. Client submits a new application
2. Server sends back some authorizations
3. Client fulfills authorizations
4. Server issues as soon as all required authorizations are fulfilled

Is there some reason you think a client wouldn't want step (4) to happen?
Maybe you could elaborate on the bulk-issuance scenarios you have in mind?

--Richard

On Thu, Aug 25, 2016 at 1:57 PM, Daniel McCarney <[email-masked]>
wrote:

> [0] https://github.com/ietf-wg-acme/acme/blob/
> 3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme-
> acme.md#protocol-overview
>
> [1] https://github.com/ietf-wg-acme/acme/blob/
> 3502ff0bfb6d434b4326e206ea7cae7b8434ac7d/draft-ietf-acme-
> acme.md#application-objects
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 25 Aug 2016 16:09:59 -0400

Hi Richard,

Sure! Imagine a provider with a large number of domains wants to perform an
initial roll-out by provisioning these domains across a number of
certificates. The provider also wants to exercise a finer-grain control
over the expiration of these certificates to stagger them across days.

With a "on-finalization" based issuance the provider would be free to
construct the required applications & complete the challenges for all
domains ahead of time as part of one large batch process. The provider can
subsequently request certificate issuance on an application-by-application
basis across a period of days by completing the finalization.

To contrast, with a "go-ahead-and-issue" or proactive issuance model the
provider can not authorize all of their domains ahead of time and must
complete one application's worth of challenges per day. The provider would
be required to split both the authorization and issuance into smaller
batches when the intention was to only split the issuance up to control
expiry.

Does that help clarify?

- Daniel/cpu

On Thu, Aug 25, 2016 at 2:48 PM, Richard Barnes <[email-masked]> wrote:

> On Thu, Aug 25, 2016 at 1:57 PM, Daniel McCarney <
> [email-masked]> wrote:
>
>> Hi folks,
>>
>> > Once the validation process is complete and the server is satisfied
>> that the
>> > client has met its requirements, the server can either proactively
>> issue the
>> on-finalization issuance. This is cheaper to implement and seems to be
>> the path
>> [0] https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b43
>> 26e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#protocol-overview
>>
>> [1] https://github.com/ietf-wg-acme/acme/blob/3502ff0bfb6d434b43
>> 26e206ea7cae7b8434ac7d/draft-ietf-acme-acme.md#application-objects
>>

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 25 Aug 2016 14:41:01 -0700

On Thu, 25 Aug 2016 13:57:25 -0400
Daniel McCarney <[email-masked]> wrote:

> In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems
> to agree
> that there should be only one issuance method to simplify client
> behaviours, though he favours proactive issuance instead of
> on-finalization issuance. While
> it saves a round-trip message I'm not sure that this alone is
> convincing enough

There's another reason I prefer proactive issuance: I think the server
should automatically issue a new certificate if an application's
current certificate is about to expire and its authorizations are still
valid.  This lets you create an application from a central
location with access to your account key, and then have your TLS
frontends/load balancers make unauthenticated GETs to keep the
certificate up-to-date.  I think this is essential to make short-lived
certificates work robustly, but it's useful even with longer-lived
certificates.  I went into further detail in my previous email[1].

Requiring an explicit action to issue would mean you'd need some
process somewhere to request issuance when a cert is about
to expire.  This process would need access to your account key (so it
should not run on your frontend servers), and if it fails your
certificates stop renewing.

I understand the bulk issuance use case you describe.  Could it be
accomplished instead by a boolean field in the application to
enable/disable the application?  Certificates would only be issued when
the application is enabled.  Bulk issuers could pre-create
authorizations in the disabled state, and enable them when ready to
issue.

Regards,
Andrew

[1] https://www.ietf.org/mail-archive/web/acme/current/msg01160.html

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Aug 2016 18:15:35 -0400

> certificates.  I went into further detail in my previous email[1].

One issue that was briefly discussed at the meeting is whether the
Application object should have a "certificates" array member instead of a
"certificate" string member.  That would allow this sort of re-issuance
without erasing the old URL.

Andrew: Is that something you think we need?

> authorizations in the disabled state, and enable them when ready to

I was actually thinking that Daniel's use case sounded a lot like what EKR
was describing as his use case for bringing back the new-authz flow.
Namely, instead of proactively submitting new-app requests for a bunch of
certs, the client would submit new-authz requests for all the names they
might want on certs, then submit new-app requests when they're ready to get
certs.  So basically what you do with LE now, except "new-app" instead of
"new-cert".

Daniel: That change is in this PR:

https://github.com/ietf-wg-acme/acme/pull/165

Does that look like it would address your use case?

--Richard

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 26 Aug 2016 11:50:03 -0400

Hi Andrew,

Thanks for the follow-up.

> certificates.  I went into further detail in my previous email[1].

Ahhh! Yes, this sounds like a sensible reason to prefer proactive
issuance. I will review your previous email with details and will
reevaluate
my position.

> enable/disable the application?

Yes - this might be a good compromise. I'll try and take some time to
compare this versus the EKR PR[0] for the new-authz flow that Richard
linked to in his other reply to this thread to see if one is a better fit
than the other.

My primary motivation for this thread is to decide on *one* method:
proactive or on-finalization. If the proactive approach can support
the bulk issuance case then I could be persuaded to support it as the
One True Issuance Method :-)

- Daniel

(P.s. my timing here wasn't ideal and I leave for vacation today. I will
have to pick this thread up in a weeks time, apologies!)

[0] https://github.com/ietf-wg-acme/acme/pull/165

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Fri, 26 Aug 2016 11:35:03 -0700

> certificates.  I went into further detail in my previous email[1].

This is a very interesting idea that is worth considering but perhaps as
an extension to the ACME specification rather than an initial part of
it? A move to this style of issuance would require major architectural
changes to all existing server and client implementations, something I'm
unsure there is much enthusiasm for at this point.

> authorizations in the disabled state, and enable them when ready to

You refer to enabling/disabling an authorization but it seems like you
mean the application? If that is the case this seems to be essentially
the same as having two step issuance except it is possible to default to
'issue instantly'. I'm not entirely convinced this wouldn't work but I
am much happier increasing complexity on the side of the client than the
server which this would do the opposite of.

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Fri, 26 Aug 2016 11:46:23 -0700

On 08/25/2016 03:15 PM, Richard Barnes wrote:
> 
> 
> On Thu, Aug 25, 2016 at 5:41 PM, Andrew Ayer <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Daniel McCarney <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
> Application object should have a "certificates" array member instead of
> a "certificate" string member.  That would allow this sort of
> re-issuance without erasing the old URL.
> 

In the current model would the idea be you could 'finalize' an
application multiple times and the 'certificates' field would include
the array of certificates created from that application in some defined
order? This would be a very nice thing to have from the server side.

> I was actually thinking that Daniel's use case sounded a lot like what
> EKR was describing as his use case for bringing back the new-authz
> flow.  Namely, instead of proactively submitting new-app requests for a
> bunch of certs, the client would submit new-authz requests for all the
> names they might want on certs, then submit new-app requests when
> they're ready to get certs.  So basically what you do with LE now,
> except "new-app" instead of "new-cert".
> 

I think this adds unneeded complexity and only makes sense if we decide
to make proactive issuance a 'MUST' and still need a way for people to
create applications with new authorizations without immediately creating
the certificate.

Thinking about it more I do kind of like the idea Andrew brought up, or
really a mutation of it, where the application has a field that lets the
client define if they want the application to complete itself if possible.

>     <https://www.ietf.org/mail-archive/web/acme/current/msg01160.html>
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> 
>