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

From: Rob Stradling <[email-masked]>
Date: Mon, 20 May 2019 15:56:21 +0000

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

---

From: Jörn Heissler <[email-masked]>
Date: Mon, 20 May 2019 21:29:18 +0200

>     the empty JSON object ({}).'

Hello,

I agree with your finding and your suggested erratum.

--
Jörn Heissler

---

From: Rob Stradling <[email-masked]>
Date: Wed, 22 May 2019 11:34:04 +0000

> 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

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 22 May 2019 11:58:37 -0400

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

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

---

From: Rob Stradling <[email-masked]>
Date: Thu, 23 May 2019 09:55:45 +0000

Thanks Daniel.

On 22/05/2019 16:58, Daniel McCarney wrote:
> On Wed, May 22, 2019 at 7:34 AM Rob Stradling <[email-masked] 
> <mailto:[email-masked]>> wrote:
>