Proposal Details

The x/crypto/acme package provides methods for polling ACME objects, currently it has:

• WaitAuthorization
• WaitOrder

These methods block until until the desired state is reached and internally respect the Retry-After header if provided by the ACME server as part of its polling logic.

Sometimes using a blocking method is not practical, for example in Kubernetes control loops. In this case case the Get methods can be used to return the Authorization or Order, allowing polling to be implemented by the API consumer. However since the Authorization and Order structs do not expose the Retry-After header as a field it cannot be respected by any external polling implementations.

I propose adding a RetryAfter field to the Order, Authorization and Challenge structs as these are the objects the ACME RFC specifies may have this header:

• Order - when an order is "processing" (cert is currently being issued) then it is set (RFC 8555 §7.4)
• Authorization - when the authorization is still in progress the Retry-After header may be set (RFC 8555 §7.5.1)
• Challenge - if a challenge is currently being retried the Retry-After header should be set to indicate when the next challenge attempt will be complete (RFC 8555 §8.2)

The RetryAfter would be a time.Duration and would be 0 if not provided by the ACME server.