jiebi/CodeConvo huggingface dataset:
Change:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.

Discussion:
In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON <del> dictionary, whose keys are drawn from the following table and whose </del> <ins> object, whose keys are drawn from the following table and whose </ins> values are the corresponding URLs. There is no constraint on the actual URI of the directory except that

a host which only functions as an ACME server could place the directory under path "/". <del> The dictionary MAY additionally contain a key "meta".  If present, it MUST be a JSON dictionary; each item in the dictionary is an item of </del> <ins> The object MAY additionally contain a key "meta".  If present, it MUST be a JSON object; each field in the object is an item of </ins> metadata relating to the service provided by the ACME server. The following metadata items are defined, all of which are OPTIONAL:

The challenges that the client can fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array <del> entry is a dictionary with parameters required to validate the </del> <ins> entry is an object with parameters required to validate the </ins> challenge.  A client should attempt to fulfill at most one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid.

client needs to respond with information to complete the challenges. To do this, the client updates the authorization object received from the server by filling in any required information in the elements of <del> the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </del> <ins> the "challenges" object.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type,

Template: <del> Field name: The string to be used as a key in the JSON dictionary </del> <ins> Field name: The string to be used as a key in the JSON object </ins> Field type: The type of value to be provided, e.g., string, boolean, array of string

Template: <del> Key: The value to be used as a dictionary key in the directory object </del> <ins> Key: The value to be used as a field name in the directory object </ins> Resource type: The type of resource labeled by the key
Change:
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.

Discussion:
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> <ins> (Bad Request), and indicate the ACME error type </ins> "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> <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 <del> appropriate error code and description. </del> <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) <del> ACME Error Codes (iana-error) </del> <ins> ACME Error Types (iana-error) </ins> ACME Resource Types (iana-resource)

Template: <del> Code: The label to be included in the URN for this error, </del> <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 <del> Initial contents: The codes and descriptions in the table in errors </del> <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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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
Change:
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.)

Discussion:
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> <ins> DISCLAIMER: This is a WIP draft of ACME and has not yet had a thorough security analysis. </ins> <del> https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf- 4Yc </del> <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>
Change:
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

Discussion:
A "new-order" resource (applying-for-certificate-issuance) <del> A "revoke-certificate" resource (certificate-revocation) </del> <ins> A "revoke-cert" resource (certificate-revocation) </ins> A "key-change" resource (account-key-roll-over)
Change:
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.

Discussion:
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> <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 <del> high probability. </del> <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
Change:
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.

Discussion:
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> <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
Change:
Depends on
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Discussion:
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. <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> <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.
Change:
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.

Discussion:
9.7.5. <del> This registry lists the types of identifiers in certificates that ACME clients may request authorization to issue. </del> <ins> This registry lists the types of identifiers that can be present in ACME authorization objects. </ins> Template:
Change:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.

Discussion:
In order to help clients configure themselves with the right URLs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON <del> object, whose keys are drawn from the following table and whose values are the corresponding URLs. </del> <ins> object, whose fields names are drawn from the following table and whose values are the corresponding URLs. </ins> There is no constraint on the actual URL of the directory except that it should be different from the other ACME server resources' URLs,

a host which only functions as an ACME server could place the directory under the path "/". <del> The object MAY additionally contain a key "meta".  If present, it </del> <ins> The object MAY additionally contain a field "meta".  If present, it </ins> MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.

reflect them as already valid in any orders submitted by the client. If a CA wishes to allow pre-authorization within ACME, it can offer a <del> "new authorization" resource in its directory by adding the key "new- authz" with a URL for the new authorization resource. </del> <ins> "new authorization" resource in its directory by adding the field "new-authz" with a URL for the new authorization resource. </ins> To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier

Template: <del> Field name: The string to be used as a key in the JSON object </del> <ins> Field name: The string to be used as a field name in the JSON object </ins> Field type: The type of value to be provided, e.g., string, boolean, array of string

Template: <del> Key: The value to be used as a field name in the directory object </del> <ins> Field name: The value to be used as a field name in the directory object </ins> <del> Resource type: The type of resource labeled by the key </del> <ins> Resource type: The type of resource labeled by the field </ins> Reference: Where the resource type is defined
Change:
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?

Discussion:
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> <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
Change:
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.

Discussion:
ACME Identifier Types (iana-identifier) <del> ACME Challenge Types (iana-challenge) </del> <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. <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> <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: <del> Label: The value to be put in the "type" field of challenge objects using this validation mechanism </del> <ins> Label: The identifier for this validation method </ins> <del> Identifier Type: The type of identifier that this mechanism applies to </del> <ins> Identifier Type: The type of identifier that this method applies to </ins> <del> Reference: Where the challenge type is defined </del> <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 ]]
Change:
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.

Discussion:
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> <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
Change:
Thanks to NAME for the report. Resolves URL
s/MIME-complaint/MIME-compliant/
NAME thanks - URL

Discussion:
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> <ins> Applications which use this media type: Any MIME-compliant transport </ins> Additional information:
Change:
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.

Discussion:
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> <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