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
