jiebi/CodeConvo huggingface dataset:
Change:
We need a challenge type to cover types of validation that can't be done automatically, in band to ACME. For example, a CA doing OV or EV validation might need the applicant to upload some documents through a web form. We should add a generic "out-of-band" challenge type that has a URL for a web site where the applicant gan go for instructions. I think the challenge object would look something like: There would be no response object; you just click the link, and when you complete the instructions there, the CA reflects this in the "status" field of the challenge object.
A few months back I wrote up a for this idea -- the hope is that ACME could evolve to become the language that all cert issuers talk to support a standard for cert management and exchange.
At IETF 95, agreed that this seemed reasonable to pursue, but needs to have a PR that describes what the URI characteristics are.

Discussion:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <ins> 7.5. 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" A client responds to this challenge by presenting the indicated URL for a human user to navigate to.  If the user choses to complete this challege (by vising the website and completing its instructions), the client indicates this by sending a simple acknowledgement response to the server. The string "oob-01" On receiving a response, the server MUST verify that the value of the "type" field is as required.  Otherwise, the steps the server takes to validate identifier possession are determined by the server's local policy. </ins> 8. [[ Editor's Note: Should we create a registry for tokens that go into
Change:
As discussed in the thread about , we can have a fairly clean recovery story (assuming a MAC key can be provisioned. As a first step, we should reverse the order of the signatures in the roll-over request object. Just wanted to make sure everyone is aware that there's an ACME F2F meeting happening at the IETF this afternoon, 17:40-19:40 Argentina Time (13:40-15:40 US Pacific, 20:40-22:40 UTC). URL Remote participation is possible. You can find links to audio streaming, XMPP chat, and a MeetEcho room in ACME line on the above agenda page. See you there! --Richard

Discussion:
The string "reg", indicating an update to the registration. <del> The JWK thumbprint of the old key RFC7638, base64url-encoded </del> <ins> The JWK thumbprint of the new key RFC7638, base64url-encoded </ins> <del> The client signs this object with the new key pair and encodes the </del> <ins> The client signs this object with the old key pair and encodes the </ins> object and signature as a JWS.  The client then sends this JWS to the <del> server in the "newKey" field of a request to update the registration. </del> <ins> server in the "rollover" field of a request to update the registration. </ins> <del> On receiving a request to the registration URL with the "newKey" </del> <ins> On receiving a request to the registration URL with the "rollover" </ins> attribute set, the server MUST perform the following steps: <del> Check that the contents of the "newKey" attribute are a valid JWS </del> <ins> Check that the contents of the "rollover" attribute are a valid JWS </ins> <del> Check that the "newKey" JWS verifies using the key in the "jwk" header parameter of the JWS </del> <ins> Check that the "rollover" JWS verifies using the account key correspdonding to this registration </ins> Check that the payload of the JWS is a valid JSON object Check that the "resource" field of the object has the value "reg" <del> Check that the "oldKey" field of the object contains the JWK thumbprint of the account key for this registration </del> <ins> Check that the "newKey" field of the object contains the JWK thumbprint of the account key used to sign the request </ins> If all of these checks pass, then the server updates the registration by replacing the old account key with the public key carried in the <del> "jwk" header parameter of the "newKey" JWS object. </del> <ins> "jwk" header of the request JWS. </ins> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body.
Change:
This reverts commit a5cb357a64ce5e46815544c9faaf94b97b3eba56 I think we did not reach consensus on the list about this feature.
Oh, it's a shame that this was removed. I was hoping to use this feature to help when my servers were behind a load balancer. We should probably remove this reference as well:

Discussion:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records.  Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non- intuitive manner, the challenge must be completed over HTTP, not HTTPS. </del> <ins> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "http-01"

The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. <del> An IPv4 or IPv6 address, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves when the server attempts validation.  If given, the server SHOULD connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves. </del> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then

Verify that the resulting URI is well-formed. <del> If the client has supplied an address to use, verify that the address is included in the A or AAAA records to which the domain name resolves.  If the address is not included in the result, the validation fails. Dereference the URI using an HTTP GET request.  If an address was supplied by the client, use that address to establish the HTTP connection. </del> <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
Change:
The current mechanism has a potential copy/paste vulnerability. Karthik proposed on the list: That is, you need the full matrix of "X signs over Y" -- "new/old", "new/new", "old/old", "old/new" -- so that both sides explicitly agree to the (old, new) pair. But the current design has only has "old/new" and "new/new". That raises a risk that if you got an "old/new" signature, you could copy/paste the "new/new" signature and get a valid request. As long as we have parallel signatures (cf. ), we need to have both the old and new keys in the payloads.

Discussion:
registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. <del> To change the key associate with an account, the client POSTs a key- change object with a "key" field containing a JWK representation of the new public key.  The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </del> <ins> To change the key associate with an account, the client sends a POST request containing a key-change object with the following fields: The JWS representation of the original key (i.e., the client's current account key) The JWS representation of the new key The JWS of this POST must have two signatures: one signature from the existing key on the account, and one signature from the new key that the client proposes to use.  This demonstrates that the client actually has control of the private key corresponding to the new public key.  The protected header must contain a JWK field containing the current account key. </ins> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation:
Change:
Fixing two minor typos in Section 6.2.1 "Account Key Roll-over"

Discussion:
registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise. <del> To change the key associate with an account, the client sends a POST </del> <ins> To change the key associated with an account, the client sends a POST </ins> request containing a key-change object with the following fields: The JWK representation of the original key (i.e., the client's

On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: <del> Check that the JWS protected header container a "jwk" field </del> <ins> Check that the JWS protected header contains a "jwk" field </ins> containing a key that matches a currently active account. Check that there are exactly two signatures on the JWS.
Change:
It seem like the only way to retrieve an existing registration object for a given key is to provoke an error by attempting to register again with the same key and read the Location from it. As a client library implementor, I would expect to and to not be recoverable. I think its strange that the only way to recover the registration object is by triggering an error. Would it make sense to add an extra endpoint to simply retrieve the registration object? Alternatively, I don't see any reason for the endpoint not to return when already registered (instead of when it create the registration) as opposed to a . Also, the returned error type in boulder is , which does not make much sense to me since the request was not malformed. If its an expected behaviour to provoke an error to recover data from the response, the error type should be specify into the spec and unique so its can be recovered from easily. Implementation in boulder and initial discussion in the ruby .

Discussion:
field. If the server already has a registration object with the provided <del> account key, then it MUST return a 409 (Conflict) response and provide the URI of that registration in a Location header field. This allows a client that has an account key but not the corresponding registration URI to recover the registration URI. </del> <ins> account key, then it MUST return a 200 (OK) response and provide the URI of that registration in a Content-Location header field.  This allows a client that has an account key but not the corresponding registration URI to recover the registration URI. </ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms
Change:
As discussed at IETF 96, ACME server processing of the "url" field should perform an exact string equality test between the URL string provided to the client and the string provided by the client in its "url" parameter. Effectively, this turns "url" values into opaque service labels, which just happen to have the side effect of being able to direct an HTTP request.

Discussion:
server MUST reject the request as unauthorized. Except for the directory resource, all ACME resources are addressed <del> with URLs provided to the client by the server.  In such cases, the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL). </del> <ins> with URLs provided to the client by the server.  For these resources, the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" fields. </ins> 5.3.1.
Change:
The registration object already contains a list of certificate applications, and each application contains a link to the resulting certificate if one was issued. This reduces the number of primitives that an ACME server has to support.

Discussion:
Link header with link relation "next" indicating a URL to retrieve further entries. <del> A URI from which a list of certificates issued for this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The server SHOULD NOT include expired or revoked certificates.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del> 6.1.3. An ACME registration resource represents a client's request for a
Change:
Prior to this PR the specification seems to be contradictory, indicating that the "new-X" resources must not be duplicated, but that they can live at different URIs. It's not clear to me what this MUST is trying to prevent, especially in light of an allowance of multiple URIs if functionality is equivalent. Similarly, while the text prior to this PR says "new-X" I believe the intentions of the statements that follow would include some of the resources that have been added since, e.g. "key-change". This PR updates the "new-X" language to include the additional singular resources and removes the MUST. If I've missed the mark in this clarification perhaps someone who was involved with the spec at the time of this paragraph's writing can help guide us to something both clear & accurate to the original spirit.

Discussion:
A "key-change" resource <del> For the "new-X" resources above, the server MUST have exactly one resource for each function.  This resource may be addressed by multiple URIs, but all must provide equivalent functionality. </del> <ins> For the singular resources above ("directory", "new-registration", "new-application", "revoke-certificate", and "key-change") the resource may be addressed by multiple URIs, but all must provide equivalent functionality. </ins> ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI,
Change:
They should be base64url rather than base64, for symmetry with rest of spec.
Don't think this is totally necessary, since we say at the front that when we say "base64", we mean the special variant. But happy to be clearer here.

Discussion:
The string "proofOfPossession-01" <del> An array of certificates, in Base64-encoded DER format, that </del> <ins> An array of certificates, in Base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key
Change:
Right now, it's not clear when the client needs to agree to the server's terms, and what the server should do if it needs the client to re-agree. This PR addresses both with a dedicated error code and some related behaviors.

Discussion:
If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms can be accessed in the "terms-of-service" subfield of the "meta" <del> field in the directory object, and the server SHOULD reject new- registration requests that do not contain "terms-of-service-agreed": true. </del> <ins> field in the directory object, and the server MUST reject new- registration requests that do not have the "terms-of-service-agreed" set to "true". </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration

6.3.1. <ins> As described above, a client can indicate its agreement with the CA's terms of service by setting the "terms-of-service-agreed" field in its registration object to "true". If the server has changed its terms of service since a client initially agreed, and the server is unwilling to process a request without explicit agreement to the new terms, then it MUST return an error response with status code 403 (Forbidden) and type "urn:ietf:params:acme:error:agreementRequired".  This response MUST include a Link header with link relation "terms-of-service" and the latest terms-of-service URL. The problem document returned with the error MUST also include an "instance" field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms. 6.3.2. </ins> A client may wish to change the public key that is associated with a registration in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.

responds with an error status code and a problem document describing the error. <del> 6.3.2. </del> <ins> 6.3.3. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do
Change:
requires IDNs be encoded in this way in order to be stored in the X509 certificate dNSNames field. Compliance with this RFC is one of the requirements of the CABForum which CAs are expected to adhere to. We already require domain names transmitted via ACME to use the ASCII encoding, this just formalizes how IDNs should be converted.

Discussion:
The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier <del> MUST be the ASCII representation of the domain name.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization requests. </del> <ins> MUST be the ASCII representation of the domain name.  If a domain name contains Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin 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 requests. </ins> 6.2.
Change:
With the combinations array now removed, this is no longer accurate.
If you could re-wrap that paragraph to get rid of the short line, LGTM.
I tend not to re-wrap Markdown on edits because it makes diffs & blames more meaningful. Do you feel strongly about the wrapping?

Discussion:
taken to fulfill the challenge, e.g., removing files that have been provisioned to a web server. <del> Presumably, the client's responses provide the server with enough information to validate one or more challenges.  The server is said to "finalize" the authorization when it has completed all the validations it is going to complete, and assigns the authorization a </del> <ins> The server is said to "finalize" the authorization when it has completed one of the validations, by assigning the authorization a </ins> status of "valid" or "invalid", corresponding to whether it considers the account authorized for the identifier.  If the final state is "valid", the server MUST add an "expires" field to the authorization.
Change:
Signing with the current account key allows servers to use the same message transport authentication that they use for other requests, simplifying the verification. Also fix two spots where we still described newKey/oldKey as thumbprints.
LGTM. I had only done that signing order to be forward-compatible with some imagined future recovery scheme, but if we decide to do that someday, that patch can differ in signature order as well as whatever else.

Discussion:
The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed <del> with the client's current account key (i.e., the key matching the "oldKey" value). This inner JWS then become the payload of the JWS that the client sends to the server.  The outer JWS is signed with the key pair that the the client wishes to have the server use as its account key (i.e., the key pair matching the "newKey" value).  The client sends this outer JWS in a POST request to the server's "key-change" resource. </del> <ins> with the requested new account key (i.e., the key matching the "newKey" value). </ins> The outer JWS MUST meet the normal requirements for an ACME JWS (see request-authentication).  The inner JWS MUST meet the normal

On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: <ins> Validate the POST request belongs to a currently active account, as described in Message Transport. </ins> Check that the payload of the JWS is a well-formed JWS object (the "inner JWS") Check that the JWS protected header of the inner JWS has a "jwk" <del> field containing a key that matches a currently active account </del> <ins> field. </ins> Check that the inner JWS verifies using the key in its "jwk" field

the URL for the registration matching the old key Check that the "oldKey" field of the key-change object contains <del> the thumbprint of the key used to sign the inner JWS </del> <ins> the current account key. </ins> Check that the "newKey" field of the key-change object contains <del> the thumbprint of the key used to sign the outer JWS </del> <ins> the key used to sign the inner JWS. </ins> If all of these checks pass, then the server updates the corresponding registration by replacing the old account key with the