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

Commentary: does n't is missing at Sec 8.2 ?
IANA is requested to add the following entries to the registry for
Exporter Labels (defined in RFC5705): "EXPORTER-server authenticator
handshake context", "EXPORTER-client authenticator handshake
context", "EXPORTER-client authenticator finished key" and "EXPORTER-
server authenticator finished key" with "DTLS-OK" and "Recommended"
set to "Y" and this document added to the "Reference" column.
IANA is requested to add the following entries to the registry for
Exporter Labels (defined in RFC5705): "EXPORTER-client authenticator
handshake context", "EXPORTER-server authenticator handshake
context", "EXPORTER-client authenticator handshake context",
"EXPORTER-client authenticator finished key" and "EXPORTER-server
authenticator finished key" with "DTLS-OK" and "Recommended" set to
"Y" and this document added to the "Reference" column.
Draft: draft-ietf-tls-exported-authenticator

Commentary: Section 4 : I find this confusing : extensions : The set of extensions allowed in the CertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry containing CR in the TLS 1.3 column . The extensions allowed in the ClientCertificateRequest are those containing CR in the TLS 1.3 column , along with the servername [ RFC6066 ] extension . I think it means : extensions : The set of extensions allowed in the CertificateRequest structure and the ClientCertificateRequest structure are those defined in the TLS ExtensionType Values IANA registry [ cite ] containing CR in the TLS 1.3 column . In addition , the set of extensions in the ClientCertificateRequest structure MAY include the servername [ RFC6066 ] extension . 
 fixed in
The set of extensions allowed in the CertificateRequest structure
and the ClientCertificateRequest structure are those defined in
the TLS ExtensionType Values IANA registry RFC8447 containing CR
in the TLS 1.3 column.  In addition, the set of extensions in the
ClientCertificateRequest structure MAY include the server_name
RFC6066 extension.
Draft: draft-ietf-tls-exported-authenticator

Commentary: one minor nit : i would phrase " applying the function for validating the certificate chain contained in the authenticator . " as " applying the function for validating the certificate chain to the chain contained in the authenticator . " for clarity . Otherwise LGTM ! 
 I 've implemented earlier drafts . I do have a concern with the validate API as presented in the draft : it treats empty authenticators as valid , and then returns the identity as a certificate chain that must be validated by the application . Similar APIs have lead to easily foreseeable pwnage . Instead I would recommend the validate API carry out X509 validation against a trust store or validation function and treat the empty authenticator as invalid . That way someone has to think before not checking the certificate returned . 
 Closing this out as it was addressed .
It returns the identity, such as the certificate chain and its
extensions, and a status to indicate whether the authenticator is
valid or not.  The API SHOULD return a failure if the
certificate_request_context of the authenticator was used in a
previously validated authenticator.  Well-formed empty authenticators
are returned as valid.
It returns the identity, such as the certificate chain and its
extensions, and a status to indicate whether the authenticator is
valid or not after applying the function for validating the
certificate chain to the chain contained in the authenticator.
The API SHOULD return a failure if the certificate_request_context of
the authenticator was used in a previously validated authenticator.
Well-formed empty authenticators are returned as invalid.
Draft: draft-ietf-tls-exported-authenticator

Commentary: got merged while I was reviewing it , so here 's my feedback as a follow - up PR . I initially though line 244 needed a comma , but usage through the rest of the document suggests that supporting certificates are a property of one type of identity instead of something that could come along with a generic identity , so I dropped that one . 
 Thanks ,  .
This document describes a mechanism in Transport Layer Security (TLS)
for peers to provide a proof of ownership of an identity, such as an
X509 certificate.  This proof can be exported by one peer,
transmitted out-of-band to the other peer, and verified by the
receiving peer.
This document describes a mechanism in Transport Layer Security (TLS)
for peers to provide a proof of ownership of an identity, such as an
X.509 certificate.  This proof can be exported by one peer,
transmitted out-of-band to the other peer, and verified by the
receiving peer.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, an identity, such as
an X509 certificate, and a corresponding private key.  Clients MUST
NOT send an authenticator without a preceding authenticator request;
for servers an authenticator request is optional.  For authenticators
that do not correspond to authenticator requests, the
certificate_request_context is chosen by the server.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, an identity, such as
an X.509 certificate, and a corresponding private key.  Clients MUST
NOT send an authenticator without a preceding authenticator request;
for servers an authenticator request is optional.  For authenticators
that do not correspond to authenticator requests, the
certificate_request_context is chosen by the server.
Only the X509 certificate type defined in TLS13 is supported.
Alternative certificate formats such as RFC7250 Raw Public Keys are
not supported in this version of the specification and their use in
this context has not yet been analysed.
Only the X.509 certificate type defined in TLS13 is supported.
Alternative certificate formats such as RFC7250 Raw Public Keys are
not supported in this version of the specification and their use in
this context has not yet been analysed.
Where Hash is the authenticator hash defined in section 4.1.  If the
authenticator request is not present, it is omitted from this
construction, i.e., it is zero length.
Where Hash is the authenticator hash defined in section 4.1.  If the
authenticator request is not present, it is omitted from this
construction, i.e., it is zero-length.
Draft: draft-ietf-tls-exported-authenticator

Commentary: Proposal to fix Issue 
 cc 
 The Introduction limits this to TLS 1.2 and later , but DTLS is similar . Do you want to take that into account now , or ignore it ? DTLS has additional fields to support fragmentation : 
 Exported authentication are meant to be embedded in a higher - layer protocol , so there 's no need to support fragmentation . 
 The draft states that there should be no " TLS framing " but what is meant is that the handshake messages should n't be encapsulated by TLS Record Framing ( which does the encryption of the handshake messages ) .
The CertificateRequest and ClientCertificateRequest messages are used
to define the parameters in a request for an authenticator.  These
messages do not include any TLS framing and are not encrypted with a
handshake key.
The CertificateRequest and ClientCertificateRequest messages are used
to define the parameters in a request for an authenticator.  These
are encoded as TLS handshake messages, including length and type
fields.  They do not include any TLS record layer framing and are not
encrypted with a handshake key.
To avoid key synchronization attacks, Exported Authenticators MUST
NOT be generated or accepted on TLS 1.2 connectons that did not
negotiate the extended master secret RFC7627.
An authenticator is formed from the concatenation of TLS 1.3 TLS13
Certificate, CertificateVerify, and Finished messages.
To avoid key synchronization attacks, Exported Authenticators MUST
NOT be generated or accepted on TLS 1.2 connections that did not
negotiate the extended master secret RFC7627.
An authenticator is formed from the concatenation of TLS 1.3 TLS13
Certificate, CertificateVerify, and Finished messages.  These
messages are encoded as TLS handshake messages, including length and
type fields.
If, given an authenticator request, the endpoint does not have an
appropriate certificate or does not want to return one, it constructs
an authenticated refusal called an empty authenticator.  This is a
Finished message sent without a Certificate or CertificateVerify.
This message is an HMAC over the hashed authenticator transcript with
a Certificate message containing no CertificateEntries and the
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message does not include any TLS framing.
If, given an authenticator request, the endpoint does not have an
appropriate certificate or does not want to return one, it constructs
an authenticated refusal called an empty authenticator.  This is a
Finished message sent without a Certificate or CertificateVerify.
This message is an HMAC over the hashed authenticator transcript with
a Certificate message containing no CertificateEntries and the
CertificateVerify message omitted.  The HMAC is computed using the
authenticator hash, using the Finished MAC Key as a key.  This
message is encoded as a TLS handshake message, including length and
type field.  It does not include TLS record layer framing.
Draft: draft-ietf-tls-exported-authenticator

Commentary: are you happy with the adjusted text ? I do n't consider DTLS support to be a big change since the only thing we are relying on from TLS is the exporter interface . 
 I think that this is sneaking in a big change with the DTLS thing . I 'll try to find the email ...
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) communication to its peer using a certificate
after the session has been established.  This allows both the client
and server to prove ownership of additional identities at any time
after the handshake has completed.  This proof of authentication can
be exported and transmitted out of band from one party to be
validated by its peer.
This document provides a way to authenticate one party of a Transport
Layer Security (TLS) connection to its peer using a certificate after
the session has been established.  This allows both the client and
server to prove ownership of additional identities at any time after
the handshake has completed.  This proof of authentication can be
exported and transmitted out-of-band from one party to be validated
by its peer.
For simplicity, the mechanisms described in this document require a
TLS version 1.2 or later.
Exported Authenticators are meant to be used as a building block for
application protocols.  Mechanisms such as those required to
advertise support and handle authentication errors are not handled at
the TLS layer.
For simplicity, the mechanisms described in this document require TLS
(or DTLS) version 1.2 or later.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
connection.  It can be transmitted to the other party of the TLS
connection at the application layer.  The application layer protocol
used to send the authenticator SHOULD use TLS as its underlying
transport to keep the request confidential.
The authenticator request is a structured message that can be created
by either party of a TLS connection using data exported from that
connection.  It can be transmitted to the other party of the TLS
connection at the application layer.  The application layer protocol
used to send the authenticator request SHOULD use TLS as its
underlying transport to keep the request confidential.  The
application MAY use the existing TLS connection to transport the
authenticator.
The authenticator is a structured message that can be exported from
either party of a TLS connection.  It can be transmitted to the other
party of the TLS connection at the application layer.  The
application layer protocol used to send the authenticator SHOULD use
TLS as its underlying transport to keep the certificate confidential.
The authenticator is a structured message that can be exported from
either party of a TLS connection.  It can be transmitted to the other
party of the TLS connection at the application layer.  The
application layer protocol used to send the authenticator SHOULD use
TLS as its underlying transport to keep the certificate confidential.
The application MAY use the existing TLS connection to transport the
authenticator.
Draft: draft-ietf-tls-exported-authenticator

Commentary: In Section 3 of the RFC , it states that the authenticator request includes those extensions allowed for the CertificateRequest message . However , this does not mean it could only includes them and other extensions could also be sent . In the TLS spec CertificateRequest explicitly states " Clients MUST ignore unrecognized extensions . " , we should have the same here .
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  If the certificate_request_context from the authenticator
request has already been used in the connection, then no
authenticator should be constructed.  If there is no authenticator
request, the extensions are chosen from the TLS handshake.  Only
servers can provide an authenticator without a corresponding request.
In such cases, ClientHello extensions are used to determine
permissible extensions in the Certificate message.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  Unrecognized extensions MUST be ignored.  If the
certificate_request_context from the authenticator request has
already been used in the connection, then no authenticator should be
constructed.  If there is no authenticator request, the extensions
are chosen from the TLS handshake.  Only servers can provide an
authenticator without a corresponding request.  In such cases,
ClientHello extensions are used to determine permissible extensions
in the Certificate message.
Draft: draft-ietf-tls-exported-authenticator

Commentary: TBH I do n't really know if this is actually needed . 
 Whoops that was supposed to be about it 's good to merge . We need this section to tell IANA to register the exporter . 
 do you mind amending this to add : 
 Added section about exporter labels as well .
This document has no IANA actions.
IANA is requested to update the entry for server_name(0) in the
registry for ExtensionType (defined in TLS13) by replacing the value
in the "TLS 1.3" column with the value "CH, EE, CR".
IANA is requested to add the following entries to the registry for
Exporter Labels (defined in RFC5705): "EXPORTER-server authenticator
handshake context", "EXPORTER-client authenticator finished key" and
"EXPORTER-server authenticator finished key".
Draft: draft-ietf-tls-exported-authenticator

Commentary: In RFC5705 absent and zero length context produce different results .
The context_value used for the exporter is absent (length zero) for
all four values.  The length of the exported value is equal to the
length of the output of the hash function selected in TLS for the
pseudorandom function (PRF).  Cipher suites that do not use the TLS
PRF MUST define a hash function that can be used for this purpose or
they cannot be used.  For TLS 1.3 symmetric cipher suites, the hash
algorithm used with HKDF is used.
The context_value used for the exporter is empty (zero length) for
all four values.  The length of the exported value is equal to the
length of the output of the hash function selected in TLS for the
pseudorandom function (PRF).  Cipher suites that do not use the TLS
PRF MUST define a hash function that can be used for this purpose or
they cannot be used.  For TLS 1.3 symmetric cipher suites, the hash
algorithm used with HKDF is used.
Draft: draft-ietf-tls-exported-authenticator

Commentary: the newline was being introduced by trailing whitespace at the end of line 136 . 
 In the , there 's a newline between two sentences that apparently ca n't decide whether they want to be in separate paragraphs or not .
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  Clients MUST NOT send an authenticator
without a preceding authenticator request; for servers an
authenticator request is optional.
The authenticator uses the message structures from Section 4.4 of
TLS13, but different parameters.  These messages do not include the
TLS record layer and are therefore not encrypted with a handshake
key.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  Clients MUST NOT send an authenticator
without a preceding authenticator request; for servers an
authenticator request is optional.  The authenticator uses the
message structures from Section 4.4 of TLS13, but different
parameters.  These messages do not include the TLS record layer and
are therefore not encrypted with a handshake key.
Draft: draft-ietf-tls-exported-authenticator

Commentary: you do n't want to provide one . TLS allows Certificate to be empty , with a missing CertificateVerify and Finished as normal . That would be a nice change . Alternatively , we could insist on the using application managing this , but it seems like an authenticated refusal is nice . 
 Resolved in PR
The HMAC is computed using the same hash function using the Finished
MAC Key as a key.
It returns the exported authenticator as a sequence of octets.
Ideally, the logic for selecting the certificates and extensions to
include in the exporter is implemented in the TLS library.
Implementing this in the TLS library lets the implementer take
advantage of existing extension and certificate selection logic.
It returns either the exported authenticator or an empty
authenticator as a sequence of octets.  It is RECOMMENDED that the
logic for selecting the certificates and extensions to include in the
exporter is implemented in the TLS library.  Implementing this in the
TLS library lets the implementer take advantage of existing extension
and certificate selection logic.
It returns the certificate chain and extensions.
It returns the certificate chain and extensions and a status to
indicate whether the authenticator is valid or not.  If the
authenticator was empty - that is, it did not contain a certificate -
the certificate chain will contain no certificates.
Draft: draft-ietf-tls-exported-authenticator

Commentary: In Section 4 , clients are required to have an authenticator request before generating and sending an authenticator . Later , in Section 4.2 , the draft states that clients may get authenticator information from a SH or EncryptedExtensions in the event that no authenticator request is present . This seems to contradict the requirement in Section 4 .
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  For clients, an authenticator request is
required; for servers an authenticator request is optional.  The
authenticator uses the message structures from Section 4.4 of TLS13,
but different parameters.  These messages do not include the TLS
record layer and are therefore not encrypted with a handshake key.
An authenticator message can be constructed by either the client or
the server given an established TLS connection, a certificate, and a
corresponding private key.  Clients MUST NOT send an authenticator
without a preceding authenticator request; for servers an
authenticator request is optional.
The authenticator uses the message structures from Section 4.4 of
TLS13, but different parameters.  These messages do not include the
TLS record layer and are therefore not encrypted with a handshake
key.
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  If there is no authenticator request, the extensions are
chosen from the TLS handshake.  That is, the extensions received in a
ClientHello (for servers), ServerHello (for clients in TLS 1.2), or
EncryptedExtensions (for clients in TLS 1.3).
If an authenticator request is present, the extensions used to guide
the construction of these messages are taken from the authenticator
request.  If there is no authenticator request, the extensions are
chosen from the TLS handshake.  Only servers can provide an
authenticator without a corresponding request.  In such cases,
ClientHello extensions are used to determine permissible extensions
in the Certificate message.
Draft: draft-ietf-tls-exported-authenticator

Commentary: It 's also the only use of 2119 language in this section , which is otherwise nicely informative .
It returns the exported authenticator as a sequence of octets.  It is
RECOMMENDED that the logic for selecting the certificates and
extensions to include in the exporter is implemented in the TLS
library.  Implementing this in the TLS library lets the implementer
take advantage of existing extension and certificate selection logic.
It returns the exported authenticator as a sequence of octets.
Ideally, the logic for selecting the certificates and extensions to
include in the exporter is implemented in the TLS library.
Implementing this in the TLS library lets the implementer take
advantage of existing extension and certificate selection logic.
Draft: draft-ietf-tls-exported-authenticator

Commentary: Make it possible to choose a non - empty certificaterequestcontext when there is no authenticator request . This change introduces the flexibility needed to achieve compound authentication between certificates using a technique called CRC Smuggling , described by   .
The certificate message contains an opaque string called
certificate_request_context, which is extracted from the
authenticator request if present.  If no authenticator request is
provided, it is zero-length.
The certificate message contains an opaque string called
certificate_request_context, which is extracted from the
authenticator request if present.  If no authenticator request is
provided, the certificate_request_context can be chosen arbitrarily.
Draft: draft-ietf-tls-exported-authenticator

Commentary: Just fixing a couple of nits that will need to be addressed later .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 RFC2119.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Draft: draft-ietf-tls-exported-authenticator

Commentary: Fix typos , clarify Hash used .
The Finished MAC Key is an exporter value derived using the label
"EXPORTER-server authenticator finished key" or "EXPORTER-client
authenticator finished key" for authenticators sent by the client
and server respectively.
The Finished MAC Key is an exporter value derived using the label
"EXPORTER-client authenticator finished key" or "EXPORTER-server
authenticator finished key" for authenticators sent by the client
and server respectively.
A HMAC over the value Hash(Handshake Context || Certificate ||
CertificateVerify) using the hash function from the handshake and
the Finished MAC Key as a key.
The value Hash(Handshake Context || Certificate) where Hash is the
hash function for the handshake.
A HMAC over the value Hash(Handshake Context || Certificate ||
CertificateVerify) where Hash is the hash function for the
handshake, and the HMAC is computed using the hash function from
the handshake and the Finished MAC Key as a key.