Subject: [Acme] Clarify that newAuthz endpoint is optional

From: Daniel McCarney <[email-masked]>
Date: Fri, 5 Jan 2018 14:05:22 -0500

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.

- Daniel / cpu

[0] - https://acme-staging-v02.api.letsencrypt.org/directory

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 5 Jan 2018 21:27:53 +0200

> appreciate if anyone with objections raise them on-thread over the next few

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

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 5 Jan 2018 14:33:53 -0500

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

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!

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Jan 2018 16:24:12 -0500

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

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 5 Jan 2018 16:43:09 -0500

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

>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <[email-masked]
>> > wrote:
>>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 5 Jan 2018 18:02:39 -0500

I merged.

On Fri, Jan 5, 2018 at 4:43 PM, Daniel McCarney <[email-masked]> wrote:

> I have no objections to using MUST over SHOULD. Updated in 5fcaa6c on my
> PR branch.
>
> - Daniel / cpu
>
>>>> 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).
>>> On Fri, Jan 5, 2018 at 2:27 PM, Ilari Liusvaara <
>>> [email-masked]> wrote:
>>>