jiebi/TextFlow huggingface dataset:
Original text:
7.3.5. The server MAY require a value to be present for the "external- <del> account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. </del>  To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST

Reviewer comments:
Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.

Revised text:
7.3.5. The server MAY require a value to be present for the "external-  <ins> account-binding" field.  This can be used to associate an ACME account with an existing account in a non-ACME system, such as a CA customer database. </ins> To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST
Original text:
In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an <del> identifier.  In these case, the CA should provision its ACME server </del>  with authorization objects corresponding to these authorizations and reflect them as already valid in any orders submitted by the client.

Reviewer comments:
Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.

Revised text:
In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an  <ins> identifier.  In these cases, the CA should provision its ACME server </ins> with authorization objects corresponding to these authorizations and reflect them as already valid in any orders submitted by the client.
Original text:
the "challenges" dictionary. The client sends these updates back to the server in the form of a <del> JSON object with the response fields required by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </del>  For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: The server updates the authorization document by updating its <del> representation of the challenge with the response fields provided by </del>  the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge

Reviewer comments:
Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.

Revised text:
the "challenges" dictionary. The client sends these updates back to the server in the form of a  <ins> JSON object with contents as specified by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </ins> For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: The server updates the authorization document by updating its  <ins> representation of the challenge with the response object provided by </ins> the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge
Original text:
Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation <del> query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </del>  The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After

Reviewer comments:
Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.

Revised text:
Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation  <ins> query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources.  The precise retry schedule is up to the server, but server operators should keep in mind the operational scenarios that the schedule is trying to accommodate.  Given that retries are intended to address things like propagation delays in HTTP or DNS provisioning, there should not usually be any reason to retry more often than every 5 or 10 seconds.  While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </ins> The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After
Original text:
for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple <del> acknowledgement response to the server. The string "oob-01" </del>  On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to

Reviewer comments:
Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.

Revised text:
for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple  <ins> acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). </ins> On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to
Original text:
according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 5.6. Certain elements of the protocol will require the establishment of a shared secret between the client and the server, in such a way that an entity observing the ACME protocol cannot derive the secret.  In these cases, we use a simple ECDH key exchange, based on the system used by CMS RFC5753: Inputs: Client-generated key pair Server-generated key pair Length of the shared secret to be derived Label Perform the ECDH primitive operation to obtain Z (Section 3.3.1 of SEC1) Select a hash algorithm according to the curve being used: For "P-256", use SHA-256 For "P-384", use SHA-384 For "P-521", use SHA-512 Derive the shared secret value using the KDF in Section 3.6.1 of SEC1 using Z and the selected hash algorithm, and with the UTF-8 encoding of the label as the SharedInfo value In cases where the length of the derived secret is shorter than the output length of the chosen hash algorithm, the KDF referenced above reduces to a single hash invocation.  The shared secret is equal to the leftmost octets of the following: </del> 6. In this section, we describe the certificate management functions

Reviewer comments:
As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.

Revised text:
according to this encoding, then the verifier MUST reject the JWS as malformed.  6. In this section, we describe the certificate management functions
Original text:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.3.1. If the client wishes to establish a secret key with the server that it can use to recover this account later (a "recovery key"), then it must perform a simple key agreement protocol as part of the new- registration transaction.  The client and server perform an ECDH exchange through the new-registration transaction (using the technique in key-agreement), and the result is the recovery key. To request a recovery key, the client includes a "recoveryKey" field in its new-registration request.  The value of this field is a JSON object. The client's ECDH public key The length of the derived secret, in octets. In the client's request, this object contains a JWK for a random ECDH public key generated by the client and the client-selected length value.  Clients need to choose length values that balance security and usability.  On the one hand, a longer secret makes it more difficult for an attacker to recover the secret when it is used for recovery (see mac-based-recovery).  On the other hand, clients may wish to make the recovery key short enough for a user to easily write it down. The server MUST validate that the elliptic curve ("crv") and length value chosen by the client are acceptable, and that it is otherwise willing to create a recovery key.  If not, then it MUST reject the new-registration request. If the server agrees to create a recovery key, then it generates its own random ECDH key pair and combines it with the client's public key as described in key-agreement above, using the label "recovery".  The derived secret value is the recovery key.  The server then returns to the client the ECDH key that it generated.  The server MUST generate a fresh key pair for every transaction. The server's ECDH public key On receiving the server's response, the client can compute the recovery key by combining the server's public key together with the private key corresponding to the public key that it sent to the server. Clients may refresh the recovery key associated with a registration by sending a POST request with a new recoveryKey object.  If the server agrees to refresh the recovery key, then it responds in the same way as to a new registration request that asks for a recovery key. </del> 6.4. Once a client has created an account with an ACME server, it is

Reviewer comments:
As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.

Revised text:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI  6.4. Once a client has created an account with an ACME server, it is
Original text:
is the only one that can choose the new account key that receives the capabilities held by the account being recovered. <del> MAC-based recovery can be performed if the attacker knows the account key and registration URI for the account being recovered.  Both of these are difficult to obtain for a network attacker, because ACME uses HTTPS, though if the recovery key and registration URI are sufficiently predictable, the attacker might be able to guess them. An ACME MitM can see the registration URI, but still has to guess the recovery key, since neither the ECDH in the provisioning phase nor HMAC in the recovery phase will reveal it to him. ACME clients can thus mitigate problems with MAC-based recovery by using long recovery keys.  ACME servers should enforce a minimum recovery key length, and impose rate limits on recovery to limit an attacker's ability to test different guesses about the recovery key. Contact-based recovery uses both the ACME channel and the contact channel.  The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the contact-based recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </del>  If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure

Reviewer comments:
As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.

Revised text:
is the only one that can choose the new account key that receives the capabilities held by the account being recovered.  <ins> Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </ins> If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure
Original text:
In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. <del> In designing and deploying contact-based recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact- based recovery schemes that achieve an appropriate level of risk using those contact channels. </del>  9.4.

Reviewer comments:
As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.

Revised text:
In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above.  <ins> In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. </ins> 9.4.
Original text:
certificate. If the revocation succeeds, the server responds with status code 200 <del> (OK).  If the revocation fails, the server returns an error. </del>  8.

Reviewer comments:
NAME This definitely needs to be reviewed.
This looks good to me.
I like the idea of a special compound error type to indicate that the subproblems field is used.
In s7.6, it seems like we should indicate what error is returned: If the revocation fails, the server returns an error. The draft this nicely in many others places in the draft.
I mentioned this earlier on the mailing list, but it did not receive any feedback: as a ACME client developer, I would like to be able to distinguish between errors which do not require user interaction (that would be "certificate is already revoked, so can't revoke it again"), and ones where the user must be warned that the operation did not succeed ("certificate could not be revoked", "bad credentials", etc.). This is currently only possible with server-specific ugly hacks (for example, returns this information, but other servers might return it differently or this might change in later versions of Boulder as it is not specified).
This is a good idea, sorry for missing it earlier. NAME - Do you have any thoughts on other cases besides "already revoked" that would (a) not require user interaction and (b) not be covered by other current error codes? NAME - Would you mind making a PR to add an error code (and anything else that NAME comes up with), and note it in the revocation section?
I thought of one to consider in :
It looks like Boulder uses 404 and a generic malformed problem type for this case: URL URL
NAME So far I couldn't think of anything else. I'm totally happy with :-)
Fixed by
:+1: Thanks!

Revised text:
certificate. If the revocation succeeds, the server responds with status code 200  <ins> (OK).  If the revocation fails, the server returns an error.  For example, if the certificate has already been revoked the server returns an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:alreadyRevoked". </ins> 8.
Original text:
9.1. A file of this type contains one or more certificates encoded with <del> the PEM textual encoding, according to RFC 7468 RFC7468.  In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del>  The "Media Types" registry should be updated with the following additional value:

Reviewer comments:
In addition to forbidding explanatory text, this PR restricts the PEM-certificate-chain structure to the "strict" production defined in RFC 7468, Figure 3.
s/Figure 3 of RFC 7468/Section 3 of RFC 7468/

Revised text:
9.1. A file of this type contains one or more certificates encoded with  <ins> the PEM textual encoding, according to RFC 7468 RFC7468.  The textual encoding of certificates in this file MUST use the strict encoding and MUST NOT include explanatory text.  The ABNF for this format is as follows, where "stricttextualmsg" and "eol" are as defined in Section 3 of RFC 7468: In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that represents a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> The "Media Types" registry should be updated with the following additional value: