jiebi/TextFlow huggingface dataset:
Original text:
extension. A request to finalize an order will result in error if the order <del> indicated does not have status "pending", if the CSR and order </del>  identifiers differ, or if the account is not authorized for the identifiers indicated in the CSR.

Reviewer comments:
When the "ready" status was added to the order process we missed a place in Section 7.4 where the specification claims an order should be in status "processing" when it is ready for finalization. This commit changes this sentence to say the order is ready for finalization when it is status "ready". Thanks to NAME for flagging this issue on-list.

Revised text:
extension. A request to finalize an order will result in error if the order  <ins> indicated does not have status "ready", if the CSR and order </ins> identifiers differ, or if the account is not authorized for the identifiers indicated in the CSR.
Original text:
required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. <del> For final authorizations, it contains the challenges that were successfully completed. </del> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard

Reviewer comments:
In section 7.1.4 "Authorization Objects" the "challenges" field is described as containing: Later, after discussing the array entries a duplicate sentence appears: This is already covered by the initial description of what a final authorization's challenges array holds and so this commit removes the second redundant sentence.

Revised text:
required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.  For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard
Original text:
ACME Order Object Fields (iana-order)  ACME Error Types (iana-error) ACME Resource Types (iana-resource)

Reviewer comments:
Section 9.7 "New Registries" itemizes the subsections that include new IANA registries. We added a subsection for "Authorization Object Fields" but forgot to add a link to it from the top level 9.7 text. This commit adds that forward pointer.

Revised text:
ACME Order Object Fields (iana-order) <ins> ACME Authorization Object Fields (iana-authz) </ins> ACME Error Types (iana-error) ACME Resource Types (iana-resource)
Original text:
associate 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 provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients. </del>  The ACME client then computes a binding JWS to indicate the external account holder's approval of the ACME account key.  The payload of File contains one or more certificates encoded with 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 <del> certificate.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust </del>  anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

Reviewer comments:
A few editorial things that Dale found.
Editorial diffs only. Merging as-is. Thanks NAME !
:shipit:

Revised text:
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, the CA operating the ACME server needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients. </ins> The ACME client then computes a binding JWS to indicate the external account holder's approval of the ACME account key.  The payload of File contains one or more certificates encoded with 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  <ins> certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust </ins> anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.
Original text:
"alg" (Algorithm) "jwk" (JSON Web Key, for all requests not signed using an <del> existing account, e.g. newAccount) </del>  "kid" (Key ID, for all requests signed using an existing account)

Reviewer comments:
Thanks to NAME .
Thanks NAME Merging with one review as this is strictly editorial. I’m not sure what the best forum is to report minor typographical issues, but: : "jwk" (JSON Web Key, for all requests not signed using an existing account, e.g. newAccount) ^^ Everyplace else in the spec puts a comma after “e.g.”, so I would think there should be one here as well. -Felipe Gasper

Revised text:
"alg" (Algorithm) "jwk" (JSON Web Key, for all requests not signed using an  <ins> existing account, e.g., newAccount) </ins> "kid" (Key ID, for all requests signed using an existing account)
Original text:
Either "jwk" (JSON Web Key) or "kid" (Key ID) as specified below  The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both.

Reviewer comments:
As proposed in EKR's AD review, discussed on-list and at IETF 102.
Of course, this needs WG consensus first.
Yes NAME just posting this so we can be concrete about the discussion in the meeting.
Merging this on AD+chair guidance guidance that we can

Revised text:
Either "jwk" (JSON Web Key) or "kid" (Key ID) as specified below <ins> An ACME server MUST implement the "ES256" signature algorithm RFC7518 and SHOULD implement the "EdDSA" signature algorithm using the "Ed25519" variant (indicated by "crv") RFC8037. </ins> The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both.
Original text:
request is signed with the private key corresponding to the "key" field of the request before updating the registration.  Servers SHOULD NOT respond to GET requests for registration resources as these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP or HTTPS GET request.  If using HTTPS, the ACME server MUST ignore the certificate provided by the HTTPS server. </del>  Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Reviewer comments:
vs. The spec doesn't seem to be consistent. And why does it have to be completed with HTTP? I honestly don't understand that.
LE's seems to give a choice. I'd really prefer that. This would make it possible to not even listen on port 80 for things like APIs, e.g. GitHub does that on .
As discussed on the list and in the document, the HTTP challenge needs to be HTTP-only in order to avoid the default-vhost issues. Thanks for catching the stray HTTPS text. I will remove it.
Do you have a link to the discussion?
See URL Is that example just bogus or what's the for? There are only two challenges, so it can't be an index there.
Good point. Left over from when we had three challenges in the example.
Contact information may have been misspelled during registration. Contact information such as phone numbers may also change. https://acme-URL exposes only the endpoint and that endpoint doesn't accept updates, because it has to respond with 409 Conflict for already existing keys. There should be a way to update that information. See also URL
thanks NAME yes updating the contact email for registered LE account is a must have feature otherwise an LE notifications/renew notices may end up going to invalid email addresses.
Right now, the spec says that you can update anything in the registration with a : Note that the request goes to the registration URL, not the new-registration URL. I'll add an example to the document to clarify.

Revised text:
request is signed with the private key corresponding to the "key" field of the request before updating the registration. <ins> For example, to update the contact information in the above registration, the client could send the following request: </ins> Servers SHOULD NOT respond to GET requests for registration resources as these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the Verify that the resulting URI is well-formed.  <ins> Dereference the URI using an HTTP GET request. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at
Original text:
requests without an entity body are not authenticated, in particular GET requests.  Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del>  If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del>  6.4. anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal.  A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

Reviewer comments:
As suggested by David Hancock, change the certificate fetch examples to use POST-as-GET, noting that GET is optional As suggested by Felix Fontein, use the correct error code for "malformed" in the description of what servers should do in response to inappropriate GET requests
Since doesn't look like it will be merged anytime soon, would it be possible to move the editorial (undisputed) stuff (trailing comma, authz -> challenge in URL) into this PR?
NAME I think I've gotten all the trailing commas and errant headersgit di.
NAME Looks good to me!
editorial clarifications, looks good to me.

Revised text:
requests without an entity body are not authenticated, in particular GET requests.  Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status  <ins> code 405 "Method Not Allowed" and type "malformed". </ins> If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status  <ins> code 405 "Method Not Allowed" and type "malformed". </ins> 6.4. anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <ins> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.
Original text:
these resources.  This enables clients to bootstrap into the ACME authentication system. <del> The server MAY allow GET requests for certificate resources in order to allow certificates to be fetched by a lower-privileged process, e.g., the web server that will use the referenced certificate chain. (See I-D.ietf-acme-star for more advanced cases.)  A server that allows GET requests for certificate resources can still provide a degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status code 405 "Method Not Allowed" and type "malformed". </del> 6.4. It is common in deployment for the entity terminating TLS for HTTPS

Reviewer comments:
This exception doesn't actually improve interop for STAR clients, and it introduces complexity into the security analysis of ACME. STAR can easily solve the problem by defining a new field on orders that provides an explicitly GETtable URL, with whatever security properties the STAR project needs.
Do not merge this without discussion on the mailing list.
Merging based on out-of-band approval from NAME

Revised text:
these resources.  This enables clients to bootstrap into the ACME authentication system.  6.4. It is common in deployment for the entity terminating TLS for HTTPS
Original text:
POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with <del> several low-entropy fields: </del>  Accounts: https://example.com/:accountID <del> Orders: https://example.com/:accountID/:orderID </del>  <del> Authorizations: https://example.com/:accountID/:authorizationID </del>  <del> Certificates: https://example.com/:accountID/:certID </del>  <del> If the ID fields have low entropy, then an attacker can find out how many users a CA has, how many authorizations each account has, etc. </del>  <del> In order to avoid leaking these correlations, servers SHOULD assign capability URLs for dynamically-created resources W3C.WD-capability- urls-20140218.  These URLs incorporate large unpredictable components to prevent third parties from guessing them.  These URLs SHOULD NOT have a structure that would enable a third party to infer correlations between resources. For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </del>  Accounts: https://example.com/acct/:accountID

Reviewer comments:
Fix a misuse of the term "capability URL." Change the example. Hiding the number of accounts was not a great example, because even with randomized account URLs, an attacker could probe the space of URLs to estimate their density.
Thanks for slimming this down. I can live with this version.Thanks NAME This looks fine to me.

Revised text:
POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with  <ins> guessable fields: </ins> Accounts: https://example.com/:accountID  <ins> Orders: https://example.com/:accountID/:domainName </ins>  <ins> Authorizations: https://example.com/:accountID/:domainName </ins>  <ins> Certificates: https://example.com/:accountID/:domainName </ins>  <ins> Under that scheme, an attacker could probe for which domain names are associated with which accounts, which may allow correlation of ownership between domain names, if the CA does not otherwise permit it. </ins>  <ins> To avoid leaking these correlations, CAs SHOULD assign URLs with an unpredictable component.  For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </ins> Accounts: https://example.com/acct/:accountID
Original text:
The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could <del> use the media type "application/pkix-cert" RFC2585 or "applicaiton/ </del>  pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD including the key in the PEM file returned in response to a query for a certificate URL. <del> When processing an file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </del>  certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.

Reviewer comments:
Change "applicaiton" to "application"
With any luck we'll have to catch this in the RFC editor queue; hopefully there won't be another draft.
Thanks NAME

Revised text:
The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could  <ins> use the media type "application/pkix-cert" RFC2585 or "application/ </ins> pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD including the key in the PEM file returned in response to a query for a certificate URL.  <ins> When processing a file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </ins> certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.
Original text:
unwilling to issue a certificate corresponding to the submitted CSR. For example: <del> If the order indicated does not have status "ready" </del> If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR. <del> A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take: </del>  "invalid": The certificate will not be issued.  Consider this order process abandoned.

Reviewer comments:
draft-ietf-acme-acme-18 §7.4 has two conflicting statements regarding what an ACME server should do when it receives a request to finalize an order that is not in the "ready" state: 'If the order indicated does not have status "ready" ... the problem document returned by the server SHOULD use error code "badCSR"'. 'A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take:', where values other than "ready" are listed. This PR proposes to resolve this conflict by requiring servers to return a new 'badState' error in response to a request to finalize an order that is not in the "ready" state. The client should respond to a "badState" error by re-fetching the order object and examining the status field to determine what to do.
I think a better name for this very specific error would be badOrderState or orderNotReady. That avoids potential confusion with bad states for authzs or challenges. Posted a proposed change in URL
Thanks NAME - this clarification makes sense to me. I'm +1 to applying your diff with the other AUTH48 changes. cc NAME Not really just editorial, but okay.

Revised text:
unwilling to issue a certificate corresponding to the submitted CSR. For example:  If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR.  <ins> A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the order will indicate what action the client should take: </ins> "invalid": The certificate will not be issued.  Consider this order process abandoned.
Original text:
Additional information: <del> Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .pem Macintosh file type code(s): n/a </del> Person & email address to contact for further information: See Authors' Addresses section. Field type: The type of value to be provided, e.g., string, boolean, array of string <del> Client configurable: Boolean indicating whether the server should accept values provided by the client </del>  Reference: Where this field is defined

Reviewer comments:
For pem-certificate-chain, the "Addition information" section was getting jumbled all onto one line by the Markdown to HTML generator. The table for Fields in Account Objects was jumbled. In the template for some registries, a field was called "Client configurable" in the next but "Configurable" in the table. Changed to always say "Configurable."

Revised text:
Additional information:  Person & email address to contact for further information: See Authors' Addresses section. Field type: The type of value to be provided, e.g., string, boolean, array of string  <ins> Configurable: Boolean indicating whether the server should accept values provided by the client </ins> Reference: Where this field is defined
Original text:
prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is <del> "example.org", then the client would provision the following DNS </del>  record: A client responds with an empty object ({}) to acknowledge that the

Reviewer comments:
Since is consistently used to represent the ACME server, we should always use to represent the ACME client. Whenever there's a single hostname we prefer the variant because the prefix makes it easier to quickly distinguish from . When there are two hostnames we use both and . Since we already used one order ID consistently through the doc, I made sure that its identifiers, notBefore, and notAfter were always the same. I tweaked the "expires" so it would be in a reasonable range (not precisely equal to the notBefore). Note that the "pending" version of the order has a slightly different expires than the "valid" order. One version of the finalized order had a cert ID of jWCdfHVGY2M and another had mAt3xBGaobw. Harmonized on mAt3xBGaobw since it was also used in the certificate retrieval example. Also fixed an accidentally duplicated nonce.
:100:

Revised text:
prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is  <ins> "www.example.org", then the client would provision the following DNS </ins> record: A client responds with an empty object ({}) to acknowledge that the