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

Commentary: All of the Base64 strings are actually Base64 URL encoded In the  support for big ints the top byte is set to 0 to eliminate issues with signs . The thumbprint used here does not support that . It would be useful to mention that in the spec . I think it would help if there was an appendix with a complete example from key to key authorization to help clarify the points above . 
 Right , point 3 is pretty unclear and requires searching with your favorite search engine .
Paragraph (version A):
The "JWK_Thumbprint" step indicates the computation specified in
RFC7638, using the SHA-256 digest.  As specified in the individual
challenges below, the token for a challenge is a JSON string
comprised entirely of characters in the base64 alphabet.  The "||"
operator indicates concatenation of strings.
Paragraph (version B):
The "JWK_Thumbprint" step indicates the computation specified in
RFC7638, using the SHA-256 digest.  As specified in the individual
challenges below, the token for a challenge is a JSON string
comprised entirely of characters in the URL-safe Base64 alphabet.
The "||" operator indicates concatenation of strings.
Paragraph (version B):
An example of how to compute a JWK thumbprint can be found in
Section 3.1 of RFC7638.  Note that some cryptographic libraries
prepend a zero octet to the representation of the RSA public key
parameters N and E, in order to avoid ambiguity with regard to the
sign of the number.  As noted in JWA, a JWK object MUST NOT include
this zero octet.  That is, any initial zero octets MUST be stripped
before the values are Base64url-encoded.
Draft: draft-ietf-acme-acme

Commentary: It 's no longer at a " do not implement " stage , but some caution is still merited . Also , it 's good to have a pointer in the draft to this repo . ( Cribbed from the TLS 1.3 spec . )
Paragraph (version B):
DISCLAIMER: This is a WIP draft of ACME and has not yet had a
thorough security analysis.
Paragraph (version B):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
this draft is maintained in GitHub.  Suggested changes should be
submitted as pull requests at https://github.com/ietf-wg-acme/acme
[1].  Instructions are on that page as well.  Editorial changes can
be managed in GitHub, but any substantive change should be discussed
on the ACME mailing list (acme@ietf.org).
Paragraph (version B):
CAs that use ACME to automate issuance will need to ensure that their
servers perform all necessary checks before issuing.
Draft: draft-ietf-acme-acme

Commentary: Editorial changes .
Paragraph (version A):
With Simple HTTP validation, the client in an ACME transaction proves
its control over a domain name by proving that it can provision
resources on an HTTP server that responds for that domain name.  The
ACME server challenges the client to provision a file with a specific
JWS as its contents.
Paragraph (version B):
With HTTP validation, the client in an ACME transaction proves its
control over a domain name by proving that it can provision resources
on an HTTP server that responds for that domain name.  The ACME
server challenges the client to provision a file with a specific JWS
as its contents.
Paragraph (version A):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attack.  For example, on a web server that
allows non-administrative users to write to .well-known, any user can
claim to own the server's hostname by responding to a Simple HTTP
challenge, and likewise for TLS configuration and TLS SNI.
Paragraph (version B):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attack.  For example, on a web server that
allows non-administrative users to write to .well-known, any user can
claim to own the server's hostname by responding to an HTTP
challenge, and likewise for TLS configuration and TLS SNI.
Paragraph (version A):
More limited forms of delegation can also lead to an unintended party
gaining the ability to successfully complete a validation
transaction.  For example, suppose an ACME server follows HTTP
redirects in Simple HTTP validation and a web site operator
provisions a catch-all redirect rule that redirects requests for
unknown resources to different domain.  Then the target of the
redirect could use that to get a certificate through Simple HTTP
validation, since the validation path will not be known to the
primary server.
Paragraph (version B):
More limited forms of delegation can also lead to an unintended party
gaining the ability to successfully complete a validation
transaction.  For example, suppose an ACME server follows HTTP
redirects in HTTP validation and a web site operator provisions a
catch-all redirect rule that redirects requests for unknown resources
to different domain.  Then the target of the redirect could use that
to get a certificate through HTTP validation, since the validation
path will not be known to the primary server.
Draft: draft-ietf-acme-acme

Commentary: They should be base64url rather than base64 , for symmetry with rest of spec . 
 Do n't think this is totally necessary , since we say at the front that when we say " base64 " , we mean the special variant . But happy to be clearer here .
Paragraph (version A):
An array of certificates, in Base64-encoded DER format, that
contain acceptable public keys.
Paragraph (version B):
An array of certificates, in Base64url-encoded DER format, that
contain acceptable public keys.