Original text:
If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type <del> "urn:ietf:params:acme:error:badSignatureAlgorithm" (see errors).  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. </del>  Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field The server granted the client authorization based on an external account <del> Clients should check the "status" field of an order to determine </del>  whether they need to take any action. 7.1.4. Validation responses need to be bound to an account key pair in order to avoid situations where a MitM on ACME HTTPS requests can switch <del> out a legitimate domain holder's account key for one of his choosing, e.g.: </del>  Legitimate domain holder registers account key pair A B (the MitM) instead of account key A (the legitimate domain holder) <del> All of the challenges above have a binding between the account private key and the validation query made by the server, via the key authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </del>  The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who

Reviewer comments:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME

Revised text:
If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type  <ins> "urn:ietf:params:acme:error:badSignatureAlgorithm".  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values.  See errors for more details on the structure of error responses. </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field The server granted the client authorization based on an external account  <ins> Clients SHOULD check the "status" field of an order to determine </ins> whether they need to take any action. 7.1.4. Validation responses need to be bound to an account key pair in order to avoid situations where a MitM on ACME HTTPS requests can switch  <ins> out a legitimate domain holder's account key for one of his choosing. Such MitMs can arise, for example, if a CA uses a CDN or third-party reverse proxy in front of its ACME interface.  An attack by such an MitM could have the following form: </ins> Legitimate domain holder registers account key pair A B (the MitM) instead of account key A (the legitimate domain holder)  <ins> All of the challenges defined in this document have a binding between the account private key and the validation query made by the server, via the key authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </ins> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who