jiebi/CodeConvo huggingface dataset:
Change:
requests are allowed to send DNS type identifiers with a value that contains a wildcard prefix ('') as the leftmost label. The authorization object created for the wildcard identifiers in the requests are not allowed to carry the wildcard prefix in the authorization identifier per spec language: This is sensible because the authorization is not for the logical wildcard but for the specific base domain. This leaves an ambiguous situation for client developers/users. Imagine a situation where a user requests a new order with the following request body: It's possible two authorizations will be created for this case, but both will contain the identifier . This can be confusing to users! (e.g. shred/acme4j) If one of the authorizations fails a challenge validation operation the client can't know whether it was the "URL" validation, or the "URL" validation that failed and won't be able to prompt the user to retry with the failed domain removed. Generally speaking it makes presenting accurate error information difficult without over-fitting Let's Encrypt's particular Wildcard issuance policies. (E.g. see discussion in URL and URL) This commit introduces an optional boolean authorization field that can be used to indicate the authorization's identifier should be considered the base domain of a wildcard identifier that was requested. This replaces , which included the baggage of .

Discussion:
Subject Alternate Name Extension by RFC 5280 RFC5280.  An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix <del> in the authorization identifier value. </del> <ins> in the authorization identifier value.  The returned authorization MUST include the optional "wildcard" field, with a value of true. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents of

For final authorizations, it contains the challenges that were successfully completed. <ins> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard prefix this field MUST be present, and true. </ins> The only type of identifier defined by this specification is a fully- 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 with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the <del> first label) MUST NOT be included in authorization objects. </del> <ins> first label) MUST NOT be included in authorization objects.  If an authorization object conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.
Change:
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.

Discussion:
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> <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. <del> The identifier that the account is authorized to represent: </del> <ins> The identifier to appear in the resulting authorization object (see authorization-objects) </ins> <del> The type of identifier. The identifier itself. </del> <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
Change:
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.

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

Discussion:
The identifier itself. The status of this authorization.  Possible values are: "pending", <del> "valid", "invalid", "deactivated", and "revoked". </del> <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
Change:
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.

Discussion:
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> <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.
Change:
This PR clarifies that a client SHOULD NOT assume that the "identifiers", "authorizations" or "challenges" arrays returned in various server response objects are sorted. This PR also clarifies that while some have a 1:1 relationship between order identifiers and order authorizations this isn't a universal truth. This resolves URL
NAME Is 6 days without any feedback on-list sufficient to merge?
On the reuqest, there are two arrays returned, one for the and one for the . However, there is no order specified in ACMEv2. As two arrays are returned (and no hash), this might imply that the order of matches the order of . This is not specified right now. Having this specified would allow clients to know in advance for which identity they are requesting the authorization challenge before requesting the URL, e.g. for better error reporting. Also ok would be to just explicitly specify that the order is not guaranteed or the number of entries is not guaranteed to match in order to make it more clear to developers. cf. URL
From the outcome of the linked conversation, we should just specify that no specific order is guaranteed.
:+1: - URL I will start a mailing list thread since this is a new SHOULD NOT.
Looks good to me; let's wait a little bit for feedback on-list.

Discussion:
For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see <del> identifier-authorization).  For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </del> <ins> identifier-authorization).  The authorizations required are dictated by server policy and there may not be a 1:1 relationship between the order identifiers and the authorizations required. For final orders (in the "valid" or "invalid" state), the authorizations that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. </ins> A URL that a CSR must be POSTed to once all of the order's authorizations are satisfied to finalize the order.  The result of

(see identifier-authorization).  If the client fails to complete the required actions before the "expires" time, then the server SHOULD change the status of the order to "invalid" and MAY delete the order <del> resource. </del> <ins> resource.  Clients SHOULD NOT make any assumptions about the sort order of "identifiers" or "authorizations" elements in the returned order object. </ins> Once the client believes it has fulfilled the server's requirements, it should send a POST request to the order resource's finalize URL.
Change:
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.

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

Discussion:
ACME Order Object Fields (iana-order) <ins> ACME Authorization Object Fields (iana-authz) </ins> ACME Error Types (iana-error) ACME Resource Types (iana-resource)
Change:
A few editorial things that Dale found.
Editorial diffs only. Merging as-is. Thanks NAME !
:shipit:

Discussion:
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> <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 <del> certificate.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust </del> <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.
Change:
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

Discussion:
"alg" (Algorithm) "jwk" (JSON Web Key, for all requests not signed using an <del> existing account, e.g. newAccount) </del> <ins> existing account, e.g., newAccount) </ins> "kid" (Key ID, for all requests signed using an existing account)
Change:
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

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

Discussion:
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. <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> <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:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME

Discussion:
If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type <del> "urn:ietf:params:acme:error:badSignatureAlgorithm" (see errors).  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. </del> <ins> "urn:ietf:params:acme:error:badSignatureAlgorithm".  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values.  See errors for more details on the structure of error responses. </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field

The server granted the client authorization based on an external account <del> Clients should check the "status" field of an order to determine </del> <ins> Clients SHOULD check the "status" field of an order to determine </ins> whether they need to take any action. 7.1.4.

Validation responses need to be bound to an account key pair in order to avoid situations where a MitM on ACME HTTPS requests can switch <del> out a legitimate domain holder's account key for one of his choosing, e.g.: </del> <ins> out a legitimate domain holder's account key for one of his choosing. Such MitMs can arise, for example, if a CA uses a CDN or third-party reverse proxy in front of its ACME interface.  An attack by such an MitM could have the following form: </ins> Legitimate domain holder registers account key pair A

B (the MitM) instead of account key A (the legitimate domain holder) <del> 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 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. </del> <ins> All of the challenges defined in this document have a binding between the account private key and the validation query made by the server, via the key 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:
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.

Discussion:
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> <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 <del> code 405 "Method Not Allowed" and type "malformedRequest". </del> <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.
Change:
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

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