Currently, when an order is created, authorizations are created for it, and challenges are created for each of those authorizations.
If a challenge is failed once, the challenge comes to have status "invalid", as does the authorization containing it. The order containing the authorization becomes unfulfillable. This is highly undesirable because it is not necessarily possible to discern ahead of time which challenges will succeed and which will fail for a given hostname. Moreover, random failures or failures due to differing viewpoints (e.g. DNS propagation for DNS challenges) increase the likelihood that a given challenge will fail. This is a particular problem for DNS challenges, where it can be unclear when propagation is complete, but also affects other challenge types. Where there is doubt as to the challenges which will be successful for a given hostname, different methods may be attempted by a client in sequence. If the failure of a challenge results in the failure of an entire order, this results in an excessively large number of failed and wasted order, authorization and challenge objects. For example, if a CA which allows up to 100 SANs in each certificate supports three challenge methods (e.g. HTTP, TLS-SNI, DNS), successful completion of the order could involve the creation of about 120,300 objects. (Assume that every time, only the last challenge method attempted of the three methods available is successful. For each attempt, 401 objects are created (1 order, 100 authorizations and 300 challenges). 300 attempts are required: 3 for each authorization.) Although this may be avoidable using new-authz, the intention is clearly to prefer the new-order workflow, support for the new-authz endpoint is not mandatory, and the new-authz endpoint may not be usable for some use cases, such as wildcard domains. The following resolutions are possible: 1. Allow challenges to be retried. Optionally, this could include the removal of the "invalid" status for challenges; there would be only "pending" and "valid". If audit trails are desired, challenge failures would be indicated by appending error objects to a "failedValidations" array, not by changing a status field. Challenge failures during polling would be detected by observing increases in the length of this array. 2. Allow challenges to be regenerated via request, in a fresh, pending state. The challenge URL is changed. The old challenge remains accessible at the old URL for auditing purposes, but the authorization is updated to reference the new challenge URL where previously it updated the old one. 3. Allow authorizations to be regenerated via request. Like challenge regeneration, the authorization URL in the order object would be replaced, and the old authorization would remain accessible at the old URL. 4. Don't change anything about the current specification. This is highly inefficient, insofar that it inflates the number of database objects which must be generated and stored by a CA. It also increases the time that the issuance process will take very substantially. I'd prefer option 1. Thoughts? Hugo Landau _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
