On 11/20/2017 08:24 PM, Martin Thomson wrote:
> Is this better cast as "sub" problems, or just "additional" problems?
I think "additional" is the wrong semantic, because it implies that the
first error is hoisted to the top position, so a naive client would only
show the first error. Instead, there's a top-level generic error ("some
identifiers were rejected"), and then there are potentially multiple
errors that are part of it (_example.com, example.net).
> On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews <[email protected]> wrote:
>> I've submitted a PR adding this to the spec:
>>
>> https://github.com/ietf-wg-acme/acme/pull/354
>>
>> commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18
>> Author: Jacob Hoffman-Andrews <[email protected]>
>> Date: Mon Nov 20 15:14:29 2017 -0800
>>
>> Define sub-problems.
>>
>> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
>> index a2c11ab..a9e3535 100644
>> --- a/draft-ietf-acme-acme.md
>> +++ b/draft-ietf-acme-acme.md
>> @@ -521,6 +521,53 @@ set to a URI other than those defined above.
>> Servers MUST NOT use the ACME URN
>> namespace for errors other than the standard types. Clients SHOULD
>> display the
>> "detail" field of all errors.
>>
>> +### Sub-problems
>> +
>> +Sometimes a CA may need to return multiple errors to a single
>> +request. Additionally, the CA may need to attribute errors to specific
>> +identifiers. For instance, a new-order request may contain multiple
>> +identifiers for which the CA cannot issue. In this situation, an ACME
>> +problem document MAY contain the "sub-problems" field, contains a JSON
>> +array of problem documents, each of which MAY contain an "identifier"
>> +field. If present, the "identifier" field MUST contain an ACME identifier
>> +({{iana-identifier}}). The "identifier" field MUST NOT be present at
>> +the top level in ACME problem documents. It can only be present in
>> sub-problems.
>> +Sub-problems need not all have the same type, and do not need to match
>> the top level type.
>> +
>> +ACME clients may choose to use the "identifier" field as a hint that
>> +an operation would succeed if certain identifiers were omitted. For
>> +instance, if an order contains ten DNS identifiers, and the new-order
>> +request returns a problem document with two sub-problems, referencing two
>> +of those identifiers, the ACME client may choose to submit another order
>> +containing only the eight identifiers not listed in the problem document.
>> +
>> +~~~~~
>> +HTTP/1.1 403 Forbidden
>> +Content-Type: application/problem+json
>> +
>> +{
>> + "type": "urn:ietf:params:acme:error:malformed",
>> + "detail": "Some of the identifiers requested were rejected",
>> + "sub-problems": [
>> + {
>> + "type": "urn:ietf:params:acme:error:malformed",
>> + "value": "Invalid underscore in DNS name \"_example.com\"",
>> + "identifier": {
>> + "type": "dns",
>> + "value": "_example.com"
>> + }
>> + },
>> + {
>> + "type": "urn:ietf:params:acme:error:rejectedIdentifier",
>> + "value": "This CA will not issue for \"example.net\"",
>> + "identifier": {
>> + "type": "dns",
>> + "value": "example.net"
>> + }
>> + }
>> + ]
>> +}
>> +~~~~~
>>
>> # Certificate Management
>>
>> _______________________________________________
>> Acme mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
