Re: [Acme] Optional "Wildcard" authorization field

[Daniel McCarney]

>
> 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.


That sounds sensible to me. +1



On Fri, Mar 2, 2018 at 5:22 PM, Richard Barnes  wrote:

> 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 
> wrote:
>
>> This sounds like you want to provide the order identifiers that
>>> triggered this authorization within the authorization object?
>>
>>
>> Generally speaking yes.
>>
>> In principle, several order identifiers could lead to a single
>>> 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
>>
>>
>> On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold 
>> wrote:
>>
>>> On 02/03/18 18:32, Daniel McCarney 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).
>>>
>>> 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
>>>
>>> ___
>>> 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

Re: [Acme] Optional "Wildcard" authorization field

[Richard Barnes]

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  wrote:

> This sounds like you want to provide the order identifiers that
>> triggered this authorization within the authorization object?
>
>
> Generally speaking yes.
>
> In principle, several order identifiers could lead to a single
>> 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
>
>
> On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold 
> wrote:
>
>> On 02/03/18 18:32, Daniel McCarney 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).
>>
>> 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
>>
>> ___
>> 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

Re: [Acme] Optional "Wildcard" authorization field

[Daniel McCarney]

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


Generally speaking yes.

In principle, several order identifiers could lead to a single
> 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


On Fri, Mar 2, 2018 at 3:46 PM, Sophie Herold 
wrote:

> On 02/03/18 18:32, Daniel McCarney 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).
>
> 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
>
> ___
> 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

Re: [Acme] Optional "Wildcard" authorization field

[Sophie Herold]

On 02/03/18 18:32, Daniel McCarney 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).

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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Optional "Wildcard" authorization field

[Brad Warren]

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  wrote:
> 
> 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
> 
> 
> Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
>> 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  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  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  
>>> 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
>> 
> 
> ___
> 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

Re: [Acme] Optional "Wildcard" authorization field

[Richard Körber]

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


Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
> 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  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  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  
>> 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
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Optional "Wildcard" authorization field

[Richard Körber]

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


Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
> 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  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  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  
>> 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
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Optional "Wildcard" authorization field

[Felipe Gasper]

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  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  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  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

Re: [Acme] Optional "Wildcard" authorization field

[Daniel McCarney]

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  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 
> 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

Re: [Acme] Optional "Wildcard" authorization field

[Richard Barnes]

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 
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] Optional "Wildcard" authorization field

[Daniel McCarney]

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