jiebi/CodeConvo huggingface dataset:
Change:
It is no longer necessary with the order based issuance flow that allows the server to specify which authorizations a client must satisfy to allow issuance of an order. See URL Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back at the PR that introduced the "scope" field[0] and knowing the current state of order based issuance I'm not clear why this field is needed, or what a client could do with the scope information. Can someone clarify or should this part of the spec be removed? The server determines as a matter of policy which authorizations are required for an order and includes these in the order's array. If part of that server policy is to treat some valid authorizations as only being valid for a specific order then the server can simply not include those valid authorizations in the order's authorizations array and can instead create new pending authorizations for the client to solve. The client doesn't need to understand authorization scope it just needs to know which authorizations the server says are required and how to move these authorizations to a valid state. Since the client can't ask for specific authorizations to be used with specific orders and must react to what the server provides why is it helpful to tell a client that one of the authorizations it solved won't be used with future orders? Similarly I think the scope field interacts weirdly with pre-authorization. Are all authorization objects created with pre-authorization assumed to be global scope since they aren't associated with an order? Have any ACME clients or servers implemented order scope? Let's Encrypt/Boulder/Pebble have not. Daniel / cpu [0] - URL

Discussion:
RFC3339.  This field is REQUIRED for objects with "valid" in the "status" field. <del> If this field is present, then it MUST contain a URL for an order resource, such that this authorization is only valid for that resource.  If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. </del> For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier.  For final authorizations, the challenges that were used.  Each array entry

This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers), or to associate multiple accounts with an identifier (e.g., to allow <del> multiple entities to manage certificates).  The server may declare that an authorization is only valid for a specific order by setting the "scope" field of the authorization to the URL for that order. </del> <ins> multiple entities to manage certificates). </ins> Authorization resources are created by the server in response to certificate orders or authorization requests submitted by an account
Change:
While addressing Dale's Gen-ART comments, it occurred to me that while the document said that a CA could require external account binding, it didn't say how. This PR adds a "meta" field and an error code to support that requirements proactively and reactively.
Merging based on NAME review
:ship:

Discussion:
determine the correct issuer domain name to use when configuring CAA records. <ins> If this field is present and set to "true", then the CA requires that all new-account requests include an "external-account- binding" field associating the new account with an external account. </ins> Clients access the directory by sending a GET request to the directory URL.

The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. <ins> If a CA requires that new-account requests contain an "external- account-binding" field, then it MUST provide the value "true" in the "external-account-required" subfield of the "meta" field in the directory object.  If the CA receives a new-account request without an "external-account-binding" field, then it should reply with an error of type "externalAccountRequired". </ins> When a CA receives a new-account request containing an "external- account-binding" field, it decides whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT
Change:
The OOB challenge was added to accommodate non-ACME CAs building ACME integrations. Since then two non-ACME CAs have implemented ACME integrations using the external account binding feature but not implementing OOB challenges. Since the target demographic has not implemented this feature and has also not presented a use-case requiring it there seems to be no strong reasons to keep it in-spec.
NAME If you could update this to remove the OOB challenge from the , I'll go ahead and merge
NAME Good catch - thanks! Addressed in 0753c73.

Discussion:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <del> 8.6. 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".  Note that this field is distinct from the "url" field of the challenge, which identifies the challenge itself. A client responds to this challenge by presenting the indicated URL for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to validate identifier possession are determined by the server's local policy. </del> 9. 9.1.

CAs using ACME to allow clients to agree to terms of service should keep in mind that ACME clients can automate this agreement, possibly <del> not involving a human user.  If a CA wishes to have stronger evidence of user consent, it may present an out-of-band requirement or challenge to require human involvement. </del> <ins> not involving a human user. </ins> 11.
Change:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:

Discussion:
ACME Resource Types (iana-resource) <ins> ACME Directory Metadata Fields (iana-meta) </ins> ACME Identifier Types (iana-identifier) ACME Validation Methods (iana-validation)

Initial contents: The fields and descriptions defined in account- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.2. This registry lists field names that are defined for use in ACME

Initial contents: The fields and descriptions defined in order- objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.3. This registry lists field names that are defined for use in ACME

Initial contents: The fields and descriptions defined in authorization-objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.4. This registry lists values that are used within URN values that are

9.7.6. <ins> This registry lists field names that are defined for use in the JSON object included in the "meta" field of an ACME directory object. Template: Field name: The string to be used as a field name in the JSON object Field type: The type of value to be provided, e.g., string, boolean, array of string Reference: Where this field is defined Initial contents: The fields and descriptions defined in account- objects. [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] 9.7.7. </ins> This registry lists the types of identifiers that can be present in ACME authorization objects.

[[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] <del> 9.7.7. </del> <ins> 9.7.8. </ins> This registry lists identifiers for the ways that CAs can validate control of identifiers.  Each method's entry must specify whether it
Change:
The idea here is that if the CA opts not to log the precertificates it has a mechanism for publishing the proofs that are associated with a cert.
There are two good mechanisms to do this without adding a new endpoint: The CA implementing ACME can include SCTs in its OCSP responses Subscribers that wish to use SCTs, for instance in the TLS Extension mode of operation, may fetch those SCTs directly from the CT logs.
Neither of these seem like great substitutes. The first seems to violate straightforward reference semantics. The second puts a lot more work on the server.
I think this can be easily solved with a .

Discussion:
In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate <del> the registration under which this certicate was issued.  The server MAY also include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del> <ins> the registration under which this certicate was issued. The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) If the CA particpates 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 a 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". </ins> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA
Change:
Rewrite "in challenge", which seems to be incorrect to "of the order"
Good catch! Thank you NAME :eagle: :mag:

Discussion:
array after they are created.  If a client observes a change in the contents of either array, then it SHOULD consider the order invalid. <del> The "authorizations" array in the challenge SHOULD reflect all </del> <ins> The "authorizations" array of the order SHOULD reflect all </ins> authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions.  For example, if a CA allows multiple
Change:
Prior to this commit the IDN prefix referenced from RFC5890 was being turned from to . This commit escapes the two dashes so they remain in the generated doc. Thanks to NAME for reporting! Resolves URL
In https://ietf-wg-URL This should be:
Opened URL with a fix. Thanks!

Discussion:
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 <del> 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 objects. </del> <ins> 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 objects. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.
Change:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.

Discussion:
"alg" (Algorithm) <del> "jwk" (JSON Web Key, only for requests to new-account and revoke-cert resources) </del> <ins> "jwk" (JSON Web Key, for all requests not signed using an existing account, e.g. newAccount) </ins> <del> "kid" (Key ID, for all other requests) </del> <ins> "kid" (Key ID, for all requests signed using an existing account) </ins> "nonce" (defined in replay-protection below)

The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. <del> For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </del> <ins> For newAccount requests, and for revokeCert requests authenticated by certificate key, there MUST be a "jwk" field.  This field MUST contain the public key corresponding to the private key used to sign the JWS. </ins> <del> For all other requests, there MUST be a "kid" field.  This field must contain the account URL received by POSTing to the new-account resource. </del> <ins> For all other requests, the request is signed using an existing account and there MUST be a "kid" field.  This field MUST contain the account URL received by POSTing to the newAccount resource. </ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET

7.6. To request that a certificate be revoked, the client sends a POST <del> request to the ACME server's revoke-cert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </del> <ins> request to the ACME server's revokeCert URL.  The body of the POST is a JWS object whose JSON payload contains the certificate to be </ins> revoked: The certificate to be revoked, in the base64url-encoded version of

Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in <del> the certificate.  Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate.  The server MUST consider at least the following accounts authorized for a given certificate: </del> <ins> the certificate. Example using an account key pair for the signature: Example using the certificate key pair for the signature: Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server MUST consider at least the following accounts authorized for a given certificate: </ins> the account that issued the certificate.
Change:
As recommended by . Thanks to for the catch.
NAME I believe you need write, admin, or owner permissions on the repo for a "changes requested" review to show up this way in the GH UI.
(Merging myself because it's the real author is NAME I'm just the scribe)
Could you please change the spelling? (Why won't I get a "Changes requested" with red marker?) Hello, https://ietf-wg-URL states: If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs. Yet URL says the opposite: the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. Could this be reworded somehow? It would make sense to store `0' in a database but later don't add a CRLReason extension / ASN.1 field. Cheers, Jörn

Discussion:
One of the revocation reasonCodes defined in Section 5.3.1 of RFC5280 to be used when generating OCSP responses and CRLs.  If <del> this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The </del> <ins> this field is not set the server SHOULD omit the reasonCode CRL entry extension when generating OCSP responses and CRLs.  The </ins> server MAY disallow a subset of reasonCodes from being used by the user.  If a request contains a disallowed reasonCode the server MUST reject it with the error type
Change:
Section 6.2 "Request Authentication" says: Prior to this commit Section 7.3 "Account Creation" doesn't mention that the account URL also doubles as the key ID. To make the question of "What is my Key ID?" more obvious for client implementers this commit adds a brief mention of this fact where the specification discusses the account URL. Thanks to NAME for flagging this and providing a chance to avoid confusion and add clarity.
thanks

Discussion:
verify the JWS (i.e., the "jwk" element of the JWS header) to authenticate future requests from the account.  The server returns this account object in a 201 (Created) response, with the account URL <del> in a Location header field. </del> <ins> in a Location header field.  The account URL is used as the "kid" value in the JWS authenticating subsequent requests by this account (See request-authentication). </ins> 7.3.1.
Change:
As suggested by Felipe Gasper
NAME fixed. Note, also standardized on "validation method" (vs. "mechanism"). Hello, I’ve been looking over the -09 draft and have created a Perl client module against Pebble as well as LE’s new testing endpoint. I’m curious about whether the specification intends to define Challenge objects. They appear to exist, of course, but they’re not defined as objects per se in section 7.1 of the draft. Thank you! -Felipe Gasper Mississauga, ON

Discussion:
identifier-validation-challenges describes a set of challenges for domain name validation. <ins> 7.1.5. An ACME challenge object represents a server's offer to validate a client's possession of an identifier in a specific way.  Unlike the other objects listed above, there is not a single standard structure for a challenge object.  The contents of a challenge object depend on the validation method being used.  The general structure of challenge objects and an initial set of validation methods are described in identifier-validation-challenges. </ins> 7.2. Before sending a POST request to the server, an ACME client needs to

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 <del> different validation mechanisms. </del> <ins> different validation methods. </ins> 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
Change:
Section "Request Authentication" already forbade it.
In general, we have not been making MUST-level requirements for servers in this document because CAs are subject to a lot of external constraints already. Under that theory, I would say we should just close this. NAME NAME wdyt?
If you don't want this change, can you change "Servers MUST NOT respond to GET requests for resources that might be considered sensitive. Account resources are the only sensitive resources defined in this specification." instead to resolve the inconsistency?
NAME I agree with NAME - this isn't a new MUST-level requirement, it's already said elsewhere that the server MUST NOT respond to sensitive resources and the account object has contact information you wouldn't want returned to an unauthenticated GET request. It seems fine to emphasize this in the account information section.
I'm going to merge this. NAME gives an OOB +1. Thanks NAME !

Discussion:
7.3.3. <del> Servers SHOULD NOT respond to GET requests for account resources as </del> <ins> Servers MUST NOT respond to GET requests for account resources as </ins> these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the "contact" or "orders" fields), then it SHOULD do so by sending a POST
Change:
Merging because editorial.
account binding feature (see {{external-account-binding}}) can be used to associate authorizations with an account that were not validated through the ACME authorization process. To me (non-native English speaker) "were not" refers to "an account" which would be a grammar mistake. If it refers to "authorizations" would it be better to switch "authorizations" and "an account"?
I think it is technically correct (it does refer to "authorizations"), but I agree it's an awkward sentence. Filed to address.

Discussion:
ACME can also be used to automate some aspects of certificate management even where non-automated processes are still needed.  For example, the external account binding feature (see external-account- <del> binding) can be used to associate authorizations with an account that were not validated through the ACME authorization process.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </del> <ins> binding) can allow an ACME account to use authorizations that have been granted to an external, non-ACME account.  This allows ACME to address issuance scenarios that cannot yet be fully automated, such as the issuance of Extended Validation certificates. </ins> 2.