jiebi/TextFlow huggingface dataset:
Original text:
When a server rejects a request because its nonce value was unacceptable (or not present), it MUST provide HTTP status code 400 <del> (Bad Request), and indicate the ACME error code </del>  "urn:ietf:params:acme:error:badNonce".  An error response with the <del> "badNonce" error code MUST include a Replay-Nonce header with a fresh </del>  nonce.  On receiving such a response, a client SHOULD retry the request using the new nonce. specified, and MUST NOT issue a certificate with contents other than those requested.  If the server requires the request to be modified in a certain way, it should indicate the required changes using an <del> appropriate error code and description. </del>  If the server is willing to issue the requested certificate, it responds with a 201 (Created) response.  The body of this response is ACME Order Object Fields (iana-order) <del> ACME Error Codes (iana-error) </del>  ACME Resource Types (iana-resource) Template: <del> Code: The label to be included in the URN for this error, </del>  following "urn:ietf:params:acme:" Description: A human-readable description of the error Reference: Where the error is defined <del> Initial contents: The codes and descriptions in the table in errors </del>  above, with the Reference field set to point to this specification. 8.6.4.

Reviewer comments:
Usage of is slightly confusing when we are not using int-enumerated error codes. RFC 7807 also refers to the problem document error types as and the field is called so this seems to make the most sense.

Revised text:
When a server rejects a request because its nonce value was unacceptable (or not present), it MUST provide HTTP status code 400  <ins> (Bad Request), and indicate the ACME error type </ins> "urn:ietf:params:acme:error:badNonce".  An error response with the  <ins> "badNonce" error type MUST include a Replay-Nonce header with a fresh </ins> nonce.  On receiving such a response, a client SHOULD retry the request using the new nonce. specified, and MUST NOT issue a certificate with contents other than those requested.  If the server requires the request to be modified in a certain way, it should indicate the required changes using an  <ins> appropriate error type and description. </ins> If the server is willing to issue the requested certificate, it responds with a 201 (Created) response.  The body of this response is ACME Order Object Fields (iana-order)  <ins> ACME Error Types (iana-error) </ins> ACME Resource Types (iana-resource) Template:  <ins> Type: The label to be included in the URN for this error, </ins> following "urn:ietf:params:acme:" Description: A human-readable description of the error Reference: Where the error is defined  <ins> Initial contents: The types and descriptions in the table in errors </ins> above, with the Reference field set to point to this specification. 8.6.4.
Original text:
The requested value of the notAfter field in the certificate, in the date format defined in RFC3339.  For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see identifier-authorization).  For final orders, the authorizations

Reviewer comments:
Removes dnssec error type for a broader "dns" error type. It's very hard to split out dnssec errors from regular dns problems, because recursive resolvers can only return SERVFAIL. The new dns error type also subsumes "unknownHost." Introduces a new "incorrectResponse" error type for cases where connection and request were both successful, but the content didn't match. This also puts the validation-related errors at the bottom of the table so they can be viewed in context with each other. Introduces an error field for orders. Orders can fail independent of authorizations because of last-minute CAA checking, failure to submit to CT logs, timeouts, etc.

Revised text:
The requested value of the notAfter field in the certificate, in the date format defined in RFC3339. <ins> The error that occurred while processing the order, if any.  This field is structured as a problem document RFC7807. </ins> For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see identifier-authorization).  For final orders, the authorizations
Original text:
new challenge types, and they will need to specify which types of identifier they apply to. <del> [[ Editor's Note: In pre-RFC versions of this specification, challenges are labeled by type, and with the version of the draft in which they were introduced.  For example, if an HTTP challenge were 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 -04 was compatible with one in version -03. ]] </del> 8.1. Several of the challenges in this document make use of a key

Reviewer comments:
This is worth discussion on the list. Do we consider the current, numbered, names a draft-only thing? Do we want the final RFC to use non-numbered challenge names?
If we are going to do this, we need to update the following paragraph: Personally, I would prefer dropping the version number (i.e., not merging this PR), since if all goes well, future client development can be based on the RFC vs. the drafts. Clients will need to change which token they use, but that's hardly the biggest change between what's deployed today and what's in this spec.
Will update to remove the editor's note.
Could possibly use some additional language about the name + version scheme we are using but I couldn't come up with anything that really worked.

Revised text:
new challenge types, and they will need to specify which types of identifier they apply to.  8.1. Several of the challenges in this document make use of a key
Original text:
other certificate management functions, such as certificate revocation. <del> DANGER: Do not implement this specification.  It has a known signature reuse vulnerability.  For details, see the following discussion: </del>  <del> https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf- 4Yc </del>  1. CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. 

Reviewer comments:
It's no longer at a "do not implement" stage, but some caution is still merited. Also, it's good to have a pointer in the draft to this repo. (Cribbed from the TLS 1.3 spec.)

Revised text:
other certificate management functions, such as certificate revocation.  <ins> DISCLAIMER: This is a WIP draft of ACME and has not yet had a thorough security analysis. </ins>  <ins> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1].  Instructions are on that page as well.  Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). </ins> 1. CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <ins> 10.  References 10.1.  URIs [1] https://github.com/ietf-wg-acme/acme </ins>
Original text:
A "new-order" resource (applying-for-certificate-issuance) <del> A "revoke-certificate" resource (certificate-revocation) </del>  A "key-change" resource (account-key-roll-over)

Reviewer comments:
Fixes per feedback . Section 6.1 referenced "revoke-certificate" where elsewhere using "revoke-cert", this commit replaces it with "revoke-cert". Section 7.1 has a resource diagram that previously labelled the termination of the "new-account" flow as "acct", this commit replaces that label with "account". Elsewhere the use of "acct" is limited to URLs and not referencing specific resources/spec content. I'm resending this message as there were no responses and nothing changed. ---------- Forwarded message ---------- Morning, the current draft contains a few inconsistencies in the resource naming. 1) https://ietf-wg-URL mentions "revoke-certificate", while it's called "revoke-cert" in the rest of the document. 2) There's "new-account", but the account resource is called "acct", I think it should be "account" everywhere. We don't gain anything by saving a few keystrokes / bytes there. Maybe we should then also rename "authz" to "authorization" and "cert" to "certificate" everywhere. Regards, Niklas

Revised text:
A "new-order" resource (applying-for-certificate-issuance)  <ins> A "revoke-cert" resource (certificate-revocation) </ins> A "key-change" resource (account-key-roll-over)
Original text:
The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future <del> client requests.  The server should generate the value provided in </del>  Replay-Nonce in such a way that they are unique to each message, with <del> high probability. </del>  The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of

Reviewer comments:
And clarify "high probability."
While we're clarifying, I might add an encrypted counter another option that is guaranteed unique.
I don't think we need to get into that level of prescribing implementation detail; once you mention it at all it immediately sounds half-specified. As a reader, I would want to know "what algorithm? shared across how many frontends? how does key management and rotation work?" Better to just say it should be unique (with high probability) and leave it to the implementer.

Revised text:
The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future  <ins> client requests.  The server MUST generate the value provided in </ins> Replay-Nonce in such a way that they are unique to each message, with  <ins> high probability.  For instance, it is acceptable to generate Replay- Nonces randomly. </ins> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of
Original text:
unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. <del> 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. </del>  The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to

Reviewer comments:
Firstly, this PR updates the table of errors in Section 6.6 "Errors" to add an "unsupportedContact" error type in addition to "invalidContact". The former is returned when the contact URI protocol is unsupported and the latter when the protocol is supported but the provided contact is invalid. Secondly, this PR updates Section 7.3 "Account Creation" to both mention the new "unsupportedContact" error type and to make support of the "mailto:" protocol a MUST.
Thanks for the feedback NAME - updated.
Should the "unsupportedContact" error include a separate machine-readable field with the types of contacts acceptable?
NAME Let's discuss that in a follow-on issue / PR.

Revised text:
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 URIs in the "contact" field are valid and supported by the server.  If the server validates contact URIs it MUST support the "mailto" scheme.  If the server rejects a contact URI for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URIs the server considers acceptable.  If the server rejects a contact URI for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </ins> The server creates an account and stores the public key used to verify the JWS (i.e., the "jwk" element of the JWS header) to
Original text:
Same meaning as the corresponding server field defined in  The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, field.  This allows a client that has an account key but not the corresponding account URL to recover the account URL. <del> If a client wishes to recover an existing account and does not want a non existing account to be created, then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). </del>  7.3.2.

Reviewer comments:
Depends on
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Revised text:
Same meaning as the corresponding server field defined in <ins> If this field is present with the value "true", then the server MUST NOT create a new account if one does not already exist.  This allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). </ins> The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future, field.  This allows a client that has an account key but not the corresponding account URL to recover the account URL.  <ins> If a client wishes to find the URL for an existing account and does not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true" ({"only-return-existing": true}). </ins> 7.3.2.
Original text:
9.7.5. <del> This registry lists the types of identifiers in certificates that ACME clients may request authorization to issue. </del>  Template:

Reviewer comments:
Currently says This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates. But ACME clients no longer directly request authorization; instead this section lists identifiers that the servers may create authorizations for based on new-order.

Revised text:
9.7.5.  <ins> This registry lists the types of identifiers that can be present in ACME authorization objects. </ins> Template:
Original text:
All of the challenges above have a binding between the account private key and the validation query made by the server, via the key <del> authorization.  The key authorization is signed by the account private key, reflects the corresponding public key, and is provided to the server in the validation response. </del>  The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who

Reviewer comments:
As pointed out to the list: There is this sentence in the security considerations (10.2 Integrity of Authorizations) that strikes me as extremely misleading: "All of the challenges above have a binding between the account private key and the validation query made by the server, via the key authorization. The key authorization is signed by the account private key, reflects the corresponding public key, and is provided to the server in the validation response." The key authorization itself does NOT contain the signature of the account's key. It gets though signed by the account's key later on in the challenge response (not the validation response) over the ACME channel (not the validation channel). What about saying that in the chronological order of events?

Revised text:
All of the challenges above have a binding between the account private key and the validation query made by the server, via the key  <ins> authorization.  The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. </ins> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who
Original text:
ACME Identifier Types (iana-identifier) <del> ACME Challenge Types (iana-challenge) </del>  All of these registries are under a heading of "Automated Certificate Management Environment (ACME) Protocol" and are administered under a 9.7.6. <del> This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in the template must be contained in the Label column of the ACME Identifier Types registry. </del>  Template: <del> Label: The value to be put in the "type" field of challenge objects using this validation mechanism </del>  <del> Identifier Type: The type of identifier that this mechanism applies to </del>  <del> Reference: Where the challenge type is defined </del>  Initial Contents  [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]

Reviewer comments:
It is useful in some contexts (e.g., ) to have identifiers for non-ACME methods that CAs use to validate control of an identifier. This PR updates the ACME Challenge Types registry to instead address Validation Methods more generally, with a column that indicates whether the method is an ACME method.
Okay, I see your point. Fine.

Revised text:
ACME Identifier Types (iana-identifier)  <ins> ACME Validation Methods (iana-validation) </ins> All of these registries are under a heading of "Automated Certificate Management Environment (ACME) Protocol" and are administered under a 9.7.6.  <ins> This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it corresponds to an ACME challenge type.  The "Identifier Type" field must be contained in the Label column of the ACME Identifier Types registry. </ins> Template:  <ins> Label: The identifier for this validation method </ins>  <ins> Identifier Type: The type of identifier that this method applies to </ins>  <ins> ACME: "Y" if the validation method corresponds to an ACME challenge type; "N" otherwise. Reference: Where the validation method is defined </ins> Initial Contents <ins> When evaluating a request for an assignment in this registry, the designated expert should ensure that the method being registered has a clear, interoperable definition and does not overlap with existing validation methods.  That is, it should not be possible for a client and server to follow take the same set of actions to fulfill two different validation mechanisms. Validation methods do not have to be compatible with ACME in order to be registered.  For example, a CA might wish to register a validation method in order to support its use with the ACME extensions to CAA I- D.ietf-acme-caa. </ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]
Original text:
public key and returns status code 200 (OK).  Otherwise, the server responds with an error status code and a problem document describing the error.  If there is an existing account with the new key <del> provided, then the server SHOULD use status code 409 (Conflict). </del>  Note that changing the account key for an account SHOULD NOT have any other impact on the account.  For example, the server MUST NOT

Reviewer comments:
Similar to Section 7.3.1 "Finding an Account URL Given a Key" when a key rollover request will result in a conflict with an existing account the header of the response should indicate the URL of the conflicting account. This saves the client from having to post the new-account endpoint to learn the account URL.

Revised text:
public key and returns status code 200 (OK).  Otherwise, the server responds with an error status code and a problem document describing the error.  If there is an existing account with the new key  <ins> provided, then the server SHOULD use status code 409 (Conflict) and provide the URL of that account in the Location header field. </ins> Note that changing the account key for an account SHOULD NOT have any other impact on the account.  For example, the server MUST NOT
Original text:
replace draft-ietf-acme-acme above with the RFC number assigned to this ]] <del> Applications which use this media type: Any MIME-complaint transport </del>  Additional information:

Reviewer comments:
Thanks to NAME for the report. Resolves URL
s/MIME-complaint/MIME-compliant/
NAME thanks - URL

Revised text:
replace draft-ietf-acme-acme above with the RFC number assigned to this ]]  <ins> Applications which use this media type: Any MIME-compliant transport </ins> Additional information:
Original text:
The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates <del> contact URLs it MUST support the "mailto" scheme.  If the server rejects a contact URL for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URLs the server considers acceptable.  If the server rejects a contact URL for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </del>  If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms

Reviewer comments:
This doesn't address the other piece of feedback, that mailto URLs can contain multiple entries.
If you don't allow , then it's only possible to have one address.
Oh, no, that's totally wrong, will update.

Revised text:
The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates  <ins> contact URLs it MUST support the "mailto" scheme.  Clients MUST NOT provide a "mailto" URL in the "contact" field that contains "hfields" RFC6068, or more than one "addr-spec" in the "to" component.  If a server encounters a "mailto" contact URL that does not meet these criteria, then it SHOULD reject it as invalid. If the server rejects a contact URL for using an unsupported scheme it MUST return an error of type "unsupportedContact", with a description describing the error and what types of contact URLs the server considers acceptable.  If the server rejects a contact URL for using a supported scheme but an invalid value then the server MUST return an error of type "invalidContact". </ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms