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.
On Wed, Sep 21, 2016 at 04:19:23PM -0700, Jacob Hoffman-Andrews wrote:
> 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:
> > 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
> >
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
