Subject: [Acme] New-application flow and retries

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 12 Sep 2016 14:27:57 -0700

Currently, Let's Encrypt considers each authorization a one-shot. Once a
client POSTs to a challenge URL, the server validates the challenge and
changes the authorization status to either "valid" or "invalid."

Under the new-application flow, this becomes more awkward. If you
request a certificate with 50 names on it, and successfully validate 49
of those names, then fail the 50th, you would need to create a whole new
application object. The server can reuse the 49 successful validations,
but it's fairly common for a user to need to retry repeatedly. For
instance, their server may be misconfigured in a way that is not
immediately obvious, for instance with an over-aggressive firewall.

In this common case, the server needs to store an application object for
each retry. Application objects are more expensive than authorization
objects because they contain full CSRs, which commonly contain full RSA
keys. They also need to contain a list of associated authorization
objects. We'd like to minimize the amount of storage required by such
repeated retries.

Also, I suspect that the existing infrastructure of other CAs does not
consider an order canceled if a single validation attempt fails, which
means the current one-shot approach is not a good match.

I'm thinking we may need to make challenges retryable (up to some
server-set limit). This would mean making the Error and ValidationRecord
fields capable of representing multiple errors and multiple validation
attempts, and potentially adding a new state to authorization objects:
"errored, but retryable."

Advantages:
 - Reduces storage cost for repeated failures.
 - Allows a client to try multiple times using the same token.
 - Potentially better match with non-Let's Encrypt CAs' workflow.

Disadvantages:
 - Adds significant complexity to protocol.

I'm interested in feedback and opinions, and possible alternate approaches.

Thanks,
Jacob

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 21 Sep 2016 16:19:23 -0700

Does anyone have opinions on how retrying authorizations should work?
I'll work on writing it up, but it would be helpful to have early feedback.

On 09/12/2016 02:27 PM, Jacob Hoffman-Andrews wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Hugo Landau <[email-masked]>
Date: Sun, 25 Sep 2016 02:13:06 +0100

If you're going to make this change I'd also consider changing
authorizations so that the failure of individual challenges is nonfatal
to the authorization if there are other challenges which could be
completed to satisfy the authorization. This would be useful in addition
to the ability to retry authorizations as a whole. Which could perhaps
be implemented by allowing authorizations to be "reset" by an explicit
action performed on them, which restores challenges to their initial
state.

Resetting an authorization could create a new authorization, change all
references in any applications to refer to it, and leave the old one for
audit purposes, then return the new URI. Or it could simply mutate the
existing authorization resource. In this case, the old version could be
kept internally for audit purposes but wouldn't be exposed in the
protocol.