jiebi/CodeConvo huggingface dataset:
Code change:
This uses two JWS signatures to achieve the two-signature property during rollover, instead of using extra layers of encoding and embedding. It also simplifies the logic and splits it out into its own resource.

Related discussion:
text: A "revoke-certificate" resource <ins> A "key-change" resource </ins> 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.
Code change:
what's the difference between "deactivated" and "revoked"?
Deactivated is done by the user; revoked is done by an administrator.
OK, so we need to either say that or use clearer terms :) I talked with NAME offline, and I think he's going to propose something.

Related discussion:
text: The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <del> "valid" or "deactivated" </del> <ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may
Code change:
Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL

Related discussion:
text: Fulfill the server's requirements for issuance <del> Finalize the application and request issuance </del> <ins> Await issuance and download the issued certificate </ins> The client's application for a certificate describes the desired certificate using a PKCS#10 Certificate Signing Request (CSR) plus a
Code change:
Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL

Related discussion:
text: the client has accomplished the challenge. Once the validation process is complete and the server is satisfied <del> that the client has met its requirements, the server can either proactively issue the requested certificate or wait for the client to request that the application be "finalized", at which point the certificate will be issued and provided to the client. </del> <ins> that the client has met its requirements, the server will issue the requested certificate and make it available to the client. </ins> To revoke a certificate, the client simply sends a revocation request indicating the certificate to be revoked, signed with an authorized
Code change:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Related discussion:
text: "alg" <del> "jwk" (only for requests to new-reg and revoke-cert resources) </del> <ins> "jwk" (only for requests to new-account and revoke-cert resources) </ins> "kid" (for all other requests).
Code change:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Related discussion:
text: The "jwk" and "kid" fields are mutually exclusive.  Servers MUST reject requests that contain both. <del> For new-reg requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </del> <ins> For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. </ins> For all other requests, there MUST be a "kid" field.  This field must <del> contain the account URI received by POSTing to the new-reg resource. </del> <ins> contain the account URI received by POSTing to the new-account resource. </ins> Note that authentication via signed JWS request bodies implies that GET requests are not authenticated.  Servers MUST NOT respond to GET
Code change:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Related discussion:
text: The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" <del> field of the request before updating the registration. </del> <ins> field of the request before updating the account object. </ins> For example, to update the contact information in the above account, the client could send the following request:
Code change:
In the term "registration" was changed to "account". In and in some of the remaining references to "registration" were removed, but some 'new-reg' and references to "registration" remained. This PR removes, hopefully, the last references to "registration".

Related discussion:
text: the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If <del> any of these checks fail, then the CA MUST reject the new- registration request. </del> <ins> any of these checks fail, then the CA MUST reject the new-account request. </ins> 6.3.3.
Code change:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Related discussion:
text: supported scheme but an invalid value then the server MUST return an error of type "invalidContact". <ins> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true".  Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. </ins> The server creates an account and stores the public key used to 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 in a Location header field. <ins> 7.3.1. </ins> If the server already has an account registered with the provided account key, then it MUST return a response with a 200 (OK) status code and provide the URL of that account in the Location header field.  This allows a client that has an account key but not the <del> corresponding account URI to recover the account URL. </del> <ins> corresponding account URL to recover the account URL. </ins> <del> If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true".  Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. </del> <ins> If a client wishes to recover an existing account and does not want a non existing account to be created, then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). 7.3.2. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the account URL. The server MUST ignore any updates to "order" fields or any other <del> fields it does not recognize. </del> <ins> fields it does not recognize.  If the server accepts the update, it MUST return a response with a 200 (OK) status code and the resulting account object. </ins> For example, to update the contact information in the above account, the client could send the following request: <ins> 7.3.3. </ins> Servers SHOULD NOT respond to GET requests for account 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
Code change:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Related discussion:
text: a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). <del> 7.3.1. </del> <ins> 7.3.4. </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
Code change:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Related discussion:
text: human user to visit in order for instructions on how to agree to the terms. <del> 7.3.2. </del> <ins> 7.3.5. </ins> The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an
Code change:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Related discussion:
text: any of these checks fail, then the CA MUST reject the new-account request. <del> 7.3.3. </del> <ins> 7.3.6. </ins> A client may wish to change the public key that is associated with an account in order to recover from a key compromise or proactively
Code change:
This PR is a first go at addressing the following points I raised on the mailing list.
This allows us to address the account URL recovery use case in without having special handling for empty payloads.

Related discussion:
text: responds with an error status code and a problem document describing the error. <del> 7.3.4. </del> <ins> 7.3.7. </ins> A client can deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do
Code change:
This change replaces "shortly" in the normative language of Section 7.4, Applying for Certificate Issuance, with the more precise expectation that the server begin the issuance process, as discussed on the mailing list. URL We could say "MUST begin the issuance process" The main things on my mind that could delay issuance slightly: Submitting to CT Checking CAA Internal queuing for available capacity Manual vetting I think "MUST begin" covers for all of those, while allowing some vagueness as to how long they will take. On 03/22/2017 09:39 AM, Daniel McCarney wrote:

Related discussion:
text: then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. <del> The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </del> <ins> The server MUST begin the issuance process for the requested certificate and update the order resource with a URL for the certificate once the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its
Code change:
Is 200 really correct? This seems like a 404 maybe? Also we should specify the body (empty).
Would a problem document be appropriate (with either a pre-existing ACME error type or a new one like "accountDoesNotExist")?
404 talks about the effective request URI, so that's not going to work. I think that a 400 would be better on the basis that the request checked, but failed (NAME suggestion is a fine enhancement). The reason you make this request is to check; and having a 4xx series code is easier to test than the absence of a header field.
Thanks NAME and NAME implemented this in the latest commit.
As discussed; this is fine.

Related discussion:
text: not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true" <del> ({"only-return-existing": true}). </del> <ins> ({"only-return-existing": true}).  If a client sends such a request and an account does not exist, then the server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:accountDoesNotExist". </ins> 7.3.2.
Code change:
It makes sense to cancel any pending cert orders when an account is deactivated, where the cert has not been issued yet.

Related discussion:
text: (OK) status code and the current contents of the account object. Once an account is deactivated, the server MUST NOT accept further <del> requests authorized by that account's key.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </del> <ins> requests authorized by that account's key.  The server SHOULD cancel any pending operations authorized by the account's key, such as certificate orders.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </ins> 7.4.
Code change:
Previously there was some notion of being able to hint to the server whether you wanted to reuse authorizations. This was removed from the spec but the pre-authorization flow still made a reference to it. This commit removes that obsolete reference. Thanks to NAME for pointing out the error. Resolves URL
Hi in the section on pre-authz there is this sentence: To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. the part "and how the server should behave with respect to existing authorizations for this identifier" probably is obsoleted
Hi NAME I submitted URL to fix this. Thanks for spotting & reporting :-)

Related discussion:
text: To request authorization for an identifier, the client sends a POST request to the new-authorization resource specifying the identifier <del> for which authorization is being requested and how the server should behave with respect to existing authorizations for this identifier. </del> <ins> for which authorization is being requested. </ins> The identifier that the account is authorized to represent:
Code change:
I think without OOB all challenges use key-authorization "JWA" is not defined in this document. I think it can just be omitted
NAME Thank you for the change! :smile:
Thanks again NAME I really appreciate your editing & the accompanying PRs! :-)

Related discussion:
text: 8.1. <del> Several of the challenges in this document make use of a key </del> <ins> All challenges defined in this document make use of a key </ins> authorization string.  A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in <del> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in JWA RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </del> <ins> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </ins> As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-
Code change:
Prior to this commit the literal string "." was being rendered as the start of italics in the generated HTML doc. This commit updates the markup to escape the "*."` in the generated document. Originally reported by Joel Sing - thanks!

Related discussion:
text: Any identifier of type "dns" in a new-order request MAY have a wildcard domain name as its value.  A wildcard domain name consists of a single asterisk character followed by a single full stop <del> character ("_.") followed by a domain name as defined for use in the Subject Alternate Name Extension by RFC 5280 . An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("_RFC5280.") prefix in the authorization identifier value. </del> <ins> character ("*.") followed by a domain name as defined for use in the 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 in the authorization identifier value. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents either