I think this is a solid proposal addressing a real need. I'm +1 for supporting it both in spec and in Boulder/Pebble.
Thanks Jacob, On Wed, Nov 15, 2017 at 8:23 PM, Jacob Hoffman-Andrews <[email protected]> wrote: > In previous versions of ACME, there was sometimes a need to return > multiple errors, broken out by domain name. For instance, when issuing a > certificate by making a new-cert request, the CA has to check CAA, which > may fail for multiple domains. Ideally, the client should not have to > guess which identifiers (domains) failed, or engage in string parsing. > So far, this hasn't been terrible because *most* errors occur during > new-authz or during validation, and so are implicitly associated with a > specific identifier. > > However, in the latest spec, this problem is a lot worse. Since all > issuance starts with new-order, which can request multiple identifiers, > all attempts to issue for multiple identifiers will potentially fail for > one or more of those identifiers. > > Fortunately, JSON problem details provide enough flexibility for this, > with problem-specific extensions > (https://tools.ietf.org/html/rfc7807#page-4). I propose we define a > field, "sub-problems", on all ACME problem types. This field would > contain a list of JSON problem details, each of which may contain an > identifier. So for instance, you might receive this response from a > new-order request: > > { > "type": "urn:ietf:params:acme:error:malformed", > "detail": "Some of the identifiers requested were rejected", > "sub-problems": [ { > "identifier": { "value": "_example.com", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "Invalid underscore in DNS name \"_example.com\"", > }, { > "identifier": { "value": "example.net", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "\"example.net\" is considered a high-risk domain", > } ] > } > > That way, clients that issue for large numbers of domains may choose to > automatically retry new-order with the problem identifiers removed. > > Thoughts? > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
