On Sat, Jan 06, 2018 at 03:40:54PM +0100, Sophie Herold wrote:
> 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.
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.
> 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.
I think either:
- Client should check the overall status of order.
- Client should check the overall status of all authorizations.
> 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
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
> 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".
Yeah, looks like many statuses are poorly defined.
> 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".
Well, authorization that has not been responded to is "pending".
Authorization that is is "processing/validating", "valid" or "invalid".
> 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?
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
