jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-acme-acme

Commentary: Thanks - diff looks fine to me . Looks fine to mepurely editorial , good for me .
Paragraph (version A):
DV certificate validation commonly checks claims about properties
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
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.
Paragraph (version B):
DV certificate validation commonly checks claims about properties
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
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.
Draft: draft-ietf-acme-acme

Commentary: Including reconciliation to XML , and updated comments to RFC editor . 
 Thanks
Paragraph (version A):
Download the issued certificate and install it on their Web
Server.
Paragraph (version B):
Download the issued certificate and install it on the user's Web
Server.
Paragraph (version A):
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).
Paragraph (version B):
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).
Draft: draft-ietf-acme-acme

Commentary: This is ( hopefully ) the final reconciliation between the XML generated from the Markdown source and XML provided by the RFC Editor . will be provided to the authors for final review , and then to the RFC editor . 
 Merging myself because this is just technical transformations of the source .
Paragraph (version A):
DV certificate validation commonly checks claims about properties
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
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.
Paragraph (version B):
DV certificate validation commonly checks claims about properties
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
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.
Draft: draft-ietf-acme-acme

Commentary: " newAuthorization " -"newAuthz " Reverted the indentation on the IANA considerations since that resulted in the wrong XML
Paragraph (version A):
Authorization resources are created by the server in response to
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.
Paragraph (version B):
Authorization resources are created by the server in response to
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.
Draft: draft-ietf-acme-acme

Commentary: 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 
 Thanks - this clarification makes sense to me . I 'm +1 to applying your diff with the other AUTH48 changes . cc Not really just editorial , but okay .
Paragraph (version B):
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).
Draft: draft-ietf-acme-acme

Commentary: From Section 7.3 : " MUST account bodies sent by the 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 " is n'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 is n't purely editorial , but okay .
Paragraph (version B):
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).
Paragraph (version A):
An optional field for binding the new account with an existing
non-ACME account (see external-account-binding ).
Paragraph (version A):
The server MUST ignore any values provided in the "orders" fields in
account bodies sent by the client, as well as any other fields that
it does not recognize.  If new fields are specified in the future,
the specification of those fields MUST describe whether they can be
provided by the client.
Paragraph (version A):
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.
Paragraph (version B):
The server MUST ignore any values provided in the "orders" fields in
account objects sent by the client, as well as any other fields that
it does not recognize.  If new fields are specified in the future,
the specification of those fields MUST describe whether they can be
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.
Draft: draft-ietf-acme-acme

Commentary: Thanks to Felipe Gasper for . 
 Merging despite spurious CI failure , since it seems pretty clear that the CI failure is spurious .
Paragraph (version A):
An ACME client MAY attempt to fetch the certificate with a GET
request.  If the server does not allow GET requests for certificate
resources, then it will return an error as described in post-as-get.
On receiving such an error, the client SHOULD fall back to a POST-as-
GET request.
Draft: draft-ietf-acme-acme

Commentary: Change " applicaiton " to " application " 
 With any luck we 'll have to catch this in the RFC editor queue ; hopefully there wo n't be another draft . 
 Thanks
Paragraph (version A):
The ACME client MAY request other formats by including an Accept
header field RFC7231 in its request.  For example, the client could
use the media type "application/pkix-cert" RFC2585 or "applicaiton/
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
provide one or more "Link: rel="up"" header fields pointing to an
issuer or issuers so that ACME clients can build a certificate chain
as defined in TLS RFC8446.
Paragraph (version B):
The ACME client MAY request other formats by including an Accept
header field RFC7231 in its request.  For example, the client could
use the media type "application/pkix-cert" RFC2585 or "application/
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
provide one or more "Link: rel="up"" header fields pointing to an
issuer or issuers so that ACME clients can build a certificate chain
as defined in TLS RFC8446.
Paragraph (version A):
When processing an file of type "application/pem-certificate-chain",
a client SHOULD verify that the file contains only encoded
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.
Paragraph (version B):
When processing a file of type "application/pem-certificate-chain", a
client SHOULD verify that the file contains only encoded
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.
Draft: draft-ietf-acme-acme

Commentary: 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 This looks fine to me .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Draft: draft-ietf-acme-acme

Commentary: The definition for " meta " fields accidentally pointed to the section on account objects . 
 Thanks
Paragraph (version A):
Initial contents: The fields and descriptions defined in account-
objects.
Paragraph (version B):
Initial contents: The fields and descriptions defined in directory.
Draft: draft-ietf-acme-acme

Commentary: This exception does n't actually improve interop for STAR clients , and it introduces complexity into the security analysis of ACME . STAR can easily solve the problem by defining a new field on orders that provides an explicitly GETtable URL , with whatever security properties the STAR project needs . 
 Do not merge this without discussion on the mailing list . 
 Merging based on out - of - band approval from
Paragraph (version A):
The server MAY allow GET requests for certificate resources in order
to allow certificates to be fetched by a lower-privileged process,
e.g., the web server that will use the referenced certificate chain.
(See I-D.ietf-acme-star for more advanced cases.)  A server that
allows GET requests for certificate resources can still provide a
degree of access control by assigning them capability URLs W3C.WD-
capability-urls-20140218.  As above, if the server does not allow GET
requests for a given resource, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformed".
Draft: draft-ietf-acme-acme

Commentary: suggested by   , change the certificate fetch examples to use POST - as - GET , noting that GET is optional suggested by   , use the correct error code for " malformed " in the description of what servers should do in response to inappropriate GET requests 
 Since does n't look like it will be merged anytime soon , would it be possible to move the editorial ( undisputed ) stuff ( trailing comma , authz -challenge in URL ) into this PR ? 
 I think I 've gotten all the trailing commas and errant headersgit di . 
 Looks good to me ! 
 editorial clarifications , looks good to me .
Paragraph (version A):
Note that authentication via signed JWS request bodies implies that
requests without an entity body are not authenticated, in particular
GET requests.  Except for the cases described in this section, if the
server receives a GET request, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformedRequest".
Paragraph (version B):
Note that authentication via signed JWS request bodies implies that
requests without an entity body are not authenticated, in particular
GET requests.  Except for the cases described in this section, if the
server receives a GET request, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformed".
Paragraph (version A):
The server MAY allow GET requests for certificate resources in order
to allow certificates to be fetched by a lower-privileged process,
e.g., the web server that will use the referenced certificate chain.
(See I-D.ietf-acme-star for more advanced cases.)  A server that
allows GET requests for certificate resources can still provide a
degree of access control by assigning them capability URLs W3C.WD-
capability-urls-20140218.  As above, if the server does not allow GET
requests for a given resource, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformedRequest".
Paragraph (version B):
The server MAY allow GET requests for certificate resources in order
to allow certificates to be fetched by a lower-privileged process,
e.g., the web server that will use the referenced certificate chain.
(See I-D.ietf-acme-star for more advanced cases.)  A server that
allows GET requests for certificate resources can still provide a
degree of access control by assigning them capability URLs W3C.WD-
capability-urls-20140218.  As above, if the server does not allow GET
requests for a given resource, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformed".
Paragraph (version B):
An ACME client MAY attempt to fetch the certificate with a GET
request.  If the server does not allow GET requests for certificate
resources, then it will return an error as described in post-as-get.
On receiving such an error, the client SHOULD fall back to a POST-as-
GET request.
Draft: draft-ietf-acme-acme

Commentary: In addition to forbidding explanatory text , this PR restricts the PEM - certificate - chain structure to the " strict " production defined in RFC 7468 , Figure 3 . 
 s / Figure 3 of RFC 7468 / Section 3 of RFC 7468/
Paragraph (version A):
A file of this type contains one or more certificates encoded with
the PEM textual encoding, according to RFC 7468 RFC7468.  In order to
provide easy interoperation with TLS, the first certificate MUST be
an end-entity certificate.  Each following certificate SHOULD
directly certify the one preceding it.  Because certificate
validation requires that trust anchors be distributed independently,
a certificate that represents a trust anchor MAY be omitted from the
chain, provided that supported peers are known to possess any omitted
certificates.
Paragraph (version B):
In order to provide easy interoperation with TLS, the first
certificate MUST be an end-entity certificate.  Each following
certificate SHOULD directly certify the one preceding it.  Because
certificate validation requires that trust anchors be distributed
independently, a certificate that represents a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.
Draft: draft-ietf-acme-acme

Commentary: Merging as editorial
Paragraph (version A):
All requests and responses sent via HTTP by ACME clients, ACME
servers, and validation servers as well as any inputs for digest
computations MUST be encoded using the UTF-8 RFC3629 character set.
Paragraph (version B):
All requests and responses sent via HTTP by ACME clients, ACME
servers, and validation servers as well as any inputs for digest
computations MUST be encoded using the UTF-8 RFC3629 character set.
Note that identifiers that appear in certificates may have their own
encoding considerations (e.g., DNS names containing non-ASCII
characters are expressed as A-labels rather than U-labels).  Any such
encoding considerations are to be applied prior to the aforementioned
UTF-8 encoding.
Draft: draft-ietf-acme-acme

Commentary: EKR pointed out to me privately a couple of remaining issues after his AD review . This PR addresses those issues . 
 No complaints from me , looks good . Thanks
Paragraph (version A):
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" (see errors).  The
problem document returned with the error MUST include an "algorithms"
field with an array of supported "alg" values.
Paragraph (version B):
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.  See errors for more details
on the structure of error responses.
Paragraph (version A):
All of the challenges above have a binding between the account
private key and the validation query made by the server, via the key
authorization.  The key authorization reflects the account public
key, is provided to the server in the validation response over the
validation channel and signed afterwards by the corresponding private
key in the challenge response over the ACME channel.
Paragraph (version B):
All of the challenges defined in this document have a binding between
the account private key and the validation query made by the server,
via the key authorization.  The key authorization reflects the
account public key, is provided to the server in the validation
response over the validation channel and signed afterwards by the
corresponding private key in the challenge response over the ACME
channel.
Draft: draft-ietf-acme-acme

Commentary: This definitely needs to be reviewed . 
 This looks good to me . 
 I like the idea of a special compound error type to indicate that the subproblems field is used . 
 In s7.6 , it seems like we should indicate what error is returned : If the revocation fails , the server returns an error . The draft this nicely in many others places in the draft . 
 I mentioned this earlier on the mailing list , but it did not receive any feedback : as a ACME client developer , I would like to be able to distinguish between errors which do not require user interaction ( that would be " certificate is already revoked , so ca n't revoke it again " ) , and ones where the user must be warned that the operation did not succeed ( " certificate could not be revoked " , " bad credentials " , etc . ) . This is currently only possible with server - specific ugly hacks ( for example , returns this information , but other servers might return it differently or this might change in later versions of Boulder as it is not specified ) . 
 This is a good idea , sorry for missing it earlier . - Do you have any thoughts on other cases besides " already revoked " that would ( a ) not require user interaction and ( b ) not be covered by other current error codes ? - Would you mind making a PR to add an error code ( and anything else that comes up with ) , and note it in the revocation section ? 
 I thought of one to consider in : 
 It looks like  uses 404 and a generic malformed problem type for this case : 
 So far I could n't think of anything else . I 'm totally happy with :-) 
 Fixed by 
 : +1 : Thanks !
Paragraph (version A):
If the revocation succeeds, the server responds with status code 200
(OK).  If the revocation fails, the server returns an error.
Paragraph (version B):
If the revocation succeeds, the server responds with status code 200
(OK).  If the revocation fails, the server returns an error.  For
example, if the certificate has already been revoked the server
returns an error response with status code 400 (Bad Request) and type
"urn:ietf:params:acme:error:alreadyRevoked".
Draft: draft-ietf-acme-acme

Commentary: This is the obligatory reference whenever you mention randomness . 
 : +1 : thanks
Paragraph (version A):
A random value that uniquely identifies the challenge.  This value
MUST have at least 128 bits of entropy.  It MUST NOT contain any
characters outside the base64url alphabet, and MUST NOT include
base64 padding characters ("=").
Paragraph (version B):
A random value that uniquely identifies the challenge.  This value
MUST have at least 128 bits of entropy.  It MUST NOT contain any
characters outside the base64url alphabet, and MUST NOT include
base64 padding characters ("=").  See RFC4086 for additional
information on randomness requirements.
Draft: draft-ietf-acme-acme

Commentary: As proposed in EKR 's AD review , discussed on - list and at IETF 102 . 
 Of course , this needs WG consensus first . 
 Yes just posting this so we can be concrete about the discussion in the meeting . 
 Merging this on AD+chair guidance guidance that we can
Paragraph (version B):
An ACME server MUST implement the "ES256" signature algorithm RFC7518
and SHOULD implement the "EdDSA" signature algorithm using the
"Ed25519" variant (indicated by "crv") RFC8037.