jiebi/CodeConvo huggingface dataset:
Change:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME

Discussion:
The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is <del> intended to verify that the server actually speaks for the domain. </del> <ins> intended to verify that the server actually speaks for the domain(s). </ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain

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 <del> server SHOULD NOT include expired certificates. </del> <ins> server SHOULD NOT include expired or revoked certificates. </ins> 5.3.

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 <del> submitted to a CT log.  An SCT can be included as a extension in the </del> <ins> submitted to a CT log.  An SCT can be included as an extension in the </ins> 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

7. <del> There are few types of identifier in the world for which there is a </del> <ins> There are few types of identifiers in the world for which there is a </ins> standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually

by their account keys, so this overall goal breaks down into two more precise goals: <del> Only an entity that controls a identifier can get an account key </del> <ins> Only an entity that controls an identifier can get an account key </ins> authorized for that identifier Once authorized, an account key's authorizations cannot be

holder) All of the challenges above that require an out-of-band query by the <del> server have a binding to the account private key, such that the only the account private key holder can successfully respond to the validation query: </del> <ins> server have a binding to the account private key, such that only the account private key holder can successfully respond to the validation query: </ins> HTTP: The value provided in the validation request is signed by the account private key.
Change:
Fix a misuse of the term "capability URL." Change the example. Hiding the number of accounts was not a great example, because even with randomized account URLs, an attacker could probe the space of URLs to estimate their density.
Thanks for slimming this down. I can live with this version.Thanks NAME This looks fine to me.

Discussion:
POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with <del> several low-entropy fields: </del> <ins> guessable fields: </ins> Accounts: https://example.com/:accountID <del> Orders: https://example.com/:accountID/:orderID </del> <ins> Orders: https://example.com/:accountID/:domainName </ins> <del> Authorizations: https://example.com/:accountID/:authorizationID </del> <ins> Authorizations: https://example.com/:accountID/:domainName </ins> <del> Certificates: https://example.com/:accountID/:certID </del> <ins> Certificates: https://example.com/:accountID/:domainName </ins> <del> If the ID fields have low entropy, then an attacker can find out how many users a CA has, how many authorizations each account has, etc. </del> <ins> Under that scheme, an attacker could probe for which domain names are associated with which accounts, which may allow correlation of ownership between domain names, if the CA does not otherwise permit it. </ins> <del> In order to avoid leaking these correlations, servers SHOULD assign capability URLs for dynamically-created resources W3C.WD-capability- urls-20140218.  These URLs incorporate large unpredictable components to prevent third parties from guessing them.  These URLs SHOULD NOT have a structure that would enable a third party to infer correlations between resources. For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </del> <ins> To avoid leaking these correlations, CAs SHOULD assign URLs with an unpredictable component.  For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </ins> Accounts: https://example.com/acct/:accountID
Change:
Change "applicaiton" to "application"
With any luck we'll have to catch this in the RFC editor queue; hopefully there won't be another draft.
Thanks NAME

Discussion:
The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could <del> use the media type "application/pkix-cert" RFC2585 or "applicaiton/ </del> <ins> use the media type "application/pkix-cert" RFC2585 or "application/ </ins> pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD

including the key in the PEM file returned in response to a query for a certificate URL. <del> When processing an file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </del> <ins> When processing a file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </ins> certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.
Change:
From Section 7.3: "MUST URL account bodies sent by the URL other fields that it does not recognize" in the first paragraph seems to be unnecessarily repeated by "MUST ignore any fields in the request object that it does not recognize" in the second paragraph. This PR merges these two paragraphs and discards the duplicated text. Also, "account bodies" isn't used anywhere else in the document, so this PR changes it to "account objects".
This looks reasonable to handle in AUTH48.
the last part isn't purely editorial, but okay.

Discussion:
true, indicates the client's agreement with the terms of service. This field cannot be updated by the client. <ins> Including this field in a newAccount request indicates approval by the holder of an existing non-ACME account to bind that account to this ACME account.  This field is not updateable by the client. (See external-account-binding). </ins> A URL from which a list of orders submitted by this account can be fetched via a POST-as-GET request, as described in orders-list.

allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). <del> An optional field for binding the new account with an existing non-ACME account (see external-account-binding ). </del> <ins> Same meaning as the corresponding server field defined in </ins> The server MUST ignore any values provided in the "orders" fields in <del> account bodies sent by the client, as well as any other fields that </del> <ins> account objects sent by the client, as well as any other fields that </ins> it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be <del> provided by the client. 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. </del> <ins> provided by the client.  The server MUST NOT reflect the "onlyReturnExisting" field or any 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 server validates

Initial contents: The fields and descriptions defined in account- objects. <ins> | Field Name | Field Type | Requests | Reference | |:-----------------|:-----------|:---------|:-------| ======= | status | string | new, account | RFC 8555 | | contact | array of string | new, account | RFC 8555 | | externalAccountBinding | object | new | RFC 8555 | | termsOfServiceAgreed | boolean | new | RFC 8555 | | onlyReturnExisting | boolean | new | RFC 8555 | | orders | string | none | RFC 8555 | </ins> 9.7.2. The "ACME Order Object Fields" registry lists field names that are
Change:
draft-ietf-acme-acme-18 §7.4 has two conflicting statements regarding what an ACME server should do when it receives a request to finalize an order that is not in the "ready" state: 'If the order indicated does not have status "ready" ... the problem document returned by the server SHOULD use error code "badCSR"'. 'A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take:', where values other than "ready" are listed. This PR proposes to resolve this conflict by requiring servers to return a new 'badState' error in response to a request to finalize an order that is not in the "ready" state. The client should respond to a "badState" error by re-fetching the order object and examining the status field to determine what to do.
I think a better name for this very specific error would be badOrderState or orderNotReady. That avoids potential confusion with bad states for authzs or challenges. Posted a proposed change in URL
Thanks NAME - this clarification makes sense to me. I'm +1 to applying your diff with the other AUTH48 changes. cc NAME Not really just editorial, but okay.

Discussion:
unwilling to issue a certificate corresponding to the submitted CSR. For example: <del> If the order indicated does not have status "ready" </del> If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in

server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR. <del> A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take: </del> <ins> A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the order will indicate what action the client should take: </ins> "invalid": The certificate will not be issued.  Consider this order process abandoned.
Change:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:

Discussion:
This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a <del> value that contained a wildcard prefix.  For other authorizations, it MUST be absent. </del> <ins> value that was a wildcard domain name.  For other authorizations, it MUST be absent.  Wildcard domain names are described in order- objects. </ins> The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded

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.  If an authorization object <del> 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. </del> <ins> conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, 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.

A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a <del> 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </del> <ins> 403 (Forbidden) error with a problem document of type "orderNotReady".  The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </ins> If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the

Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- <del> authorization cannot be used to authorize issuance with wildcard DNS identifiers. </del> <ins> authorization cannot be used to authorize issuance of certificates containing wildcard domain names. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the
Change:
For pem-certificate-chain, the "Addition information" section was getting jumbled all onto one line by the Markdown to HTML generator. The table for Fields in Account Objects was jumbled. In the template for some registries, a field was called "Client configurable" in the next but "Configurable" in the table. Changed to always say "Configurable."

Discussion:
Additional information: <del> Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .pem Macintosh file type code(s): n/a </del> Person & email address to contact for further information: See Authors' Addresses section.

Field type: The type of value to be provided, e.g., string, boolean, array of string <del> Client configurable: Boolean indicating whether the server should accept values provided by the client </del> <ins> Configurable: Boolean indicating whether the server should accept values provided by the client </ins> Reference: Where this field is defined
Change:
Since is consistently used to represent the ACME server, we should always use to represent the ACME client. Whenever there's a single hostname we prefer the variant because the prefix makes it easier to quickly distinguish from . When there are two hostnames we use both and . Since we already used one order ID consistently through the doc, I made sure that its identifiers, notBefore, and notAfter were always the same. I tweaked the "expires" so it would be in a reasonable range (not precisely equal to the notBefore). Note that the "pending" version of the order has a slightly different expires than the "valid" order. One version of the finalized order had a cert ID of jWCdfHVGY2M and another had mAt3xBGaobw. Harmonized on mAt3xBGaobw since it was also used in the certificate retrieval example. Also fixed an accidentally duplicated nonce.
:100:

Discussion:
prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is <del> "example.org", then the client would provision the following DNS </del> <ins> "www.example.org", then the client would provision the following DNS </ins> record: A client responds with an empty object ({}) to acknowledge that the
Change:
"newAuthorization" -> "newAuthz" Reverted the indentation on the IANA considerations since that resulted in the wrong XML

Discussion:
multiple entities to manage certificates). Authorization resources are created by the server in response to <del> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </del> <ins> newOrder or newAuthz requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending
Change:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.

Discussion:
domain(s). DV certificate validation commonly checks claims about properties <del> related to control of a domain name - properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </del> <ins> related to control of a domain name -- properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </ins> circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention.

The ACME client periodically contacts the CA to get updated certificates, stapled Online Certificate Status Protocol (OCSP) <del> responses, or whatever else would be required to keep the web server functional and its credentials up to date. </del> <ins> responses RFC6960, or whatever else would be required to keep the web server functional and its credentials up to date. </ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the

4. ACME allows a client to request certificate management actions using <del> a set of JavaScript Object Notation (JSON) messages carried over HTTPS RFC8259 RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </del> <ins> a set of JavaScript Object Notation (JSON) messages RFC8259 carried over HTTPS RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </ins> certificate, and proves control of the domain(s) in that certificate in order for the CA to issue the requested certificate.

6.1. Each ACME function is accomplished by the client sending a sequence <del> of HTTPS requests to the server, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate-management below describes the message formats used by the function and the order in which messages are sent. </del> <ins> of HTTPS requests to the server RFC2818, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate- management below describes the message formats used by the function and the order in which messages are sent. </ins> In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.  The ACME server acts

query, since the status of the challenge will not change until that time. <del> Clients can explicitly request a retry by resending their response to a challenge in a new POST request (with a new nonce, etc.).  This </del> <ins> Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.).  This </ins> allows clients to request a retry when the state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to
Change:
I'm not sure whether we should add something like:
I think "in a way that requires an agreement update" as you've written is clear enough. Users won't need to re-agree if just fixing a typographical error.

Discussion:
can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" <del> field, with the terms URI as its value. </del> <ins> field, with the terms URI as its value.  When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration
Change:
At the IETF meeting, we discussed the possibility of simplifying the "tls-sni-01" challenge to remove the iterations, as suggested in . NAME noted that if we were going to do that, we should recommend some ways for CAs to check whether a default vhost was in play. This PR adds such a note, and creates an "Operational Considerations" section for any future such notes that might come along.

Discussion:
CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <del> 10.  References </del> <ins> 10. </ins> <del> 10.1.  URIs </del> <ins> There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when configuring their services. [[ TODO: Other operational considerations ]] 10.1. In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to distinguish between different hosted services or "virtual hosts". When a client initiates a TLS connection with an SNI value indicating a provisioned host, the hosting platform routes the connection to that host. When a connection come in with an unknown SNI value, one might expect the hosting platform to terminate the TLS connection.  However, some hosting platforms will choose a virtual host to be the "default", and route connections with unknown SNI values to that host. In such cases, the owner of the default virtual host can complete a TLS-based challenge (e.g., "tls-sni-01") for any domain with an A record that points to the hosting platform.  This could result in mis-issuance in cases where there are multiple hosts with different owners resident on the hosting platform. A CA that accepts TLS-based proof of domain control should attempt to check whether a domain is hosted on a domain with a default virtual host before allowing an authorization request for this host to use a TLS-based challenge.  A default virtual host can be detected by initiating TLS connections to the host with random SNI values within the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). 11.  References 11.1.  URIs </ins> [1] https://github.com/ietf-wg-acme/acme