jiebi/CodeConvo huggingface dataset:
Change:
Previously, each authenticated POST included a copy of its public key in the JWS protected header. Servers were required to canonicalize this key in some way and look it up in a database, then verify the payload. However, servers also had the option of verifying the payload, and then looking up the key in the database. This opened up a category of potential bugs based on truncated database fields or hash collisions, where an attacker could craft a key pair the would potentially be matched to someone else's account. Incidental benefits: Switching to kid makes payloads somewhat smaller, and removes the need to define key equality in the ACME spec.
Updated based on feedback.
Updated. Rather than have a switch/case about how to authenticate revoke-cert, I split it into two resources, authenticated different ways: one by account, one by cert key.

Discussion:
"alg" <del> "jwk" </del> <ins> "jwk" (only for requests to new-reg and revoke-cert resources) "kid" (for all other requests). </ins> "nonce" (defined below) "url" (defined below) <del> Note that this implies that GET requests are not authenticated. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </del> <ins> The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. For new-reg requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. For all other requests, there MUST be a "kid" field.  This field must contain the account URI received by POSTing to the new-reg resource. Note that authentication via signed POST implies that GET requests are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed

5.3. <del> At several points in the protocol, it is necessary for the server to </del> <ins> At some points in the protocol, it is necessary for the server to </ins> determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in
Change:
One of the most common ACME deployment failures observed in practice is for servers to be configured to serve only the end-entity certificate, without the intermediate certificates. This is a particularly pernicious problem because some browsers will still trust the resulting one-certificate chain, due to caching or fetching of URLs from Authority Information Access. But other browsers will not, resulting in a "works on my computer" problem. Arguably this configuration is the result of incorrect clients, but we should expect that most clients will do the easiest thing. This change aligns the easiest thing with the most correct thing.
You should include advice here on omitting trust anchors. TLS 1.3 has you could crib from (see the definition of ).
Hi, the PEM text is not correct: application/x-pem-file is not a registered media type, among other things. Will post to mailing list with details.

Discussion:
To download the issued certificate, the client simply sends a GET request to the certificate URL. <del> The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/x-pem-file to request the certificate in PEM format. The server provides metadata about the certificate in HTTP headers. In particular, the server MUST send one or more link relation header fields RFC5988 with relation "up", each indicating a single certificate resource for the issuer of this certificate.  The server MAY also include the "up" links from these resources to enable the client to build a full certificate chain. </del> <ins> The default format of the certificate is PEM (application/x-pem-file) as specified by RFC7468.  This format should contain the end-entity certificate first, followed by any intermediate certificates that are needed to build a path to a trusted root.  Servers SHOULD NOT include self-signed trust anchors.  The client may request other formats by including an Accept header in its request.  For example, the client may use the media type application/pkix-cert to request the end- entity certificate in DER format. The server MAY provide one or more link relation header fields RFC5988 with relation "alternate".  Each such field should express an alternative certificate chain starting with the same end-entity certificate.  This can be used to express paths to various trust anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. </ins> The server MUST also provide a link relation header field with relation "author" to indicate the application under which this
Change:
I spotted a typo/error introduced by this PR and submitted a follow-up: URL
Since we did not get consensus around , we should be explicit that HTTP is TCP port 80, and HTTPS is TCP port 443, and that holds for redirects as well. The is pretty much a minor wording change only.

Discussion:
Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del> <ins> Dereference the URI using an HTTP GET request.  This request MUST be sent to TCP port 80 on the server. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del> <ins> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other
Change:
Pull request was recently merged to clarify that HTTP and TLS challenge requests must use port 80 and 443 respectively. The "TLS with Server Name Indication (TLS SNI)" section was updated to read: This is a typo ("port 443 the domain name") and also still includes the phrase "on the requested port", which is no longer true. This PR updates the SNI challenge description to fix the typo and to explicitly say that the server MUST use port 443 in the same style/manner as the HTTP edit from .
Thanks for fixing my lame typos

Discussion:
Compute SAN A and SAN B in the same way as the client. <del> Open a TLS connection to TCP port 443 the domain name being validated on the requested port, presenting SAN A in the SNI field.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </del> <ins> Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent to TCP port 443 on the server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. </ins> Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other
Change:
As far as I am aware there has been no explicit use case for this and Boulder explicitly disallows URIs to be used. should be the only explicitly supported URI type in the spec and others should be left up to implementing CAs to document.
Conversation on-list went more in the direction of specifying that providing any contact with an unrecognized URI scheme should result in a hard error of . Renaming appropriately.

Discussion:
are specified in the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> 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. </ins> The server creates a registration object with the included contact information.  The "key" element of the registration is set to the public key used to verify the JWS (i.e., the "jwk" element of the JWS
Change:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..

Discussion:
8. <del> [[ Editor's Note: Should we create a registry for tokens that go into the various JSON objects used by this protocol, i.e., the field names in the JSON objects? ]] </del> 8.1. The "Well-Known URIs" registry should be updated with the following

8.6.1. <ins> This registry lists field names that are defined for use in ACME account objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. 8.6.2. This registry lists field names that are defined for use in ACME order objects.  Fields marked as "client configurable" may be included in a new-account request. Template: Field name: The string to be used as a key in the JSON dictionary Field type: The type of value to be provided, e.g., string, boolean, array of string Client configurable: Boolean indicating whether the server should accept values provided by the client Reference: Where this field is defined Initial contents: The fields and descriptions defined in order- objects. 8.6.3. </ins> This registry lists values that are used within URN values that are provided in the "type" field of problem documents in ACME.

Initial contents: The codes and descriptions in the table in errors above, with the Reference field set to point to this specification. <del> 8.6.2. </del> <ins> 8.6.4. </ins> This registry lists the types of resources that ACME servers may list in their directory objects.

[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.3. </del> <ins> 8.6.5. </ins> This registry lists the types of identifiers that ACME clients may request authorization to issue in certificates.

[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 8.6.4. </del> <ins> 8.6.6. </ins> This registry lists the ways that ACME servers can offer to validate control of an identifier.  The "Identifier Type" field in template
Change:
Also: Forbid the use of MAC-based JWS algorithms (in case this wasn't obvious) Sort error codes alphabetically
The server needs to support whatever the client sends. We should have an error code for this, and a way for the server to specify what algorithms it does support in the error message.

Discussion:
The JWS MUST NOT have the value "none" in its "alg" field <ins> The JWS MUST NOT have a MAC-based algorithm in its "alg" field </ins> The JWS Protected Header MUST include the following fields: "alg"

are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. <ins> 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 "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. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so
Change:
In some cases, it might be important for a client to know that a server has or has not processed an extension field. For example, if we had an extension that requested some higher level of assurance, then a client would want to know that the CA was going to provide that level of assurance. This PR specifies some rudimentary feature detection to support this objective.

Discussion:
the future, the specification of those fields MUST describe whether they may be provided by the client. <ins> In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </ins> 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
Change:
Implements from the mailing list. On Tue, Nov 29, 2016 at 04:32:33PM -0500, Richard Barnes wrote: than server implementations. With the current language, the client must check that authorizations have not changed. The language for the server should be MUST NOT change the elements of the "authorizations" array once set.'', unambiguously putting the responsibility where it squarely belongs - with the server. The spec could further elaborate that clientsSHOULD consider the application invalid'' if a change is detected. I see no reason why clients should be burdened (by way of ``MUST'') with detecting a condition that will not arise with compliant servers, and is unlikely to cause practical issues if it does occur after a certificate has been issued. Thanks, Fraser

Discussion:
order. The elements of the "authorizations" array are immutable once set. <del> If any change is made to the array after the object is created, the client MUST consider the order invalid. </del> <ins> The server MUST NOT change the contents of the "authorizations" array after it is created.  If a client observes a change in the contents of the "authorizations" array, then it SHOULD consider the order invalid. </ins> The "authorizations" array in the challenge SHOULD reflect all authorizations that the CA takes into account in deciding to issue,
Change:
Failure to synchronize between and . Also removes a stray word and some whitespace in the vicinity.
Also in the registries (and in the "Order Objects" section), is the authorizations property of an order object an array of strings (URLs) or an array of dictionaries (each of which contains status and URL parameters)?
NAME array of strings, since

Discussion:
URL-TBD <del> No transformation needed.  The </del> <ins> No transformation needed. </ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document, and replace URL-TBD with the URL assigned by IANA
Change:
The new-nonce endpoint added in defines a new endpoint which returns information just in headers, but with a 200 response code. I feel this would be more appropriate as a 204 No Content response code. I'm not sure what the approach to making this sort of change is. Should I create this change as a PR?
NAME A PR and a small note to the mailing list is probably the best approach. I'm not an HTTP status lawyer but it seems like 204 is the more-appropriate choice in this context and seems to agree with you: I would :+1: the PR to change to 204 for :-)

Discussion:
To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce, and SHOULD have <del> status code 200 (OK).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </del> <ins> status code 204 (No Content).  The server SHOULD also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header). </ins> Caching of responses from the new-nonce resource can cause clients to be unable to communicate with the ACME server.  The server MUST
Change:
Removed unnecessary paragraphs from authorizations field description in order object.
Thanks NAME not sure how I missed that in :)

Discussion:
that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. <del> The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object. A URL from which the authorization can be fetched with a GET request. </del> A URL for the certificate that has been issued in response to this order.
Change:
Also switches the type of the challenge type to be instead of as JSON doesn't have dictionaries. I'll push a follow-up PR that will switch the rest of the -> .

Discussion:
5.7. <del> Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </del> <ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges. ACME servers can return responses with an HTTP error response code (4XX or 5XX).  For example: If the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). </ins> When the server responds with an error status, it SHOULD provide additional information using problem document RFC7807.  To facilitate

standard types.  Clients SHOULD display the "detail" field of all errors. <del> Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. </del> 6. In this section, we describe the certificate management functions
Change:
As they are all fulfilled by the endpoint and are unnecessary. The relation is removed as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in (or submit it itself). Also removes a paragraph about Certificate Transparency from the 'Downloading the Certificate' section as it is irrelevant to the section and discusses operations of the CA unrelated to the ACME protocol. Additionally changes the relation which is not registered with a URI extension using the ACME URN namespace .
Looks good. Was posted on the list two weeks ago, with no objections, so merging.

Discussion:
In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits <del> using the "rate-limit" relation. </del> <ins> using the "urn:ietf:params:acme:documentation" relation. </ins> 5.7.

client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource. <del> The "directory" link relation is present on all resources other than the directory and indicates the directory URL. </del> <ins> The "index" link relation is present on all resources other than the directory and indicates the directory URL. </ins> The following diagram illustrates the relations between resources on an ACME server.  For the most part, these relations are expressed by

anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> The server MUST also provide a link relation header field with relation "author" to indicate the order under which this certificate was issued. If the CA participates 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 an 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". </del> 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:
Note is still required.
In this case it seems better to address the removal of the editor's note than to optimize its contents - do we know if this note is still required?

Discussion:
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 <del> -04 was compatible with one in version -04. ]] </del> <ins> -04 was compatible with one in version -03. ]] </ins> 7.1.
Change:
Previously these were spread among the various challenges. We can simplify by putting them in one place. Replaces .

Discussion:
Verify that the contents of one of the TXT records matches the digest value <del> It is RECOMMENDED that the server perform multiple DNS queries from various network perspectives, in order to make MitM attacks harder. </del> If all of the above verifications succeed, then the validation is successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails.

validation response for his own account key.  The risks due to hosting providers noted above are a particular case. <ins> It is RECOMMENDED that the server perform DNS queries and make HTTP and TLS connections from various network perspectives, in order to make MitM attacks harder. </ins> 10.3. As a protocol run over HTTPS, standard considerations for TCP-based