jiebi/TextFlow huggingface dataset:
Original text:
determine the correct issuer domain name to use when configuring CAA records.  Clients access the directory by sending a GET request to the directory URL. The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA.  When a CA receives a new-account request containing an "external- account-binding" field, it decides whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT

Reviewer comments:
While addressing Dale's Gen-ART comments, it occurred to me that while the document said that a CA could require external account binding, it didn't say how. This PR adds a "meta" field and an error code to support that requirements proactively and reactively.
Merging based on NAME review
:ship:

Revised text:
determine the correct issuer domain name to use when configuring CAA records. <ins> If this field is present and set to "true", then the CA requires that all new-account requests include an "external-account- binding" field associating the new account with an external account. </ins> Clients access the directory by sending a GET request to the directory URL. The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. <ins> If a CA requires that new-account requests contain an "external- account-binding" field, then it MUST provide the value "true" in the "external-account-required" subfield of the "meta" field in the directory object.  If the CA receives a new-account request without an "external-account-binding" field, then it should reply with an error of type "externalAccountRequired". </ins> When a CA receives a new-account request containing an "external- account-binding" field, it decides whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT
Original text:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <del> 8.6. There may be cases where a server cannot perform automated validation of an identifier, for example, if validation requires some manual steps.  In such cases, the server may provide an "out of band" (OOB) challenge to request that the client perform some action outside of ACME in order to validate possession of the identifier. The OOB challenge requests that the client have a human user visit a web page to receive instructions on how to validate possession of the identifier, by providing a URL for that web page. The string "oob-01" The URL to be visited.  The scheme of this URL MUST be "http" or "https".  Note that this field is distinct from the "url" field of the challenge, which identifies the challenge itself. A client responds to this challenge by presenting the indicated URL 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 acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). 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 validate identifier possession are determined by the server's local policy. </del> 9. 9.1. CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly <del> not involving a human user.  If a CA wishes to have stronger evidence of user consent, it may present an out-of-band requirement or challenge to require human involvement. </del>  11.

Reviewer comments:
The OOB challenge was added to accommodate non-ACME CAs building ACME integrations. Since then two non-ACME CAs have implemented ACME integrations using the external account binding feature but not implementing OOB challenges. Since the target demographic has not implemented this feature and has also not presented a use-case requiring it there seems to be no strong reasons to keep it in-spec.
NAME If you could update this to remove the OOB challenge from the , I'll go ahead and merge
NAME Good catch - thanks! Addressed in 0753c73.

Revised text:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails.  9. 9.1. CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly  <ins> not involving a human user. </ins> 11.
Original text:
ACME Resource Types (iana-resource)  ACME Identifier Types (iana-identifier) ACME Validation Methods (iana-validation) Initial contents: The fields and descriptions defined in account- objects.  9.7.2. This registry lists field names that are defined for use in ACME Initial contents: The fields and descriptions defined in order- objects.  9.7.3. This registry lists field names that are defined for use in ACME Initial contents: The fields and descriptions defined in authorization-objects.  9.7.4. This registry lists values that are used within URN values that are 9.7.6.  This registry lists the types of identifiers that can be present in ACME authorization objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 9.7.7. </del>  This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it

Reviewer comments:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:

Revised text:
ACME Resource Types (iana-resource) <ins> ACME Directory Metadata Fields (iana-meta) </ins> ACME Identifier Types (iana-identifier) ACME Validation Methods (iana-validation) Initial contents: The fields and descriptions defined in account- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.2. This registry lists field names that are defined for use in ACME Initial contents: The fields and descriptions defined in order- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.3. This registry lists field names that are defined for use in ACME Initial contents: The fields and descriptions defined in authorization-objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.4. This registry lists values that are used within URN values that are 9.7.6. <ins> This registry lists field names that are defined for use in the JSON object included in the "meta" field of an ACME directory object. Template: Field name: The string to be used as a field name in the JSON object Field type: The type of value to be provided, e.g., string, boolean, array of string Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] 9.7.7. </ins> This registry lists the types of identifiers that can be present in ACME authorization objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]]  <ins> 9.7.8. </ins> This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it
Original text:
In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate <del> the registration under which this certicate was issued.  The server MAY also include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del>  A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA

Reviewer comments:
The idea here is that if the CA opts not to log the precertificates it has a mechanism for publishing the proofs that are associated with a cert.
There are two good mechanisms to do this without adding a new endpoint: The CA implementing ACME can include SCTs in its OCSP responses Subscribers that wish to use SCTs, for instance in the TLS Extension mode of operation, may fetch those SCTs directly from the CT logs.
Neither of these seem like great substitutes. The first seems to violate straightforward reference semantics. The second puts a lot more work on the server.
I think this can be easily solved with a .

Revised text:
In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate  <ins> the registration under which this certicate was issued. The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) If the CA particpates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was submitted to a CT log.  An SCT can be included as a extension in the certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation "ct-sct". </ins> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA
Original text:
array after they are created.  If a client observes a change in the contents of either array, then it SHOULD consider the order invalid. <del> The "authorizations" array in the challenge SHOULD reflect all </del>  authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions.  For example, if a CA allows multiple

Reviewer comments:
Rewrite "in challenge", which seems to be incorrect to "of the order"
Good catch! Thank you NAME :eagle: :mag:

Revised text:
array after they are created.  If a client observes a change in the contents of either array, then it SHOULD consider the order invalid.  <ins> The "authorizations" array of the order SHOULD reflect all </ins> authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions.  For example, if a CA allows multiple
Original text:
qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin <del> with the ASCII Compatible Encoding prefix "xn-" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. </del>  identifier-validation-challenges describes a set of challenges for domain name validation.

Reviewer comments:
Prior to this commit the IDN prefix referenced from RFC5890 was being turned from to . This commit escapes the two dashes so they remain in the generated doc. Thanks to NAME for reporting! Resolves URL
In https://ietf-wg-URL This should be:
Opened URL with a fix. Thanks!

Revised text:
qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin  <ins> with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.
Original text:
One of the revocation reasonCodes defined in Section 5.3.1 of RFC5280 to be used when generating OCSP responses and CRLs.  If <del> this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The </del>  server MAY disallow a subset of reasonCodes from being used by the user.  If a request contains a disallowed reasonCode the server MUST reject it with the error type

Reviewer comments:
As recommended by . Thanks to for the catch.
NAME I believe you need write, admin, or owner permissions on the repo for a "changes requested" review to show up this way in the GH UI.
(Merging myself because it's the real author is NAME I'm just the scribe)
Could you please change the spelling? (Why won't I get a "Changes requested" with red marker?) Hello, https://ietf-wg-URL states: If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs. Yet URL says the opposite: the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. Could this be reworded somehow? It would make sense to store `0' in a database but later don't add a CRLReason extension / ASN.1 field. Cheers, Jörn

Revised text:
One of the revocation reasonCodes defined in Section 5.3.1 of RFC5280 to be used when generating OCSP responses and CRLs.  If  <ins> this field is not set the server SHOULD omit the reasonCode CRL entry extension when generating OCSP responses and CRLs.  The </ins> server MAY disallow a subset of reasonCodes from being used by the user.  If a request contains a disallowed reasonCode the server MUST reject it with the error type
Original text:
verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URL <del> in a Location header field. </del>  7.3.1.

Reviewer comments:
Section 6.2 "Request Authentication" says: Prior to this commit Section 7.3 "Account Creation" doesn't mention that the account URL also doubles as the key ID. To make the question of "What is my Key ID?" more obvious for client implementers this commit adds a brief mention of this fact where the specification discusses the account URL. Thanks to NAME for flagging this and providing a chance to avoid confusion and add clarity.
thanks

Revised text:
verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URL  <ins> in a Location header field.  The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (See request-authentication). </ins> 7.3.1.
Original text:
identifier-validation-challenges describes a set of challenges for domain name validation.  7.2. Before sending a POST request to the server, an ACME client needs to 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 <del> different validation mechanisms. </del>  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

Reviewer comments:
As suggested by Felipe Gasper
NAME fixed. Note, also standardized on "validation method" (vs. "mechanism"). Hello, I’ve been looking over the -09 draft and have created a Perl client module against Pebble as well as LE’s new testing endpoint. I’m curious about whether the specification intends to define Challenge objects. They appear to exist, of course, but they’re not defined as objects per se in section 7.1 of the draft. Thank you! -Felipe Gasper Mississauga, ON

Revised text:
identifier-validation-challenges describes a set of challenges for domain name validation. <ins> 7.1.5. An ACME challenge object represents a server's offer to validate a client's possession of an identifier in a specific way.  Unlike the other objects listed above, there is not a single standard structure for a challenge object.  The contents of a challenge object depend on the validation method being used.  The general structure of challenge objects and an initial set of validation methods are described in identifier-validation-challenges. </ins> 7.2. Before sending a POST request to the server, an ACME client needs to 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  <ins> different validation methods. </ins> 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
Original text:
7.3.3. <del> Servers SHOULD NOT respond to GET requests for account resources as </del>  these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the "contact" or "orders" fields), then it SHOULD do so by sending a POST

Reviewer comments:
Section "Request Authentication" already forbade it.
In general, we have not been making MUST-level requirements for servers in this document because CAs are subject to a lot of external constraints already. Under that theory, I would say we should just close this. NAME NAME wdyt?
If you don't want this change, can you change "Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification." instead to resolve the inconsistency?
NAME I agree with NAME - this isn't a new MUST-level requirement, it's already said elsewhere that the server MUST NOT respond to sensitive resources and the account object has contact information you wouldn't want returned to an unauthenticated GET request. It seems fine to emphasize this in the account information section.
I'm going to merge this. NAME gives an OOB +1. Thanks NAME !

Revised text:
7.3.3.  <ins> Servers MUST NOT respond to GET requests for account resources as </ins> these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the "contact" or "orders" fields), then it SHOULD do so by sending a POST
Original text:
ACME can also be used to automate some aspects of certificate management even where non-automated processes are still needed.  For example, the external account binding feature (see external-account- <del> binding) can be used to associate authorizations with an account that were not validated through the ACME authorization process.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </del>  2.

Reviewer comments:
Merging because editorial.
account binding feature (see {{external-account-binding}}) can be used to associate authorizations with an account that were not validated through the ACME authorization process. To me (non-native English speaker) "were not" refers to "an account" which would be a grammar mistake. If it refers to "authorizations" would it be better to switch "authorizations" and "an account"?
I think it is technically correct (it does refer to "authorizations"), but I agree it's an awkward sentence. Filed to address.

Revised text:
ACME can also be used to automate some aspects of certificate management even where non-automated processes are still needed.  For example, the external account binding feature (see external-account-  <ins> binding) can allow an ACME account to use authorizations that have been granted to an external, non-ACME account.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </ins> 2.
Original text:
a host which only functions as an ACME server could place the directory under the path "/". <del> If the ACME server does not implement pre-authorization (Section 7.4.1) it MUST omit the "newAuthz" field of the directory. </del>  The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of request to the new-authorization resource specifying the identifier for which authorization is being requested. <del> The identifier that the account is authorized to represent: </del>  <del> The type of identifier. The identifier itself. </del>  Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the

Reviewer comments:
Replaces
This text looks fine to me. I think there should be discussion in WGLC about this since folks that care about pre-authorization might be surprised by this new constraint.

Revised text:
a host which only functions as an ACME server could place the directory under the path "/".  <ins> If the ACME server does not implement pre-authorization (pre- authorization) it MUST omit the "newAuthz" field of the directory. </ins> The object MAY additionally contain a field "meta".  If present, it MUST be a JSON object; each field in the object is an item of request to the new-authorization resource specifying the identifier for which authorization is being requested.  <ins> The identifier to appear in the resulting authorization object (see authorization-objects) </ins>  <ins> Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- authorization cannot be used to authorize issuance with wildcard DNS identifiers. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the
Original text:
allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key).  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,

Reviewer comments:
1) Include optional field in the Account Creation section with a forward pointer to the external account binding section. 2) Include the mandatory "orders" field in the example new account response. 3) Correct the "orders" field type in Section 9.7.1 to match the type from 7.1.2 Thanks to NAME for flagging these issues on the WG Mailing List.

Revised text:
allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). <ins> An optional field for binding the new account with an existing non-ACME account (see external-account-binding ). </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,
Original text:
The identifier itself. The status of this authorization.  Possible values are: "pending", <del> "valid", "invalid", "deactivated", and "revoked". </del>  The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339

Reviewer comments:
1) Section 7.1.4 - Include "expires" in possible authz status values. 2) 7.1.2.1 - Fix orders link rel relation syntax Thanks to NAME for flagging these issues on-list.

Revised text:
The identifier itself. The status of this authorization.  Possible values are: "pending",  <ins> "valid", "invalid", "deactivated", "expired", and "revoked". </ins> The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339