jiebi/TextFlow huggingface dataset:
Original text:
taken to fulfill the challenge, e.g., removing files that have been provisioned to a web server. <del> Presumably, the client's responses provide the server with enough information to validate one or more challenges.  The server is said to "finalize" the authorization when it has completed all the validations it is going to complete, and assigns the authorization a </del>  status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier.  If the final state is "valid", the server MUST add an "expires" field to the authorization.

Reviewer comments:
With the combinations array now removed, this is no longer accurate.
If you could re-wrap that paragraph to get rid of the short line, LGTM.
I tend not to re-wrap Markdown on edits because it makes diffs & blames more meaningful. Do you feel strongly about the wrapping?

Revised text:
taken to fulfill the challenge, e.g., removing files that have been provisioned to a web server.  <ins> The server is said to "finalize" the authorization when it has completed one of the validations, by assigning the authorization a </ins> status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier.  If the final state is "valid", the server MUST add an "expires" field to the authorization.
Original text:
"alg" <del> "jwk" </del>  "nonce" (defined below) "url" (defined below) <del> Note that this implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </del>  In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed 5.3. <del> At several points in the protocol, it is necessary for the server to </del>  determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in

Reviewer comments:
Previously, each authenticated POST included a copy of its public key in the JWS protected header. Servers were required to canonicalize this key in some way and look it up in a database, then verify the payload. However, servers also had the option of verifying the payload, and then looking up the key in the database. This opened up a category of potential bugs based on truncated database fields or hash collisions, where an attacker could craft a key pair the would potentially be matched to someone else's account. Incidental benefits: Switching to kid makes payloads somewhat smaller, and removes the need to define key equality in the ACME spec.
Updated based on feedback.
Updated. Rather than have a switch/case about how to authenticate revoke-cert, I split it into two resources, authenticated different ways: one by account, one by cert key.

Revised text:
"alg"  <ins> "jwk" (only for requests to new-reg and revoke-cert resources) "kid" (for all other requests). </ins> "nonce" (defined below) "url" (defined below)  <ins> The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. For new-reg requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. For all other requests, there MUST be a "kid" field.  This field must contain the account URI received by POSTing to the new-reg resource. Note that authentication via signed POST implies that GET requests are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed 5.3.  <ins> At some points in the protocol, it is necessary for the server to </ins> determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in
Original text:
To download the issued certificate, the client simply sends a GET request to the certificate URL. <del> The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/x-pem-file to request the certificate in PEM format. The server provides metadata about the certificate in HTTP headers. In particular, the server MUST send one or more link relation header fields RFC5988 with relation "up", each indicating a single certificate resource for the issuer of this certificate.  The server MAY also include the "up" links from these resources to enable the client to build a full certificate chain. </del>  The server MUST also provide a link relation header field with relation "author" to indicate the application under which this

Reviewer comments:
One of the most common ACME deployment failures observed in practice is for servers to be configured to serve only the end-entity certificate, without the intermediate certificates. This is a particularly pernicious problem because some browsers will still trust the resulting one-certificate chain, due to caching or fetching of URLs from Authority Information Access. But other browsers will not, resulting in a "works on my computer" problem. Arguably this configuration is the result of incorrect clients, but we should expect that most clients will do the easiest thing. This change aligns the easiest thing with the most correct thing.
You should include advice here on omitting trust anchors. TLS 1.3 has you could crib from (see the definition of ).
Hi, the PEM text is not correct: application/x-pem-file is not a registered media type, among other things. Will post to mailing list with details.

Revised text:
To download the issued certificate, the client simply sends a GET request to the certificate URL.  <ins> The default format of the certificate is PEM (application/x-pem-file) as specified by RFC7468.  This format should contain the end-entity certificate first, followed by any intermediate certificates that are needed to build a path to a trusted root.  Servers SHOULD NOT include self-signed trust anchors.  The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/pkix-cert to request the end- entity certificate in DER format. The server MAY provide one or more link relation header fields RFC5988 with relation "alternate".  Each such field should express an alternative certificate chain starting with the same end-entity certificate.  This can be used to express paths to various trust anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. </ins> The server MUST also provide a link relation header field with relation "author" to indicate the application under which this
Original text:
Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del>  Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del>  Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

Reviewer comments:
I spotted a typo/error introduced by this PR and submitted a follow-up: URL
Since we did not get consensus around , we should be explicit that HTTP is TCP port 80, and HTTPS is TCP port 443, and that holds for redirects as well. The is pretty much a minor wording change only.

Revised text:
Verify that the resulting URI is well-formed.  <ins> Dereference the URI using an HTTP GET request.  This request MUST be sent to TCP port 80 on the server. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at Compute SAN A and SAN B in the same way as the client.  <ins> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other
Original text:
Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del>  Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other

Reviewer comments:
Pull request was recently merged to clarify that HTTP and TLS challenge requests must use port 80 and 443 respectively. The "TLS with Server Name Indication (TLS SNI)" section was updated to read: This is a typo ("port 443 the domain name") and also still includes the phrase "on the requested port", which is no longer true. This PR updates the SNI challenge description to fix the typo and to explicitly say that the server MUST use port 443 in the same style/manner as the HTTP edit from .
Thanks for fixing my lame typos

Revised text:
Compute SAN A and SAN B in the same way as the client.  <ins> Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent to TCP port 443 on the server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other
Original text:
are specified in the future, the specification of those fields MUST describe whether they may be provided by the client.  The server creates a registration object with the included contact information.  The "key" element of the registration is set to the public key used to verify the JWS (i.e., the "jwk" element of the JWS

Reviewer comments:
As far as I am aware there has been no explicit use case for this and Boulder explicitly disallows URIs to be used. should be the only explicitly supported URI type in the spec and others should be left up to implementing CAs to document.
Conversation on-list went more in the direction of specifying that providing any contact with an unrecognized URI scheme should result in a hard error of . Renaming appropriately.

Revised text:
are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the server MUST return an error of type "invalidContact", with a description describing the error and what types of contact URL the server considers acceptable. </ins> The server creates a registration object with the included contact information.  The "key" element of the registration is set to the public key used to verify the JWS (i.e., the "jwk" element of the JWS
Original text:
The JWS MUST NOT have the value "none" in its "alg" field  The JWS Protected Header MUST include the following fields: "alg" are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive.  In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so

Reviewer comments:
Also: Forbid the use of MAC-based JWS algorithms (in case this wasn't obvious) Sort error codes alphabetically
The server needs to support whatever the client sends. We should have an error code for this, and a way for the server to specify what algorithms it does support in the error message.

Revised text:
The JWS MUST NOT have the value "none" in its "alg" field <ins> The JWS MUST NOT have a MAC-based algorithm in its "alg" field </ins> The JWS Protected Header MUST include the following fields: "alg" are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. <ins> 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 "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. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so
Original text:
the future, the specification of those fields MUST describe whether they may be provided by the client.  The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the

Reviewer comments:
In some cases, it might be important for a client to know that a server has or has not processed an extension field. For example, if we had an extension that requested some higher level of assurance, then a client would want to know that the CA was going to provide that level of assurance. This PR specifies some rudimentary feature detection to support this objective.

Revised text:
the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the client provides the server with an invalid or unsupported contact URL, then the
Original text:
order. The elements of the "authorizations" array are immutable once set. <del> If any change is made to the array after the object is created, the client MUST consider the order invalid. </del>  The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue,

Reviewer comments:
Implements from the mailing list. On Tue, Nov 29, 2016 at 04:32:33PM -0500, Richard Barnes wrote: than server implementations. With the current language, the client must check that authorizations have not changed. The language for the server should be MUST NOT change the elements of the "authorizations" array once set.'', unambiguously putting the responsibility where it squarely belongs - with the server. The spec could further elaborate that clientsSHOULD consider the application invalid'' if a change is detected. I see no reason why clients should be burdened (by way of ``MUST'') with detecting a condition that will not arise with compliant servers, and is unlikely to cause practical issues if it does occur after a certificate has been issued. Thanks, Fraser

Revised text:
order. The elements of the "authorizations" array are immutable once set.  <ins> The server MUST NOT change the contents of the "authorizations" array after it is created.  If a client observes a change in the contents of the "authorizations" array, then it SHOULD consider the order invalid. </ins> The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue,
Original text:
URL-TBD <del> No transformation needed.  The </del>  [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document, and replace URL-TBD with the URL assigned by IANA

Reviewer comments:
Failure to synchronize between and . Also removes a stray word and some whitespace in the vicinity.
Also in the registries (and in the "Order Objects" section), is the authorizations property of an order object an array of strings (URLs) or an array of dictionaries (each of which contains status and URL parameters)?
NAME array of strings, since

Revised text:
URL-TBD  <ins> No transformation needed. </ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document, and replace URL-TBD with the URL assigned by IANA
Original text:
To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce, and SHOULD have <del> status code 200 (OK).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </del>  Caching of responses from the new-nonce resource can cause clients to be unable to communicate with the ACME server.  The server MUST

Reviewer comments:
The new-nonce endpoint added in defines a new endpoint which returns information just in headers, but with a 200 response code. I feel this would be more appropriate as a 204 No Content response code. I'm not sure what the approach to making this sort of change is. Should I create this change as a PR?
NAME A PR and a small note to the mailing list is probably the best approach. I'm not an HTTP status lawyer but it seems like 204 is the more-appropriate choice in this context and seems to agree with you: I would :+1: the PR to change to 204 for :-)

Revised text:
To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce, and SHOULD have  <ins> status code 204 (No Content).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </ins> Caching of responses from the new-nonce resource can cause clients to be unable to communicate with the ACME server.  The server MUST
Original text:
that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. <del> The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object. A URL from which the authorization can be fetched with a GET request. </del> A URL for the certificate that has been issued in response to this order.

Reviewer comments:
Removed unnecessary paragraphs from authorizations field description in order object.
Thanks NAME not sure how I missed that in :)

Revised text:
that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request.  A URL for the certificate that has been issued in response to this order.
Original text:
5.7. <del> Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </del>  When the server responds with an error status, it SHOULD provide additional information using problem document RFC7807.  To facilitate standard types.  Clients SHOULD display the "detail" field of all errors. <del> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. </del> 6. In this section, we describe the certificate management functions

Reviewer comments:
Also switches the type of the challenge type to be instead of as JSON doesn't have dictionaries. I'll push a follow-up PR that will switch the rest of the -> .

Revised text:
5.7.  <ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </ins> When the server responds with an error status, it SHOULD provide additional information using problem document RFC7807.  To facilitate standard types.  Clients SHOULD display the "detail" field of all errors.  6. In this section, we describe the certificate management functions
Original text:
introduced in version -03 and a breaking change made in version -05, then there would be a challenge labeled "http-03" and one labeled "http-05" - but not one labeled "http-04", since challenge in version <del> -04 was compatible with one in version -04. ]] </del>  7.1.

Reviewer comments:
Note is still required.
In this case it seems better to address the removal of the editor's note than to optimize its contents - do we know if this note is still required?

Revised text:
introduced in version -03 and a breaking change made in version -05, then there would be a challenge labeled "http-03" and one labeled "http-05" - but not one labeled "http-04", since challenge in version  <ins> -04 was compatible with one in version -03. ]] </ins> 7.1.
Original text:
Verify that the contents of one of the TXT records matches the digest value <del> It is RECOMMENDED that the server perform multiple DNS queries from various network perspectives, in order to make MitM attacks harder. </del> If all of the above verifications succeed, then the validation is successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. validation response for his own account key.  The risks due to hosting providers noted above are a particular case.  10.3. As a protocol run over HTTPS, standard considerations for TCP-based

Reviewer comments:
Previously these were spread among the various challenges. We can simplify by putting them in one place. Replaces .

Revised text:
Verify that the contents of one of the TXT records matches the digest value  If all of the above verifications succeed, then the validation is successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. validation response for his own account key.  The risks due to hosting providers noted above are a particular case. <ins> It is RECOMMENDED that the server perform DNS queries and make HTTP and TLS connections from various network perspectives, in order to make MitM attacks harder. </ins> 10.3. As a protocol run over HTTPS, standard considerations for TCP-based