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

Commentary: RFC 7748 , TLS 1.3 , and existing implementations do not check the significant bit . Instead , they mask it off . Align with all of these . Also tweak the all - zeros citation . RFC 7748 describes it as an optional check . 
 This looks goo to me . 
 LGTM
X25519 was designed in a way that the result of X25519(x, d) will
never reveal information about d, provided it was chosen as
prescribed, for any value of x (the same holds true for X448).
All-zeroes output from X25519 or X448 MUST NOT be used for premaster
secret (as required by definition of X25519 and X448).  If the
premaster secret would be all zeroes, the handshake MUST be aborted
(most probably by sending a fatal alert).
Let's define legitimate values of x as the values that can be
obtained as x = X25519(G, d') for some d', and call the other values
illegitimate.  The definition of the X25519 function shows that
legitimate values all share the following property: the high-order
bit of the last byte is not set (for X448, any bit can be set).
Since there are some implementation of the X25519 function that
impose this restriction on their input and others that don't,
implementations of X25519 in TLS SHOULD reject public keys when the
high-order bit of the final byte is set (in other words, when the
value of the rightmost byte is greater than 0x7F) in order to prevent
implementation fingerprinting.  Note that this deviates from RFC 7748
which suggests that This value be masked.
Other than this recommended check, implementations do not need to
ensure that the public keys they receive are legitimate: this is not
necessary for security with X25519.
With X25519 and X448, a receiving party MUST check whether the
computed premaster secret is the all-zero value and abort the
handshake if so, as described in section 6 of RFC7748.
Draft: draft-ietf-tls-rfc4492bis

Commentary: RFC 4492 called SHA-1 the " default " hash for ECDSA , because that was the only hash defined in X9.62 at the time . The new X9.62 ( new being a relative term - it 's from 2005 ) defines all the SHA-2 hashes as well . We now make the use of secure hashes a MUST and we call out SHA-256 , SHA-384 , and SHA-512 explicitly as examples . Also had to update the reference to the SHA document from NIST 180 - 2 ( which did not contain  ) to the current NIST 180 - 4 ( which does )
All ECDSA computations MUST be performed according to ANSI X9.62 or
its successors.  Data to be signed/verified is hashed, and the result
run directly through the ECDSA algorithm with no additional hashing.
The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske
and cert_verify) is 20.  However, an alternative hash function, such
as one of the new SHA hash functions specified in FIPS 180-2
FIPS.180-2, SHOULD be used instead.
All ECDSA computations MUST be performed according to ANSI X9.62 or
its successors.  Data to be signed/verified is hashed, and the result
run directly through the ECDSA algorithm with no additional hashing.
A secure hash function such as SHA-256, SHA-384, or SHA-512 from
FIPS.180-4 MUST be used.
Draft: draft-ietf-tls-rfc4492bis

Commentary: Use initialism consistently in the Introduction Mention EdDSA in addition to ECDSA as a signature scheme 
 lgtm
the use of the Elliptic Curve Diffie-Hellman key agreement scheme
with ephemeral keys to establish the TLS premaster secret, and
the use of ECDSA certificates for authentication of TLS peers.
the use of the ECDHE key agreement scheme with ephemeral keys to
establish the TLS premaster secret, and
the use of ECDSA and EdDSA signatures for authentication of TLS
peers.
Draft: draft-ietf-tls-rfc4492bis

Commentary: if both draft - ietf - tls - iana - registry - updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme . 
 Ship it 
 Shipped 
 LGTM
IANA is requested to prepend "TLS" to the names of the previous three
registries.
Draft: draft-ietf-tls-rfc4492bis

Commentary: draft - irtf - cfrg - eddsa is now 
 Thank you !
EdDSA signatures in both the protocol and in certificates that
conform to PKIX-EdDSA are generated and verified according to CFRG-
EdDSA.  The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm.
EdDSA signatures in both the protocol and in certificates that
conform to PKIX-EdDSA are generated and verified according to
RFC8032.  The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm.
EdDSA signatures are generated and verified according to CFRG-EdDSA.
The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm.
EdDSA signatures are generated and verified according to RFC8032.
The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm.
X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with RFC3279 or another RFC that replaces or extends it.
X.509 certificates containing ECC public keys or signed using EdDSA
MUST comply with PKIX-EdDSA.  Clients SHOULD use the elliptic curve
domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2
SECG-SEC2 or in CFRG-EdDSA.
X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with RFC3279 or another RFC that replaces or extends it.
X.509 certificates containing ECC public keys or signed using EdDSA
MUST comply with PKIX-EdDSA.  Clients SHOULD use the elliptic curve
domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2
SECG-SEC2 or in RFC8032.
All EdDSA computations MUST be performed according to CFRG-EdDSA or
its succesors.  Data to be signed/verified is run through the EdDSA
algorithm wih no hashing (EdDSA will internally run the data through
the PH function).
All EdDSA computations MUST be performed according to RFC8032 or its
succesors.  Data to be signed/verified is run through the EdDSA
algorithm wih no hashing (EdDSA will internally run the data through
the PH function).
Draft: draft-ietf-tls-rfc4492bis

Commentary: Removed two paragraphs and a table full of motivation about why ECC is great . In 2016 this is no longer needed . ECC is already mainstream . 
 +1
Elliptic Curve Cryptography (ECC) has emerged as an attractive
public-key cryptosystem, in particular for mobile (i.e., wireless)
environments.  Compared to currently prevalent cryptosystems such as
RSA, ECC offers equivalent security with smaller key sizes.  This is
illustrated in the following table, based on Lenstra_Verheul, which
gives approximate comparable key sizes for symmetric- and asymmetric-
key cryptosystems based on the best-known algorithms for attacking
them.
Smaller key sizes result in savings for power, memory, bandwidth, and
computational cost that make ECC especially attractive for
constrained environments.
Draft: draft-ietf-tls-rfc4492bis

Commentary: Should remove the " TBD2 " after  . 
 Looks good to me . Thanks .
IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this
document as reference.  IANA has already assigned the value 29 to
ecdh_x25519, and the value 30 to ecdh_x448(TBD2).
IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this
document as reference.  IANA has already assigned the value 29 to
ecdh_x25519, and the value 30 to ecdh_x448.
Draft: draft-ietf-tls-rfc4492bis

Commentary: for ecdhx25519 and ecdhx448
IANA is requested to assign four values from the NamedCurve registry
with names ecdh_x25519(TBD1), ecdh_x448(TBD2), eddsa_ed25519(TBD3)
and eddsa_ed448(TBD4) with this document as reference.
IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this
document as reference.  IANA has already assigned the value 29 to
ecdh_x25519, and the value 30 to ecdh_x448(TBD2).
Draft: draft-ietf-tls-rfc4492bis

Commentary: See    message IETF review is too onerous - use " specification required " instead .
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use.  Any
additional assignments require IETF Review.
NOTE: IANA, please update the registries to reflect the new policy
name.
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use.  The
policy for any additional assignments is "Specification Required".
The previous version of this document required IETF review.
NOTE: IANA, please update the registries to reflect the new policy.
Draft: draft-ietf-tls-rfc4492bis

Commentary: TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key . TLS 1.2 removed this restriction . Since RFC 4492 predated TLS 1.2 it reflected the same restriction . Here we remove it .
This key exchange algorithm is the same as ECDHE_ECDSA except that
the server's certificate MUST contain an RSA public key authorized
for signing, and that the signature in the ServerKeyExchange message
must be computed with the corresponding RSA private key.  The server
certificate MUST be signed with RSA.
This key exchange algorithm is the same as ECDHE_ECDSA except that
the server's certificate MUST contain an RSA public key authorized
for signing, and that the signature in the ServerKeyExchange message
must be computed with the corresponding RSA private key.
This specification does not impose restrictions on signature schemes
used anywhere in the certificate chain.  The previous version of this
document required the signatures to match, but this restriction,
originating in previous TLS versions is lifted here as it had been in
RFC 5246.
To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA-capable public key and signed with
ECDSA.
To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA-capable public key.
Draft: draft-ietf-tls-rfc4492bis

Commentary: I 've restructured a little in support of this . I think that forward secrecy is more pertinent than the analogous finite - field stuff . I can make this less intrusive if you feel like the changes are gratuitous .
The table below summarizes the new key exchange algorithms, which
mimic DHE_DSS, DHE_RSA, and DH_anon, respectively.
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
certificate and easily comply with a constrained client's elliptic
curve p references (see tlsext).  However, the computational cost
incurred by a server is higher for ECDHE_RSA than for the traditional
RSA key exchange, which does not provide forward secrecy.
tbl2 summarizes the new key exchange algorithms.  All of these key
exchange algorithms provide forward secrecy.
These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon,
respectively.
With ECDHE_RSA, a server can reuse its existing RSA certificate and
easily comply with a constrained client's elliptic curve preferences
(see tlsext).  However, the computational cost incurred by a server
is higher for ECDHE_RSA than for the traditional RSA key exchange,
which does not provide forward secrecy.
Draft: draft-ietf-tls-rfc4492bis

Commentary: Merge errata from RFC 4492 
 LGTM
The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see supp_pf_ext).
Items in elliptic_curve_list here are ordered according to the
server's preference (favorite choice first).  Note that the server
may include items that were not found in the client's list (e.g., the
server may prefer to receive points in compressed format even when a
client cannot parse this format: the same client may nevertheless be
capable of outputting points in compressed format).
The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see supp_pf_ext).
Items in ec_point_format_list here are ordered according to the
server's preference (favorite choice first).  Note that the server
may include items that were not found in the client's list (e.g., the
server may prefer to receive points in compressed format even when a
client cannot parse this format: the same client may nevertheless be
capable of outputting points in compressed format).