On 06/26/2017 07:15 AM, Ilari Liusvaara wrote:
> I was trying to write some code, and noticed a potential inconsistency:
>
> Section 7.5.1 has in example (responding to HTTP-01 challenge):
>
> "payload": base64url({
> "type": "http-01",
> "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
> }),
>
> ... Type field is present.
>
>
> But section 8.3 has:
>
> "payload": base64url({
> "keyAuthorization": "evaGxfADs...62jcerQ"
> }),
>
> ... No type field.
In general, ACME has "partial update" semantics on POSTs. So fields that
aren't changing, or aren't permitted to be changed by the client, like
"type", "status", "url" and "token", can be omitted. The spec says:
> The server updates the authorization document by updating its
representation of the challenge with the response fields 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. The server
provides a 200 (OK) response with the updated challenge object as its body.
This is actually a bit confusing because we don't ever define "response
fields", but they are defined by the individual challenge types. We
should probably update the parts of those challenge definitions that
define response fields to describe them that way.
https://github.com/ietf-wg-acme/acme/issues/329
For DNS-01, HTTP-01, and TLS-SNI-02, the only response field is
"keyAuthorization". For OOB-01, the only response field is "type". I
suspect this was just to avoid having an empty payload, but I think an
empty payload is fine, and this is confusingly different from the
others, so we should change OOB-01 to just take an empty payload.
https://github.com/ietf-wg-acme/acme/issues/328
So, of the examples you point out, the one in 7.5.1 should be updated to
remove the "type" field: https://github.com/ietf-wg-acme/acme/pull/327.
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
