In a similar vein, another small but real world example where this being
standardized would be useful is Certbot has the flag —allow-subset-of-names
that causes it to not treat it as a failure if you cannot complete all
authorizations and instead obtain a certificate only for the identifiers you
were able to successfully obtain valid authorizations for. We currently don’t
support this wildcards because we’re unable to differentiate an authorization
for a wildcard from one for the base domain.
> On Mar 2, 2018, at 12:24 PM, Richard Körber <a...@ml.shredzone.de> wrote:
>
> Hi!
>
> I also see the problem that clients might get confused because there are
> seemingly two authentications for the very same domain ("example.com").
> Without a proper flag, they could only be distinguished by the different set
> of challenges, but that would assume knowledge of server internas.
>
> Also, the client could actively validate the authorization having
> wildcard=true first, and then could check if it is still necessary to do the
> other authorization. Depending on the server implementation, if verifying the
> wildcard domain also validates the domain itself, it could save an unnecessary
> challenge round trip.
>
> --
> Richard Körber
>
>
> Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
>> One (fairly) obvious use of the “wildcard” flag is for status reporting
>> without the context of the original newOrder. The client can thus more
>> easily say:
>>
>> Authorization for “*.example.com”: $message
>>
>> … without having to correlate the authz object with the order.
>>
>> -FG
>>
>>> On Mar 2, 2018, at 12:32 PM, Daniel McCarney <c...@letsencrypt.org> 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).
>>>
>>> In general I think there will be reason for client developers will want to
>>> have a standardized way of understanding if an authorization corresponds to
>>> a wildcard identifier or not. I'm hopeful some client developers will chime
>>> in with more concrete examples, I'm a server-side grunt.
>>>
>>> - Daniel / cpu
>>>
>>> On Fri, Mar 2, 2018 at 12:29 PM, Richard Barnes <r...@ipv.sx> wrote:
>>> Daniel: I don't have a strong objection here, but could you elaborate what
>>> the client is expected to do differently based on this flag?
>>>
>>> On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney <c...@letsencrypt.org>
>>> wrote:
>>> Hi folks,
>>>
>>> There is a slight disconnect with the current specification between
>>> identifiers in newOrder/newAuthz requests and identifiers in authorization
>>> objects. The former is allowed to include wildcard domains in the value of
>>> DNS type identifiers while the latter is forbidden.
>>>
>>> Let's Encrypt's implementation of ACME wildcard issuance guessed this might
>>> lead to confusion and introduced a non-standardized "Wildcard" boolean
>>> field in authorization objects. If true, then the identifier value in the
>>> authorization identifier is known to be the base domain corresponding to a
>>> wildcard identifier from the newOrder/newAuthz request.
>>>
>>> I think it would be beneficial to the entire ecosystem if this optional
>>> "wildcard" authz field could be standardized so I've sent a small PR:
>>> https://github.com/ietf-wg-acme/acme/pull/402 Both Certbot and ACME4J have
>>> independently bumped into this disconnect, which helps justify the need.
>>>
>>> - Daniel / cpu
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> 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
