>
> I would propose we stick with a simpler solution here. While Sophie's
> solution does seem more general, in the interest of getting the spec
> shipped, I would propose we just add the boolean flag and write an
> extension spec if a more general solution is needed.
That sounds sensible to me. +1
On Fri, Mar 2, 2018 at 5:22 PM, Richard Barnes <r...@ipv.sx> wrote:
> This is seeming like a lot of work for a pretty minor use case.
>
> I would propose we stick with a simpler solution here. While Sophie's
> solution does seem more general, in the interest of getting the spec
> shipped, I would propose we just add the boolean flag and write an
> extension spec if a more general solution is needed.
>
> --Richard
>
>
> On Fri, Mar 2, 2018 at 4:58 PM, Daniel McCarney <c...@letsencrypt.org>
> wrote:
>
>> This sounds like you want to provide the order identifiers that
>>> triggered this authorization within the authorization object?
>>
>>
>> Generally speaking yes.
>>
>> In principle, several order identifiers could lead to a single
>>> authorization I guess?
>>>
>>
>> I think in principle that's true. ACME doesn't prescribe that there be a
>> single authorization per-identifier. Perhaps Wildcards are just the most
>> immediate case of there being a disconnect between the order identifiers
>> and the authorizations. I was thinking only of identifier value but you're
>> right that there may be a disconnect in the quantity of order
>> authorizations compared to requested identifiers.
>>
>> It would be helpful if a CA with intentions to implement an issuance
>> policy that differs from "n order identifiers, n authorizations" would
>> speak up. I'm partial to the optional bool field because its very simple.
>> Your proposal is more robust but also a bigger change and I'd like to know
>> someone in the real world will benefit from the work involved :-)
>>
>> - Daniel / cpu
>>
>>
>> On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold <sophie_her...@hemio.de>
>> wrote:
>>
>>> On 02/03/18 18:32, Daniel McCarney wrote:
>>> > Richard: That's up to the client and the situation. In the linked
>>> Certbot
>>> > issues there were questions about error output/UX. In this case if the
>>> > client saw an error attached to an authorization with the identifier `{
>>> > "type": "dns", "value": "example.com"}` and the authorization had
>>> > `wildcard: true` the client could say "Failed to authorize *.
>>> example.com:
>>> > blah blah blah" or otherwise use the knowledge to inform their actions
>>> > (whatever they may be).
>>>
>>> This sounds like you want to provide the order identifiers that
>>> triggered this authorization within the authorization object?
>>>
>>> I think, in general it is just a guess that exmaple.com + wildcard means
>>> that the order contains *.example.com. This depends on which
>>> authorizations are created for which order identifiers, which is not
>>> specified by acme.
>>>
>>> In principle, several order identifiers could lead to a single
>>> authorization I guess? For example, if sub1.example.org and
>>> sub2.example.org lead to just an example.org authorization. Therefore
>>> "orderIdentifiers", as I call it here, needs to be a list:
>>>
>>> {
>>> "status": "valid",
>>> "expires": "2015-03-01T14:09:00Z",
>>>
>>> "identifier": {
>>> "type": "dns",
>>> "value": "example.org"
>>> },
>>>
>>> "orderIdentifiers": [
>>> {
>>> "type": "dns",
>>> "value": "*.example.org"
>>> }
>>> ],
>>>
>>> "challenges": [
>>> …
>>>
>>> Best,
>>> Sophie
>>>
>>> _______________________________________________
>>> 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
