x/crypto/acme: Client.AcceptWithPayload to support device attestation extension

[zhsh]

Proposal Details

The current RFC 8555, section 7.5.1 "Responding to Challenges" (https://datatracker.ietf.org/doc/html/rfc8555#section-7.5.1) states that the client should send an empty JSON body ("{}") to the challenge URL. That is what Client.Accept() method does: https://github.com/golang/crypto/blob/3375612bf41a8cdb0cdfdc21e6ca2c7ae0f764b5/acme/acme.go#L517

A new extension to the ACME protocol is proposed: https://datatracker.ietf.org/doc/draft-acme-device-attest/
Based on the recent IETF meetings, the proposal is likely to be accepted.

To support the new extension, the ACME client should be able to send a non-empty JSON body:

A client responds with the response object containing the WebAuthn attestation object in the "attObj" field to acknowledge that the challenge can be validated by the server.

This proposal is for adding a new method to acme.Client (perhaps client.AcceptWithPayload) that is similar to client.Accept but allows to pass a non-default payload.

[zhsh]

A quick note: Smallstep's implementation of ACME client and server already supports the new extension.

Smallstep client code that supports both the default and non-default payloads: https://github.com/smallstep/certificates/blob/1b2d999e4607bbe4796dce2a0f0f3c7a29cec463/ca/acmeClient.go#L243-L267

[ianlancetaylor]

CC @golang/security

[gopherbot]

Change https://go.dev/cl/608975 mentions this issue: acme: support challenges that require the ACME client to send a non-empty JSON body in a response to the challenge.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Would it make sense to add a field to the Challenge type instead of having a whole new method?

[rolandshoemaker]

We could also avoid adding a field entirely, and add an internal check for Challenge.Type == "hardware-module". This would be somewhat opaque, but doesn't require an API change.

[zhsh]

Would it make sense to add a field to the Challenge type instead of having a whole new method?

This works too.

If I understand correctly, the change will look like the below. Does it make sense?

1. Add a field to Challenge.

type Challenge struct {
  ...
  // If a challenge requires a non-empty response (e.g. "device-attest-01"),
  // the client must populate Response
  Response sometype
}

2. Code that uses the new challenge type will look like this:

  // retrieve a challenge from the server
  var challenge acme.Challenge
  challenge = ...

  // construct the response from challenge.Token
  challenge.Response = ...

  // inform the server that the challenge is ready
  acmeClient.Accept(ctx, challenge)

3. Client.Accept() is modified to handle non-empty response:

  if chal.Response is not initialized {
    res, err := c.post(ctx, nil, chal.URI, json.RawMessage("{}"), ...)
  } else {
    res, err := c.post(ctx, nil, chal.URI, chal.Response, ...)
  }

[zhsh]

We could also avoid adding a field entirely, and add an internal check for Challenge.Type == "hardware-module". This would be somewhat opaque, but doesn't require an API change.

I may be missing something here... How does the client pass the response to the server in this case?