Draft: draft-ietf-acme-acme

Commentary: requests are allowed to send DNS type identifiers with a value that contains a wildcard prefix ( '' ) as the leftmost label . The authorization object created for the wildcard identifiers in the requests are not allowed to carry the wildcard prefix in the authorization identifier per spec language : This is sensible because the authorization is not for the logical wildcard but for the specific base domain . This leaves an ambiguous situation for client developers / users . Imagine a situation where a user requests a new order with the following request body : It 's possible two authorizations will be created for this case , but both will contain the identifier . This can be confusing to users ! ( e.g. shred / acme4j ) If one of the authorizations fails a challenge validation operation the client ca n't know whether it was the " " validation , or the " * " validation that failed and wo n't be able to prompt the user to retry with the failed domain removed . Generally speaking it makes presenting accurate error information difficult without over - fitting Let 's  's particular Wildcard issuance policies . ( E.g. see discussion in and ) This commit introduces an optional boolean authorization field that can be used to indicate the authorization 's identifier should be considered the base domain of a wildcard identifier that was requested . This replaces , which included the baggage of .
Paragraph (version A):
Any identifier of type "dns" in a new-order request MAY have a
wildcard domain name as its value.  A wildcard domain name consists
of a single asterisk character followed by a single full stop
character ("*.") followed by a domain name as defined for use in the
Subject Alternate Name Extension by RFC 5280 RFC5280.  An
authorization returned by the server for a wildcard domain name
identifier MUST NOT include the asterisk and full stop ("*.") prefix
in the authorization identifier value.
Paragraph (version B):
Any identifier of type "dns" in a new-order request MAY have a
wildcard domain name as its value.  A wildcard domain name consists
of a single asterisk character followed by a single full stop
character ("*.") followed by a domain name as defined for use in the
Subject Alternate Name Extension by RFC 5280 RFC5280.  An
authorization returned by the server for a wildcard domain name
identifier MUST NOT include the asterisk and full stop ("*.") prefix
in the authorization identifier value.  The returned authorization
MUST include the optional "wildcard" field, with a value of true.
Paragraph (version A):
The only type of identifier defined by this specification is a fully-
qualified domain name (type: "dns").  If a domain name contains non-
ASCII Unicode characters it MUST be encoded using the rules defined
in RFC3492.  Servers MUST verify any identifier values that begin
with the ASCII Compatible Encoding prefix "xn--" as defined in
RFC5890 are properly encoded.  Wildcard domain names (with "*" as the
first label) MUST NOT be included in authorization objects.
Paragraph (version B):
For authorizations created as a result of a newOrder request
containing a DNS identifier with a value that contained a wildcard
prefix this field MUST be present, and true.
Paragraph (version B):
The only type of identifier defined by this specification is a fully-
qualified domain name (type: "dns").  If a domain name contains non-
ASCII Unicode characters it MUST be encoded using the rules defined
in RFC3492.  Servers MUST verify any identifier values that begin
with the ASCII Compatible Encoding prefix "xn--" as defined in
RFC5890 are properly encoded.  Wildcard domain names (with "*" as the
first label) MUST NOT be included in authorization objects.  If an
authorization object conveys authorization for the base domain of a
newOrder DNS type identifier with a wildcard prefix then the optional
authorizations "wildcard" field MUST be present with a value of true.