Original text:
ACME messaging is based on HTTPS RFC2818 and JSON RFC7159. <del> Binary fields are encoded using Base64url encoding described in </del>  RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped. is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64url-encoded version of </del>  the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be <del> stripped before the values are Base64url-encoded. </del>  7.2. A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del>  A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "proof-of-possession-01" <del> An array of certificates, in Base64url-encoded DER format, that </del>  contain acceptable public keys. In response to this challenge, the client uses the private key A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del>  A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and

Reviewer comments:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)

Revised text:
ACME messaging is based on HTTPS RFC2818 and JSON RFC7159.  <ins> Binary fields are encoded using base64url encoding described in </ins> RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped. 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 </ins> the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be  <ins> stripped before the values are base64url-encoded. </ins> 7.2. A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters  <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "proof-of-possession-01"  <ins> An array of certificates, in base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters  <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and