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
