Change:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.

Discussion:
the status field. A CSR encoding the parameters for the certificate being requested <del> RFC2986.  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.) </del> <ins> RFC2986.  The CSR is sent in the base64url-encoded version of the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> The requested value of the notBefore field in the certificate, in the date format defined in

the certificate to be issued: A CSR encoding the parameters for the certificate being requested <del> RFC2986.  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.) </del> <ins> RFC2986.  The CSR is sent in the base64url-encoded version of the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> The requested value of the notBefore field in the certificate, in the date format defined in

issue the certificate (see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" <del> and MAY delete the application resource. </del> <ins> and MAY delete the order resource. </ins> The server MUST issue the requested certificate and update the order <del> resource with a URL for the certificate as soon as the client has </del> <ins> resource with a URL for the certificate shortly after the client has </ins> fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the

6.4.1. The order process described above presumes that authorization objects <del> are created reactively, in response to an application for issuance. Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific </del> <ins> are created reactively, in response to a certificate order.  Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific </ins> issuance.  For example, a client hosting virtual servers for a collection of names might wish to obtain authorization before any servers are created, and only create a certificate when a server

revoked: 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.) </del> <ins> the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> <del> One of the revocation reasonCodes defined in RFC 5280 RFC5280 Section 5.3.1 to be used when generating OCSP responses and CRLs. If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The server MAY disallow a subset of reasonCodes from being used by the user. </del> <ins> One of the revocation reasonCodes defined in RFC5280 Section 5.3.1 to be used when generating OCSP responses and CRLs.  If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The server MAY disallow a subset of reasonCodes from being used by the user. </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 <del> comprised entirely of characters in the URL-safe Base64 alphabet. </del> <ins> comprised entirely of characters in the URL-safe base64 alphabet. </ins> The "||" operator indicates concatenation of strings. In computations involving key authorizations, such as the digest

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 and MUST NOT contain any padding characters ("="). </del> <ins> outside the base64url 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

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 and MUST NOT contain any padding characters ("="). </del> <ins> outside the base64url 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