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
