Re: [Acme] Responding to challenges - spec bug?

[Rob Stradling]

Thanks Daniel.

On 22/05/2019 16:58, Daniel McCarney wrote:
> Thanks Rob, I also agree this is a valid erratum finding with the spec.
> 
> On Wed, May 22, 2019 at 7:34 AM Rob Stradling  > wrote:
> 
> On 20/05/2019 20:29, Jörn Heissler wrote:
>  > On Mon, May 20, 2019 at 15:56:21 +, Rob Stradling wrote:
>  >> How would folks feel about an erratum to change that sentence in
> section
>  >> 7.5.1 to the following:
>  >>     'The client indicates to the server that it is ready for the
> challenge
>  >>      validation by sending a POST request to the challenge URL
> (not the
>  >>      authorization URL), where the body of the POST request is a JWS
>  >>      object whose JSON payload is a response object (see Section
> 8).  For
>  >>      all challenge types defined in this document, the response
> object is
>  >>      the empty JSON object ({}).'
>  >> ?
>  >
>  > Hello,
>  >
>  > I agree with your finding and your suggested erratum.
> 
> Thanks Jörn.
> 
> I've filed an erratum for this:
> https://www.rfc-editor.org/errata/eid5729

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: [Acme] Responding to challenges - spec bug?

[Daniel McCarney]

Thanks Rob, I also agree this is a valid erratum finding with the spec.

On Wed, May 22, 2019 at 7:34 AM Rob Stradling  wrote:

> On 20/05/2019 20:29, Jörn Heissler wrote:
> > On Mon, May 20, 2019 at 15:56:21 +, Rob Stradling wrote:
> >> How would folks feel about an erratum to change that sentence in section
> >> 7.5.1 to the following:
> >> 'The client indicates to the server that it is ready for the
> challenge
> >>  validation by sending a POST request to the challenge URL (not the
> >>  authorization URL), where the body of the POST request is a JWS
> >>  object whose JSON payload is a response object (see Section 8).
> For
> >>  all challenge types defined in this document, the response object
> is
> >>  the empty JSON object ({}).'
> >> ?
> >
> > Hello,
> >
> > I agree with your finding and your suggested erratum.
>
> Thanks Jörn.
>
> I've filed an erratum for this:
> https://www.rfc-editor.org/errata/eid5729
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
>
> ___
> 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] Responding to challenges - spec bug?

[Rob Stradling]

On 20/05/2019 20:29, Jörn Heissler wrote:
> On Mon, May 20, 2019 at 15:56:21 +, Rob Stradling wrote:
>> How would folks feel about an erratum to change that sentence in section
>> 7.5.1 to the following:
>> 'The client indicates to the server that it is ready for the challenge
>>  validation by sending a POST request to the challenge URL (not the
>>  authorization URL), where the body of the POST request is a JWS
>>  object whose JSON payload is a response object (see Section 8).  For
>>  all challenge types defined in this document, the response object is
>>  the empty JSON object ({}).'
>> ?
> 
> Hello,
> 
> I agree with your finding and your suggested erratum.

Thanks Jörn.

I've filed an erratum for this:
https://www.rfc-editor.org/errata/eid5729

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

Re: [Acme] Responding to challenges - spec bug?

[Jörn Heissler]

On Mon, May 20, 2019 at 15:56:21 +, Rob Stradling wrote:
> How would folks feel about an erratum to change that sentence in section 
> 7.5.1 to the following:
>'The client indicates to the server that it is ready for the challenge
> validation by sending a POST request to the challenge URL (not the
> authorization URL), where the body of the POST request is a JWS
> object whose JSON payload is a response object (see Section 8).  For
> all challenge types defined in this document, the response object is
> the empty JSON object ({}).'
> ?

Hello,

I agree with your finding and your suggested erratum.

--
Jörn Heissler


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Responding to challenges - spec bug?

[Rob Stradling]

RFC8555 sections 8.3 (http-01) and 8.4 (dns-01) both say:
   'A client responds with an empty object ({}) to acknowledge that the
challenge can be validated by the server.'

Section 7.5.1, which is apparently intended to apply to all challenge 
types (including challenge types defined in other documents), says the 
same thing...
   'The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).'
but then, after showing an example HTTP request, it goes on to say...
   'The server updates the authorization document by updating its
representation of the challenge with the response object provided by
the client.  The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge.
Note that the challenges in this document do not define any response
fields, but future specifications might define them.'

So it seems that the 'empty JSON body "({})"' is intended to be 
interpreted by the ACME server as a "response object" that (depending on 
the challenge type) "might define" some "response fields".  However, if 
any response fields are defined and included in the JSON body then the 
client will no longer be sending the 'empty JSON body ("{}")' that 
section 7.5.1 says it's supposed to send...
   'The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).'

How would folks feel about an erratum to change that sentence in section 
7.5.1 to the following:
   'The client indicates to the server that it is ready for the challenge
validation by sending a POST request to the challenge URL (not the
authorization URL), where the body of the POST request is a JWS
object whose JSON payload is a response object (see Section 8).  For
all challenge types defined in this document, the response object is
the empty JSON object ({}).'
?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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