Subject: [Acme] Question about finalizing an order

From: "Zhang, Ning" <[email-masked]>
Date: Thu, 22 Mar 2018 20:10:04 +0000

In Section 7.4, the following two statements seem to in conflict with each other:

A request to finalize an order will result in error if the order indicated does not have status “pending”, if the CSR and order identifiers differ, or if the account is not authorized for the identifiers indicated in the CSR.
…
"ready": The server agrees that the requirements have been fulfilled, and is awaiting finalization.  Submit a finalization request.

It seems that the second statement makes more sense, by changing the “pending” into “ready” in the first statement.

Additionally, should the “finalize” URL be made optional in Section 7.1.3, and returned only if the order status is transitioned to “ready”?

Thanks,
-Ning

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 23 Mar 2018 10:43:58 -0400

Hi Ning,

It seems that the second statement makes more sense, by changing the
> “pending” into “ready” in the first statement.

Agreed, this was an oversight in
https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e
.

I opened a pull request to implement this fix
https://github.com/ietf-wg-acme/acme/pull/417

Additionally, should the “finalize” URL be made optional in Section 7.1.3,
> and returned only if the order status is transitioned to “ready”?

My preference here is no. This would introduce two ways to check for the
same thing: whether an order is ready. One by checking the status ==
"ready" and one by checking if there is a finalizationURL. I think this
will complicate things without any strong benefits.

Thanks for catching another spec error! :-)

- Daniel / cpu

On Thu, Mar 22, 2018 at 4:10 PM, Zhang, Ning <[email-masked]>
wrote:

> A request to finalize an order will result in error if the order indicated
> does not have status “pending”, if the CSR and order identifiers differ, or
> if the account is not authorized for the identifiers indicated in the CSR.
>
> …
>
> "ready": The server agrees that the requirements have been fulfilled, and
> is awaiting finalization.  Submit a finalization request.
>
>
>
> It seems that the second statement makes more sense, by changing the
> “pending” into “ready” in the first statement.
>
>
>
> Additionally, should the “finalize” URL be made optional in Section 7.1.3,
> and returned only if the order status is transitioned to “ready”?
>
>
>
> Thanks,
>
> -Ning
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 26 Mar 2018 10:52:12 -0400

PR #417 was merged. This should be resolved now.

Thanks again!

- Daniel / cpu

On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney <[email-masked]>
wrote:

> Agreed, this was an oversight in https://github.com/ietf-wg-
> acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e.
>
> I opened a pull request to implement this fix https://github.com/ietf-wg-
> acme/acme/pull/417
>
>> A request to finalize an order will result in error if the order
>> indicated does not have status “pending”, if the CSR and order identifiers
>> differ, or if the account is not authorized for the identifiers indicated
>> in the CSR.
>>
>> …
>>
>> Additionally, should the “finalize” URL be made optional in Section
>> 7.1.3, and returned only if the order status is transitioned to “ready”?
>>
>>
>>
>> Thanks,
>>
>> -Ning
>>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2018 19:05:54 +0300

Hi

Since you’re merging stuff, then please submit a new version of the draft ASAP.  We *are* in IETF LC, and we wouldn’t want everyone to read an “old” version of the draft.

Thanks

Yoav

> On 26 Mar 2018, at 17:52, Daniel McCarney <[email-masked]> wrote:
> 
> On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Ning,
> 
> Agreed, this was an oversight in https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e <https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e>.
> 
> I opened a pull request to implement this fix https://github.com/ietf-wg-acme/acme/pull/417 <https://github.com/ietf-wg-acme/acme/pull/417>
> 
> My preference here is no. This would introduce two ways to check for the same thing: whether an order is ready. One by checking the status == "ready" and one by checking if there is a finalizationURL. I think this will complicate things without any strong benefits.
> 
> On Thu, Mar 22, 2018 at 4:10 PM, Zhang, Ning <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
>

---

From: Daniel McCarney <[email-masked]>
Date: Mon, 26 Mar 2018 15:00:53 -0400

Richard: Will you take care of whatever this involves?

On Mon, Mar 26, 2018 at 12:05 PM, Yoav Nir <[email-masked]> wrote:

> Hi
>
> Since you’re merging stuff, then please submit a new version of the draft
> ASAP.  We *are* in IETF LC, and we wouldn’t want everyone to read an “old”
> version of the draft.
>
> Thanks
>
> Yoav
>
>
>>> "ready": The server agrees that the requirements have been fulfilled,
>>> and is awaiting finalization.  Submit a finalization request.
>>>
>>>
>>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Mar 2018 20:09:52 +0100

Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft
before sending it to the IESG.  Merging PRs is just the modern way of doing
accepting LC comments and addressing them before IESG evaluation.

---

From: Sophie Herold <[email-masked]>
Date: Tue, 27 Mar 2018 21:26:57 +0200

> will complicate things without any strong benefits.

Which is already the case for the "certificate" key / "valid" status.

Best,
Sophie

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Mar 2018 20:47:34 +0100

> Which is already the case for the "certificate" key / "valid" status.

That doesn't seem dispositive.  The CA might not know the cert URL before
the cert is issued (e.g., if it's based on the serial number).  I don't see
any similar barriers for the finalization URL.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 27 Mar 2018 22:59:20 +0300

The thing is, the comments came in before IETF LC started (minutes before, but still…)

And IETF LC is 4 weeks because it’s assumed that people will be too busy this week having just come back to work from IETF week.  So I’d rather any changes that we know are happening should be published before the directorates get started on their reviews.

Yoav

> On 27 Mar 2018, at 22:09, Richard Barnes <[email-masked]> wrote:
> 
> Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft before sending it to the IESG.  Merging PRs is just the modern way of doing accepting LC comments and addressing them before IESG evaluation.
> 
> On Mon, Mar 26, 2018 at 8:00 PM, Daniel McCarney <[email-masked] <mailto:[email-masked]>> wrote:
> On Mon, Mar 26, 2018 at 12:05 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi
> 
>> On 26 Mar 2018, at 17:52, Daniel McCarney <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Mar 2018 21:21:15 +0100

OK fine. -11 is up.

https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

On Tue, Mar 27, 2018 at 8:59 PM, Yoav Nir <[email-masked]> wrote:

> And IETF LC is 4 weeks because it’s assumed that people will be too busy
> this week having just come back to work from IETF week.  So I’d rather any
> changes that we know are happening should be published before the
> directorates get started on their reviews.
>
> Yoav
>
>
>>> Since you’re merging stuff, then please submit a new version of the
>>> draft ASAP.  We *are* in IETF LC, and we wouldn’t want everyone to read an
>>> “old” version of the draft.
>>>
>>> Thanks
>>>
>>> Yoav
>>>
>>>
>>>> My preference here is no. This would introduce two ways to check for
>>>> the same thing: whether an order is ready. One by checking the status ==