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
