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
