Subject: Re: [Acme] Challenge url -> finalize flow and status definitions

From: Sophie Herold <[email-masked]>
Date: Sat, 6 Jan 2018 15:40:54 +0100

Hi,

I have missed the following sentence:

    A request to finalize an order will result in error if …
    the account is not authorized for the identifiers

This was also the intention behind introducing finalization in the first
place. Therefore, this is clarified for me.

However, I want to suggest that the following issues in the draft still
need clarification:

1.

    Once the client believes it has fulfilled the server's requirements,
    it should send a POST request to the order resource's finalize URL.

This should not be based on a "believe". The client fulfills the
challenge and responds to the challenge afterwards. Then the client
should begin polling <to be decided> until all authorizations are valid.
Only then it should try to finalize.

2.

    A request to finalize an order will result in error if the order
    indicated does not have status "pending" … or if the account is not
    authorized for the identifiers

    …

    "pending": The server does not believe that the client has fulfilled
    the requirements. Check the "authorizations" array for entries that
    are still pending.

This is contradictory. It says: To finalize you need the state that
corresponds to 'unauthorized' but you must be 'authorized' at the same time.

One question is: Should the order object reflect the state of the
authorizations? I don't see arguments against it. Clients polling all
authorizations is more expensive then the server having to lookup the
first authorization that is not 'valid'.

I am suggesting the following order states

pending: Authorizations need user action
validating: Please poll order/authz until server has validated
authorized: Please finalize ('finalize' key only present in this state)
issuing: Called 'processing' before
issued: Certificate ready ('certificate' key only present in this state)
invalid: Authorization failed, error or expired

3.

    The status of this authorization. Possible values are: "pending",
    "processing", "valid", "invalid" and "revoked".

    …

    sending POST requests with the static object {"status":
    "deactivated"} to each authorization URL

The meanings of the statuses "pending", "processing" are not defined. It
also seems like there should be an "deactivated" status as well?
"processing" could probably be call "validating".

4.

    The status of this challenge. Possible values are: "pending",
    "valid", and "invalid".

Again no definition of the meaning. I think the server should reflect if
the challenge has been 'responded' by the client. This would need an
extra field like "processing" or "validating".

5.

   For challenges where the client can tell when the server has
   validated the challenge (e.g., by seeing an HTTP or DNS request from
   the server), the client SHOULD NOT begin polling until it has seen
   the validation request from the server.

I suggest removing this paragraph. There is no reason why only one
request for validation should happen from the server. Doesn't LE already
have distributed validation servers? Anyways, I would suggest to focus
on the Retry-After header instead. This is something client libraries
can give a general solution for. The Retry-After header could already be
send as an answer to the the challenge response POST. Or is there a
problem with servers not having a good Retry-After estimate?

6.

At least the "typical sequence of requests" table is lacking a polling
step before the "Finalize order" step.

Best,
Sophie

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 7 Jan 2018 17:50:12 +0200

> place. Therefore, this is clarified for me.

This assumes that authorizations are account-global. However, I
think ACME allows order-local authorizations (and I think some weirder
intermediate cases between order-local and account-global).

Yes, the scope was removed, as it was not useful and could not even
represent some cases.

> Only then it should try to finalize.

I think either:

- Client should check the overall status of order.
- Client should check the overall status of all authorizations.

> invalid: Authorization failed, error or expired

I don't think orders should have validating state. 

That is, the authorization statuses could be:

- pending: No challenge attempts yet.
- processing(or validating): Challenge in progress.
- invalid: Last challenge attempt failed, none in progress
- valid: Challenge succeded, name valid to issue.
- deactivated: Revoked by account owner.
- revoked: Revoked by CA.

Yes, there are race conditions, but running multiple orders in
parallel without coordination inherently leads to races. 

What makes sense for order status depends on if it is easy enough to
collect overall status or not. If it is easy enough (names taken from
quoted message and present specifications, might make sense to tweak
those a bit)

- pending: One or more authorizations missing.
- invalid: Order failed.
- authorized: Waiting for finalization.
- processing: Certificate is being manufactured.
- valid: Certificate issued.
- deactivated: Revoked by account owner.
- revoked: Revoked by CA.

If it is not easy to summarize status, then the following modifications
would make sense:

- pending: Not finalized, failed or revoked yet
- authorized: N/A

> "processing" could probably be call "validating".

Yeah, looks like many statuses are poorly defined.

> extra field like "processing" or "validating".

Well, authorization that has not been responded to is "pending".
Authorization that is is "processing/validating", "valid" or "invalid".

> problem with servers not having a good Retry-After estimate?

I suspect vast majority of clients can not tell if validation requests
have been seen or not. And yes, there better be multiple, or one gets
attacks (routing and stale address).

-Ilari

---

From: Sophie Herold <[email-masked]>
Date: Sun, 7 Jan 2018 18:24:55 +0100

Hi,

> Authorization that is is "processing/validating", "valid" or "invalid".

Yes, but I was talking about challenges, not authorizations.

I think, eventually this part should be fixed:

   challenges (required, array of objects): For pending authorizations,
   the challenges that the client can fulfill in order to prove
   possession of the identifier. For final authorizations (in the
   "valid" or "invalid" state), the challenges that were used.

The authorization status of 'processing' is not covered here. The server
can forget about the other challenges as soon as the authorization is no
longer pending i.e. 'processing'. Trying another challenge after failure
isn't allowed anyways. If there is only one challenge remaining, it is
clear that this is the one, that is validated/processed by the server.

Best,
Sophie