Re: [Acme] Clarify that newAuthz endpoint is optional

2018-01-05 Thread Richard Barnes 
I merged.

On Fri, Jan 5, 2018 at 4:43 PM, Daniel McCarney  wrote:

> Why not a MUST? If you don't implement preauthorization, there's no need
>> for a value.  I guess you could provide "null", but ... don't.
>
>
> I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my
> PR branch.
>
> - Daniel / cpu
>
> On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes  wrote:
>
>> Why not a MUST? If you don't implement preauthorization, there's no need
>> for a value.  I guess you could provide "null", but ... don't.
>>
>> On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney 
>> wrote:
>>
>>> Hi Ilari,
>>>
>>>
 This impiles that if pre-authorization is not supported, newAuthz
 better be absent (this is also useful for detecting pre-authorization
 support if the client can use it somehow).
 I think this should be at least a SHOULD.
>>>
>>>
>>> You're right. My intention is to make the presence of that field an
>>> indicator of pre-authorization support (or lack thereof). I'll update to a
>>> SHOULD in my PR since I agree that maps better.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <
>>> ilariliusva...@welho.com> wrote:
>>>
 On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
 > In Section 7.4.1 "Pre-Authorization" the spec says:
 >
 >  If a CA wishes to allow pre-authorization within ACME, it can offer
 > >  a "new authorization" resource in its directory by adding the field
 > >  "newAuthz" with a URL for the new authorization resource.
 >
 >
 > That text indicates that the CA may wish to *not* support
 pre-authorization
 > in which case the "newAuthz" resource will not be present in the
 directory.
 > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
 resource.
 >
 > I think this should be further emphasized in Section 7.1.1 "Directory"
 > since this is where a developer is likely to look first when trying to
 > determine what directory fields can be assumed present.
 >
 > I opened a PR to add a small note about this to Section 7.1.1:
 > https://github.com/ietf-wg-acme/acme/pull/384
 >
 > This is perhaps a step past the line of being strictly editorial. I
 would
 > appreciate if anyone with objections raise them on-thread over the
 next few
 > days.

 Why MAY? If implementation does not support some functionality that an
 endpoint is exclusively for, it better omit that endpoint. This impiles
 that if pre-authorization is not supported, newAuthz better be absent
 (this is also useful for detecting pre-authorization support if the
 client can use it somehow).

 I think this should be at least a SHOULD.



 -Ilari

>>>
>>>
>>> ___
>>> 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] Clarify that newAuthz endpoint is optional

2018-01-05 Thread Daniel McCarney 
>
> Why not a MUST? If you don't implement preauthorization, there's no need
> for a value.  I guess you could provide "null", but ... don't.


I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my PR
branch.

- Daniel / cpu

On Fri, Jan 5, 2018 at 4:24 PM, Richard Barnes  wrote:

> Why not a MUST? If you don't implement preauthorization, there's no need
> for a value.  I guess you could provide "null", but ... don't.
>
> On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney 
> wrote:
>
>> Hi Ilari,
>>
>>
>>> This impiles that if pre-authorization is not supported, newAuthz better
>>> be absent (this is also useful for detecting pre-authorization support if
>>> the client can use it somehow).
>>> I think this should be at least a SHOULD.
>>
>>
>> You're right. My intention is to make the presence of that field an
>> indicator of pre-authorization support (or lack thereof). I'll update to a
>> SHOULD in my PR since I agree that maps better.
>>
>> Thanks!
>>
>>
>>
>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara > > wrote:
>>
>>> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
>>> > In Section 7.4.1 "Pre-Authorization" the spec says:
>>> >
>>> >  If a CA wishes to allow pre-authorization within ACME, it can offer
>>> > >  a "new authorization" resource in its directory by adding the field
>>> > >  "newAuthz" with a URL for the new authorization resource.
>>> >
>>> >
>>> > That text indicates that the CA may wish to *not* support
>>> pre-authorization
>>> > in which case the "newAuthz" resource will not be present in the
>>> directory.
>>> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
>>> resource.
>>> >
>>> > I think this should be further emphasized in Section 7.1.1 "Directory"
>>> > since this is where a developer is likely to look first when trying to
>>> > determine what directory fields can be assumed present.
>>> >
>>> > I opened a PR to add a small note about this to Section 7.1.1:
>>> > https://github.com/ietf-wg-acme/acme/pull/384
>>> >
>>> > This is perhaps a step past the line of being strictly editorial. I
>>> would
>>> > appreciate if anyone with objections raise them on-thread over the
>>> next few
>>> > days.
>>>
>>> Why MAY? If implementation does not support some functionality that an
>>> endpoint is exclusively for, it better omit that endpoint. This impiles
>>> that if pre-authorization is not supported, newAuthz better be absent
>>> (this is also useful for detecting pre-authorization support if the
>>> client can use it somehow).
>>>
>>> I think this should be at least a SHOULD.
>>>
>>>
>>>
>>> -Ilari
>>>
>>
>>
>> ___
>> 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] Clarify that newAuthz endpoint is optional

2018-01-05 Thread Richard Barnes 
Why not a MUST? If you don't implement preauthorization, there's no need
for a value.  I guess you could provide "null", but ... don't.

On Fri, Jan 5, 2018 at 2:33 PM, Daniel McCarney  wrote:

> Hi Ilari,
>
>
>> This impiles that if pre-authorization is not supported, newAuthz better
>> be absent (this is also useful for detecting pre-authorization support if
>> the client can use it somehow).
>> I think this should be at least a SHOULD.
>
>
> You're right. My intention is to make the presence of that field an
> indicator of pre-authorization support (or lack thereof). I'll update to a
> SHOULD in my PR since I agree that maps better.
>
> Thanks!
>
>
>
> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara 
> wrote:
>
>> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
>> > In Section 7.4.1 "Pre-Authorization" the spec says:
>> >
>> >  If a CA wishes to allow pre-authorization within ACME, it can offer
>> > >  a "new authorization" resource in its directory by adding the field
>> > >  "newAuthz" with a URL for the new authorization resource.
>> >
>> >
>> > That text indicates that the CA may wish to *not* support
>> pre-authorization
>> > in which case the "newAuthz" resource will not be present in the
>> directory.
>> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
>> resource.
>> >
>> > I think this should be further emphasized in Section 7.1.1 "Directory"
>> > since this is where a developer is likely to look first when trying to
>> > determine what directory fields can be assumed present.
>> >
>> > I opened a PR to add a small note about this to Section 7.1.1:
>> > https://github.com/ietf-wg-acme/acme/pull/384
>> >
>> > This is perhaps a step past the line of being strictly editorial. I
>> would
>> > appreciate if anyone with objections raise them on-thread over the next
>> few
>> > days.
>>
>> Why MAY? If implementation does not support some functionality that an
>> endpoint is exclusively for, it better omit that endpoint. This impiles
>> that if pre-authorization is not supported, newAuthz better be absent
>> (this is also useful for detecting pre-authorization support if the
>> client can use it somehow).
>>
>> I think this should be at least a SHOULD.
>>
>>
>>
>> -Ilari
>>
>
>
> ___
> 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] Clarify that newAuthz endpoint is optional

2018-01-05 Thread Daniel McCarney 
Hi Ilari,


> This impiles that if pre-authorization is not supported, newAuthz better
> be absent (this is also useful for detecting pre-authorization support if
> the client can use it somehow).
> I think this should be at least a SHOULD.


You're right. My intention is to make the presence of that field an
indicator of pre-authorization support (or lack thereof). I'll update to a
SHOULD in my PR since I agree that maps better.

Thanks!



On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara 
wrote:

> On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
> > In Section 7.4.1 "Pre-Authorization" the spec says:
> >
> >  If a CA wishes to allow pre-authorization within ACME, it can offer
> > >  a "new authorization" resource in its directory by adding the field
> > >  "newAuthz" with a URL for the new authorization resource.
> >
> >
> > That text indicates that the CA may wish to *not* support
> pre-authorization
> > in which case the "newAuthz" resource will not be present in the
> directory.
> > E.g. the Let's Encrypt ACME v2 directory[0] does not include this
> resource.
> >
> > I think this should be further emphasized in Section 7.1.1 "Directory"
> > since this is where a developer is likely to look first when trying to
> > determine what directory fields can be assumed present.
> >
> > I opened a PR to add a small note about this to Section 7.1.1:
> > https://github.com/ietf-wg-acme/acme/pull/384
> >
> > This is perhaps a step past the line of being strictly editorial. I would
> > appreciate if anyone with objections raise them on-thread over the next
> few
> > days.
>
> Why MAY? If implementation does not support some functionality that an
> endpoint is exclusively for, it better omit that endpoint. This impiles
> that if pre-authorization is not supported, newAuthz better be absent
> (this is also useful for detecting pre-authorization support if the
> client can use it somehow).
>
> I think this should be at least a SHOULD.
>
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Clarify that newAuthz endpoint is optional

2018-01-05 Thread Ilari Liusvaara 
On Fri, Jan 05, 2018 at 02:05:22PM -0500, Daniel McCarney wrote:
> In Section 7.4.1 "Pre-Authorization" the spec says:
> 
>  If a CA wishes to allow pre-authorization within ACME, it can offer
> >  a "new authorization" resource in its directory by adding the field
> >  "newAuthz" with a URL for the new authorization resource.
> 
> 
> That text indicates that the CA may wish to *not* support pre-authorization
> in which case the "newAuthz" resource will not be present in the directory.
> E.g. the Let's Encrypt ACME v2 directory[0] does not include this resource.
> 
> I think this should be further emphasized in Section 7.1.1 "Directory"
> since this is where a developer is likely to look first when trying to
> determine what directory fields can be assumed present.
> 
> I opened a PR to add a small note about this to Section 7.1.1:
> https://github.com/ietf-wg-acme/acme/pull/384
> 
> This is perhaps a step past the line of being strictly editorial. I would
> appreciate if anyone with objections raise them on-thread over the next few
> days.

Why MAY? If implementation does not support some functionality that an
endpoint is exclusively for, it better omit that endpoint. This impiles
that if pre-authorization is not supported, newAuthz better be absent
(this is also useful for detecting pre-authorization support if the
client can use it somehow).

I think this should be at least a SHOULD.



-Ilari

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