Original text:
key, from which the server can look up related authorizations. A CSR encoding the parameters for the certificate being requested. <del> The CSR is sent in the Base64-encoded version of the DER format. (Note: This field uses the same modified Base64-encoding rules used elsewhere in this document, so it is different from PEM.) </del>  The CSR encodes the client's requests with regard to the content of the certificate to be issued.  The CSR MUST indicate the requested is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64-encoded version of the DER format.  (Note: This field uses the same modified Base64-encoding rules used elsewhere in this document, so it is different from PEM.) </del>  Revocation requests are different from other ACME request in that they can be signed either with an account key pair or the key pair in The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest.  As specified in the individual challenges below, the token for a challenge is a JSON string <del> comprised entirely of characters in the base64 alphabet.  The "||" operator indicates concatenation of strings. </del>  In computations involving key authorizations, such as the digest computations required for the DNS and TLS SNI challenges, the key authorization string MUST be represented in UTF-8 form (or, equivalently, ASCII).  7.2. With HTTP validation, the client in an ACME transaction proves its the client's account key.  The client then computes the SHA-256 digest of the key authorization. <del> The record provisioned to the DNS is the base64 encoding of this </del>  digest.  The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under

Reviewer comments:
All of the Base64 strings are actually Base64 URL encoded In the Java support for big ints the top byte is set to 0 to eliminate issues with signs. The thumbprint used here does not support that. It would be useful to mention that in the spec. I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above.
Right, point 3 is pretty unclear and requires searching with your favorite search engine.

Revised text:
key, from which the server can look up related authorizations. A CSR encoding the parameters for the certificate being requested.  <ins> The CSR is sent in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </ins> The CSR encodes the client's requests with regard to the content of the certificate to be issued.  The CSR MUST indicate the requested is a JWS object whose JSON payload contains the certificate to be revoked:  <ins> The certificate to be revoked, in the Base64url-encoded version of the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </ins> Revocation requests are different from other ACME request in that they can be signed either with an account key pair or the key pair in The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest.  As specified in the individual challenges below, the token for a challenge is a JSON string  <ins> comprised entirely of characters in the URL-safe Base64 alphabet. The "||" operator indicates concatenation of strings. </ins> In computations involving key authorizations, such as the digest computations required for the DNS and TLS SNI challenges, the key authorization string MUST be represented in UTF-8 form (or, equivalently, ASCII). <ins> An example of how to compute a JWK thumbprint can be found in Section 3.1 of RFC7638.  Note that some cryptographic libraries prepend a zero octet to the representation of the RSA public key parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be stripped before the values are Base64url-encoded. </ins> 7.2. With HTTP validation, the client in an ACME transaction proves its the client's account key.  The client then computes the SHA-256 digest of the key authorization.  <ins> The record provisioned to the DNS is the base64url encoding of this </ins> digest.  The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under