Re: [Acme] Clarify that newAuthz endpoint is optional

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

[Acme] Let's Encrypt draft-09 test endpoint

The list may be interested to know Let's Encrypt has made a test environment available based on ACME draft-09. The announcement post with more details is available here: https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605 Compatible clients can be configured with the

Re: [Acme] Clarify that newAuthz endpoint is optional

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

[Acme] Clarify that newAuthz endpoint is optional

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

[Acme] Usage of "unspecified" reason code in CRL / OCSP

Hello, https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.6 states: If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs. Yet https://tools.ietf.org/html/rfc5280#section-5.3.1 says the

Re: [Acme] Usage of "unspecified" reason code in CRL / OCSP

Good point. Posted a PR: https://github.com/ietf-wg-acme/acme/pull/385 On Fri, Jan 5, 2018 at 6:03 PM, Jörn Heissler wrote: > Hello, > > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.7.6 > states: > > If this field is not set the

Re: [Acme] Clarify that newAuthz endpoint is optional

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,

Re: [Acme] Clarify that newAuthz endpoint is optional

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

Re: [Acme] Specify which JWS serialization is used

On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > What do you think of the following: > Content type application/jose+json: MUST be supported. If used, the JWS > will need to be in the Flattened or General serialization. Flattened MUST > be supported; General MAY be supported. >

Re: [Acme] Clarify that newAuthz endpoint is optional

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