jiebi/CodeConvo huggingface dataset:
Change:
awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.

Discussion:
The server provides the following fields as part of the challenge: <del> The string "proofOfPossession-01" </del> <ins> The string "proof-of-possession-01" </ins> An array of certificates, in Base64url-encoded DER format, that contain acceptable public keys.

object including data related to the challenge.  The validation object covered by the signature has the following fields: <del> The string "proofOfPossession" </del> <ins> The string "proof-of-possession" </ins> A list of identifiers for which the holder of the prior key authorizes the new key

with a signature over that nonce by one of the private keys requested by the server. <del> The string "proofOfPossession" </del> <ins> The string "proof-of-possession" </ins> The validation JWS

Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object, <del> and that: * The "type" field is set to "proofOfPossession" * The </del> <ins> and that: * The "type" field is set to "proof-of-possession" * The </ins> "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued
Change:
The current wording ("root URL") may lead readers to believe that the ACME directory URI's path is "/", whereas it could actually be anything. Reword to "only URL" and provide examples which emphasize that the choice of the URL for the dictionary object is arbitrary.

Discussion:
In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This <del> should be the root URL with which clients are configured.  It is a JSON dictionary, whose keys are the "resource" values listed in https-requests, and whose values are the URIs used to accomplish the </del> <ins> should be the only URL needed to configure clients.  It is a JSON dictionary, whose keys are the "resource" values listed in https- requests, and whose values are the URIs used to accomplish the </ins> corresponding function. <ins> There is no constraint on the actual URI of the directory except that it should be different from the other ACME server resources' URIs, and that it should not clash with other services.  For instance: a host which function as both an ACME and Web server may want to keep the root path "/" for an HTML "front page", and and place the ACME directory under path "/acme". a host which only functions as an ACME server could place the directory under path "/". </ins> Clients access the directory by sending a GET request to the directory URI.
Change:
Also fixes some RFC3339 timestamps shown in examples, which must include seconds.
Authorization expiry should be a timestamp not a date, to allow for authorizations with very short expiry times. All discussion should be done on the mailing list.

Discussion:
"pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending". <del> The date after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </del> <ins> The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </ins> The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For
Change:
I approve of this change.
This looks good to me. I would like to tighten up the language a bit to clarify that this applies to validation of DNS identifiers, but will do that in a follow-on PR.

Discussion:
validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: <del> Checking the DNSSEC status of DNS records used in ACME validation (for zones that are DNSSEC-enabled) </del> <ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled) </ins> Querying the DNS from multiple vantage points to address local attackers

the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). <ins> 10.2. An ACME-based CA needs to make DNS lookups when processing challenges.  Because the security of an ACME-based CA ultimately depends entirely on the authenticity of DNS data, every possible precaution should be taken to secure such lookups.  It is therefore RECOMMENDED that ACME-based CAs make all DNS resolutions via DNSSEC- validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for all CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </ins> 11.  References 11.1.  URIs
Change:
This replaces tls-sni-01 with tls-sni-02, which requires that domains being validated return a certificate which contains a hostname that is not revealed by the server in its handshake. This ensures that challenges cannot be passed by domains which auto-generate self-signed certificates in response to requests with SANs for domains not previously seen.

Discussion:
half. The client MUST ensure that the certificate is served to TLS <del> connections specifying a Server Name Indication (SNI) value of SAN B. </del> <ins> connections specifying a Server Name Indication (SNI) value of SAN A. </ins> The response to the TLS-SNI challenge simply acknowledges that the client is ready to fulfill this challenge.

Compute SAN A and SAN B in the same way as the client. Open a TLS connection to the domain name being validated on the <del> requested port, presenting SAN B in the SNI field. </del> <ins> requested port, presenting SAN A in the SNI field. </ins> The server MUST request the certificate using an SNI value of SAN <del> B. </del> <ins> A. </ins> <del> The server SHOULD ensure that it does not reveal SAN A in any way </del> <ins> The server SHOULD ensure that it does not reveal SAN B in any way </ins> when making the TLS connection, such that the presentation of SAN <del> A in the returned certificate proves association with the client. </del> <ins> 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:
I've noticed that boulder uses DNS over TCP. I suppose this has not been an arbitrary choice, but something that would be useful to document.
As an FYI, Boulder currently uses TCP for DNS to its local authoritative resolver, but the resolver uses UDP. We tried making the resolver do upstream resolution with TCP but got a large number of failures.

Discussion:
There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when <del> configuring their services. </del> <ins> configuring their services.  For example: It is advisable to perform DNS queries via TCP to mitigate DNS forgery attacks over UDP </ins> [[ TODO: Other operational considerations ]]
Change:
This looks fine to me, and consistent with the list discussions. (I have a couple of minor issues, which I filed as .) I am merging this in preference to , which got negative feedback on the list.
The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.

Discussion:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA <del> records, at its discretion.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS. </del> <ins> records.  Because many webservers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non- intuitive manner, the challenge must be completed over HTTP, not HTTPS. </ins> The string "http-01"

The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. <ins> In addition, the client MAY advise the server at which IP the challenge is provisioned: An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then

Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del> <ins> If the client has supplied an address to use, verify that the address is included in the A or AAAA records to which the domain name resolves.  If the address is not included in the result, the validation fails. Dereference the URI using an HTTP GET request.  If an address was supplied by the client, use that address to establish the HTTP connection. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at
Change:
These fields are not required by draft-ietf-appsawg-http-problem-03.

Discussion:
When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- <del> problem.  The "type" and "detail" fields MUST be populated.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </del> <ins> problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): </ins> This list is not exhaustive.  The server MAY return errors whose "type" field is set to a URI other than those defined above.  Servers
Change:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)

Discussion:
ACME messaging is based on HTTPS RFC2818 and JSON RFC7159. <del> Binary fields are encoded using Base64url encoding described in </del> <ins> Binary fields are encoded using base64url encoding described in </ins> RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped.

is a JWS object whose JSON payload contains the certificate to be revoked: <del> The certificate to be revoked, in the Base64url-encoded version of </del> <ins> The certificate to be revoked, in the base64url-encoded version of </ins> the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.)

parameters N and E, in order to avoid ambiguity with regard to the sign of the number.  As noted in JWA RFC7518, a JWK object MUST NOT include this zero octet.  That is, any initial zero octets MUST be <del> stripped before the values are Base64url-encoded. </del> <ins> stripped before the values are base64url-encoded. </ins> 7.2.

A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del> <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name

The string "proof-of-possession-01" <del> An array of certificates, in Base64url-encoded DER format, that </del> <ins> An array of certificates, in base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key

A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet. </del> <ins> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and
Change:
Since the rest of the spec and protocol makes extensive use of JSON, when I was reading the spec the first time, I didn't know if the link relations were supposed to be JSON link relations like HAL or LinkedData. The spec mentions "link relation" 6 times, but only one of them (the 2nd-to-last) makes explicit reference to RFC 5988 for web linking via HTTP header.

Discussion:
ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI, <del> so clients only need to be configured with the directory URI. </del> <ins> so clients only need to be configured with the directory URI.  These URIs are connected by a few different link relations RFC5988. </ins> The "up" link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs.  It is also
Change:
I'm not sure if this is the correct place for issues with the actual server, but https://acme-URL is returning me an error message of When accessed from several machines.
No, this isn't the right place. Contact LetsEncrypt directly. This is for discussing the IETF protocol.
https://ietf-wg-URL does not detail what status code should be returned. I assume it should be a 202, in line with Registration update, but it needs specifying IMO.

Discussion:
by replacing the old account key with the public key carried in the "jwk" header parameter of the "newKey" JWS object. <ins> If the update was successful, then the server sends a response with status code 200 (OK) and the updated registration object as its body. If the update was not successful, then the server responds with an error status code and a problem document describing the error. </ins> 6.5. Once a client has created an account with an ACME server, it is
Change:
Proposes 201/Location: operation optional for /requestauditlog end-point.
Think we should discuss.

Discussion:
Registrar. This is done with an HTTPS POST using the operation path value of <del> "/requestvoucher". </del> <ins> "/.well-known/est/requestvoucher". </ins> The request media types are:

requirement that holds for any REST interface). This is done with an HTTP POST using the operation path value of <del> "/requestvoucher". </del> <ins> "/.well-known/est/requestvoucher". </ins> The request media type is:

in the log. This is done with an HTTP GET using the operation path value of <del> "/requestauditlog". </del> <ins> "/.well-known/est/requestauditlog". </ins> The Registrar MUST HTTP POSTs the same Registrar voucher-request as it did when requesting a Voucher.  It is posted to the

request with the original, and by now already validated, Registrar voucher-request so as to avoid an extra crypto validation. <ins> Rather than returning the audit log as a response to the POST (with a return code 200), the MASA MAY instead return a 201 ("Created") RESTful response (RFC7231 section 7.1) containing a URL to the prepared (and easily cachable) audit response. MASA servers that return URLs SHOULD take care to make the returned URL unguessable.  URLs containing a database number such as https://example.com/auditlog/1234 or the EUI of the device such https://example.com/auditlog/10-00-00-11-22-33, would be easily enumerable by an attacker.  It is recommended put to put some meaningless randomly generated slug that indexes a database instead. A MASA that returns a code 200 MAY also include a Location: header for future reference by the Registrar. </ins> The request media type is: The request is a "YANG-defined JSON document that has been signed
Change:
Adds text to include SNI in BRSKI-MASA handshake.
I like the first diff (expanding the client authentication discussion into a paragraph). I don't see the need for RFC6066 SNI reference. But since it is a "SHOULD" don't have a technical complaint.

Discussion:
The primary method of Registrar "authentication" by the MASA is detailed in RequestVoucherFromMASA.  As detailed in securityconsiderations the MASA might find it necessary to request <del> additional Registrar authentication.  Registrars MUST be prepared to support TLS client certificate authentication and HTTP Basic or Digest authentication as described in RFC7030 for EST clients. </del> <ins> additional Registrar authentication. The Registrar is the client in the BRSKI-MASA connection.  When operating as such, the Registrars MUST be prepared to support TLS client certificate authentication.  The registrar should also be configurable to support HTTP Basic or Digest authentication as described in RFC7030 for EST clients: provision of such credentials of outside the scope of this document and would be part of a supply- chain integration process. </ins> Implementors are advised that contacting the MASA is to establish a secured REST connection with a web service and that there are a number of authentication models being explored within the industry.

administrative notifications or logs in the advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. <ins> In order to support multi-tenant MASA implementations the Registrar SHOULD include the RFC6066 Server Name Indicator. </ins> 5.4. When a Registrar receives a Pledge voucher-request it in turn submits
Change:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.

Discussion:
6. <ins> The following modules extends the RFC8995 Voucher Request to include a signed artifact from the registrar agent. 7. </ins> This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap-

underlying TLS using OSCORE resulting in an authenticated self- contained object. <del> 6.1. </del> <ins> 7.1. </ins> When using EST RFC7030, the following constraints should be considered:

[RFC Editor: please delete] /* TBD: clarification of retry for fullcmc is necessary as not specified in the context of EST */ <del> 6.2. </del> <ins> 7.2. </ins> Instead of using CMP RFC4210, this specification refers to the lightweight CMP profile I-D.ietf-lamps-lightweight-cmp-profile, as it

as specified in section 5.2.4 of I-D.ietf-lamps-lightweight-cmp- profile with delayed enrollment. <del> 7. </del> <ins> 8. </ins> This document requires the following IANA actions:

included for the defined namespaces in addressing and discovery_eo . */ <del> 8. </del> <ins> 9. </ins> The credential used by the registrar-agent to sign the data for the pledge in case of the pledge-initiator-mode should not contain

technician operating the device, to avoid revealing this information to the MASA. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> Exhaustion attack on pledge based on DoS attack (connection establishment, etc.) <del> 9.2. </del> <ins> 10.2. </ins> Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request

IDevID.  Alternatively, the LDevID may be acquired by a service technician after authentication against the issuing CA. <del> 10. </del> <ins> 11. </ins> We would like to thank the various reviewers for their input, in particular Brian E.  Carpenter, Michael Richardson, Giorgio