Subject: [Acme] new-authz, new-order and examples

From: Sophie Herold <[email-masked]>
Date: Wed, 6 Dec 2017 00:07:48 +0100

Hi,

i noted that the examples in "7.4. Applying for Certificate Issuance"
are still using CSRs.

Further, I didn't found explicit coverage of the case that there is a
valid authorization (say via new-authz) at the time of posting a
new-order. Should the server return "authorizations: valid" in this case
and does that imply the client can proceed with finalization immediately?

Having mentioned new-authz: The definition of new-authz is now a subset
of new-order. Is there any reason to keep the new-authz resource at all?
Would there be any difference in using new new-order with the exact same
query without finalizing it?

Best,
Sophie

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 6 Dec 2017 10:53:09 -0500

Hi Sophie,

i noted that the examples in "7.4. Applying for Certificate Issuance" are
> still using CSRs.

Good catch! I'll submit a PR to address this oversight this afternoon.

> Further, I didn't found explicit coverage of the case that there is a valid
> authorization (say via new-authz) at the time of posting a new-order.
> Should the server return "authorizations: valid" in this case and does
> that imply the client can proceed with finalization immediately?

That's my understanding. If a client uses the new-authz preauth flow to
obtain a valid authz for "example.com" with ID "https://acme.inc/authz/1234",
and then submits a new-order for identifiers `["example.com"]` I would
expect the server to return an order with `"authorizations": ["
https://acme.inc/authz/1234"]`. When the client GET's each of the Authz IDs
it will see all are `state: valid`, no challenges need POSTing, and
finalization of the order can occur.

Having mentioned new-authz: The definition of new-authz is now a subset of
> new-order. Is there any reason to keep the new-authz resource at all? Would
> there be any difference in using new new-order with the exact same query
> without finalizing it?

I agree with you that it seems like the new-authz flow is unnecessary - I
believe Jacob Hoffman-Andrews has previously argued it shouldn't be
included in the spec. Let's Encrypt does not intend to implement it at all
for their new order-based API endpoint.

If someone has a use-case for the new-authz flow that isn't addressed by
new-order with finalization they should speak up in-thread - otherwise I
vote it be removed.

- Daniel / cpu

On Tue, Dec 5, 2017 at 6:07 PM, Sophie Herold <[email-masked]>
wrote:

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 6 Dec 2017 12:38:54 -0800

> query without finalizing it?

Yeah, I agree that this is a happy side-effect of making order
finalization an explicit step: there is now even less need for
preauthorization (i.e. new-authz). I strongly favor removing it. Eric, I
think you were the strongest voice in favor of adding preauthorization
to the spec when we moved to the new-order flow. Do you still feel it's
necessary? For context, you can accomplish the same thing by posting a
new-order for a single identifier, but not finalizing the order.

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 6 Dec 2017 15:58:20 -0500

> Good catch! I'll submit a PR to address this oversight this afternoon.

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

On Wed, Dec 6, 2017 at 10:53 AM, Daniel McCarney <[email-masked]>
wrote:

> obtain a valid authz for "example.com" with ID "
> https://acme.inc/authz/1234", and then submits a new-order for
> identifiers `["example.com"]` I would expect the server to return an
> order with `"authorizations": ["https://acme.inc/authz/1234"]`. When the
> client GET's each of the Authz IDs it will see all are `state: valid`, no
> challenges need POSTing, and finalization of the order can occur.
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Dec 2017 16:58:18 -0500

> new-order for a single identifier, but not finalizing the order.

I'll let EKR speak for himself, but this seems really clumsy to me.  At the
very least, it requires the server to allocate more resources than it
otherwise would, order+authz instead of just authz.  The new-authz endpoint
is simple enough (and optional enough) that I think it's worth keeping
around on its own for those who want it.

--Richard