Subject: [Acme] Optional "Wildcard" authorization field

From: Daniel McCarney <[email-masked]>
Date: Fri, 2 Mar 2018 12:22:07 -0500

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Mar 2018 12:29:02 -0500

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 <[email-masked]>
wrote:

> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 2 Mar 2018 12:32:47 -0500

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

---

From: Felipe Gasper <[email-masked]>
Date: Fri, 2 Mar 2018 13:28:59 -0500

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 <[email-masked]> 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
> 
> 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 <[email-masked]> 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
> 
> 
> 
>

---

From: Richard Körber <[email-masked]>
Date: Fri, 2 Mar 2018 21:26:04 +0100

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

---

From: Richard Körber <[email-masked]>
Date: Fri, 2 Mar 2018 21:24:09 +0100

Hi!

-- 
Richard Körber

---

From: Brad Warren <[email-masked]>
Date: Fri, 2 Mar 2018 12:46:14 -0800

In a similar vein, another small but real world example where this being standardized would be useful is Certbot has the flag —allow-subset-of-names that causes it to not treat it as a failure if you cannot complete all authorizations and instead obtain a certificate only for the identifiers you were able to successfully obtain valid authorizations for. We currently don’t support this wildcards because we’re unable to differentiate an authorization for a wildcard from one for the base domain.
 
> On Mar 2, 2018, at 12:24 PM, Richard Körber <[email-masked]> wrote:
> 
> Hi!
>

---

From: Sophie Herold <[email-masked]>
Date: Fri, 2 Mar 2018 21:46:45 +0100

> blah blah blah" or otherwise use the knowledge to inform their actions

This sounds like you want to provide the order identifiers that
triggered this authorization within the authorization object?

I think, in general it is just a guess that exmaple.com + wildcard means
that the order contains *.example.com. This depends on which
authorizations are created for which order identifiers, which is not
specified by acme.

In principle, several order identifiers could lead to a single
authorization I guess? For example, if sub1.example.org and
sub2.example.org lead to just an example.org authorization. Therefore
"orderIdentifiers", as I call it here, needs to be a list:

   {
     "status": "valid",
     "expires": "2015-03-01T14:09:00Z",

     "identifier": {
       "type": "dns",
       "value": "example.org"
     },

     "orderIdentifiers": [
       {
         "type": "dns",
         "value": "*.example.org"
       }
     ],

     "challenges": [
     …

Best,
Sophie

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 2 Mar 2018 16:58:17 -0500

> triggered this authorization within the authorization object?

Generally speaking yes.

> authorization I guess?

I think in principle that's true. ACME doesn't prescribe that there be a
single authorization per-identifier. Perhaps Wildcards are just the most
immediate case of there being a disconnect between the order identifiers
and the authorizations. I was thinking only of identifier value but you're
right that there may be a disconnect in the quantity of order
authorizations compared to requested identifiers.

It would be helpful if a CA with intentions to implement an issuance policy
that differs from "n order identifiers, n authorizations" would speak up.
I'm partial to the optional bool field because its very simple. Your
proposal is more robust but also a bigger change and I'd like to know
someone in the real world will benefit from the work involved :-)

- Daniel / cpu

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Mar 2018 17:22:20 -0500

This is seeming like a lot of work for a pretty minor use case.

I would propose we stick with a simpler solution here.  While Sophie's
solution does seem more general, in the interest of getting the spec
shipped, I would propose we just add the boolean flag and write an
extension spec if a more general solution is needed.

--Richard

On Fri, Mar 2, 2018 at 4:58 PM, Daniel McCarney <[email-masked]> wrote:

> It would be helpful if a CA with intentions to implement an issuance
> policy that differs from "n order identifiers, n authorizations" would
> speak up. I'm partial to the optional bool field because its very simple.
> Your proposal is more robust but also a bigger change and I'd like to know

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 2 Mar 2018 17:23:23 -0500

> extension spec if a more general solution is needed.

That sounds sensible to me. +1