jiebi/TextFlow huggingface dataset:
Original text:
3.1.1. <del> A client which supports this specification SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </del>  If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a <del> type advertised by the client in the "signature_algorithms" extension and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </del>  3.1.2.

Reviewer comments:
Hearing no objections on the list, merging this in. NAME can you please spin a new version for WGLC?
Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.
Fixed by .

Revised text:
3.1.1.  <ins> A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello.  The body of the extension consists of a SignatureSchemeList: If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a  <ins> type advertised by the client in the SignatureSchemeList and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </ins> 3.1.2.
Original text:
This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" <del> extension has been assigned a code point of TBD.  The IANA registry </del>  lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.

Reviewer comments:
Currently the codepoint is TBD
NAME does one know what we need to get a code point.
NAME if we want one early, we can kick that process off. If not we wait for it to be assigned later in the process.
I think we need an early one. It's not possible yet to implement this to evaluate in various scenarios. We plan to use delegated credentials in our internal infrastructure and then probably would push the implementation back to open source projects like OpenSSL.
i think a resolution to URL is the only thing that is probably holding back the code point.
NAME can you please start the code point allocation process now that is resolved?

Revised text:
This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials"  <ins> extension has been assigned a code point of 34.  The IANA registry </ins> lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.
Original text:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as Content Delivery Network (CDNs) or remote data </del>  centers.  This allows server operators to limit the exposure of keys <del> in cases that they do not realize a compromise has occurred.  The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del>  To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own

Reviewer comments:
Also fixed a few smaller grammatical/punctuation errors. Rationale from the mailing list: I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.

Revised text:
These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low-  <ins> trust zones such as Content Delivery Networks (CDNs) or remote data </ins> centers.  This allows server operators to limit the exposure of keys  <ins> in cases where they do not realize a compromise has occurred. However, the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446), a CA may fail to deliver OCSP stapled response.  While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates are even worse: the service that depends on those certificates would go down entirely.  Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own
Original text:
4.1. <del> We define a new X.509 extension, DelegationUsage to be used in the </del>  certificate when the certificate permits the usage of delegated credentials. certificates. The client MUST NOT accept a delegated credential unless the server's <del> end-entity certificate has the DelegationUsage extension. </del>  5.

Reviewer comments:
Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols. In this PR, I propose explicitly restricting the X.509 KeyUsage of the end-entity certificate. This change is made in the last commit: URL The two commits that proceed it don't actually change the semantics of the standard, but clean up the language a bit. If the KeyUsage change isn't adopted, we might consider merging the other two commits.
if it's not too painful, could you move this particular diff above all the others, I think I want to have some more discussion on this one. If its painful, we can just resolve this one first
Done, NAME
looks like i merged this as a result of merging a dependent PR accidentally. This is fine, we can just discuss this before I put up the next draft versions

Revised text:
4.1.  <ins> We define a new X.509 extension, DelegationUsage, to be used in the </ins> certificate when the certificate permits the usage of delegated credentials. certificates. The client MUST NOT accept a delegated credential unless the server's  <ins> end-entity certificate satisfies the following criteria: It has the DelegationUsage extension. It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. </ins> 5.
Original text:
Address case nits  Add text about certificate extension vs EKU draft-08 elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. 

Reviewer comments:
NAME please go ahead and merge after resolving conflicts!
From Martin: The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.
NAME I'm not sure what you mean here. Are you talking about explicitly calling out the possibility that the credential may expire after the certificate and that this should be forbidden?
If you are able to access the signing key of the certificate, or are otherwise able to construct a DC, you can create multiple DCs that cover the time from now until the certificate expires. It's not a big deal, but I thought it might be worth noting.
Gotcha. I'll note this.
Closed in

Revised text:
Address case nits <ins> Add text around using an oracle to forge DCs in the future and past </ins> Add text about certificate extension vs EKU draft-08 elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. <ins> Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field.  Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate.  Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. </ins>
Original text:
semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the <del> peer.  The secret key used to sign a credential corresponds to the </del>  public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a

Reviewer comments:
In section 3, the document says: The secret key used to sign ... Please change "secret" to "private". Later in the sentence, [RFC5280] is referenced, and it talks about "private key" in this context.
Addressed in

Revised text:
semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the  <ins> peer.  The private key used to sign a credential corresponds to the </ins> public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a
Original text:
Address case nits  draft-08 Include details about the impact of signature forgery attacks It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280).  5. This document registers the "delegated_credentials" extension in the

Reviewer comments:
From Russ: I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage. From Watson: One of the hard requirements for our deployment was that the same certificate be useable with DCs and without. A different EKU would be more problematic then an extension for this purpose, and while it might be more or less irritating for implementors depending on how their stack works (sorry Rich - https://boringssl-URL might serve as inspiration, but the client side got dropped for similar issues). We know the extension doesn't bust things, I don't know an EKU would, and the root program issues make me hesitate.
Addressed in

Revised text:
Address case nits <ins> Add text about certificate extension vs EKU </ins> draft-08 Include details about the impact of signature forgery attacks It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). <ins> A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed TLS and PKI software stacks without requiring CAs to issue new intermediate certificates. </ins> 5. This document registers the "delegated_credentials" extension in the
Original text:
Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential <del> is no longer valid.  Endpoints will reject delegate credentials with valid_times exceeding 7 days (as described in client-and- server-behavior). </del>  The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity <del> certificate to the peer's expected identity.  It also takes the following steps: Validate that DelegatedCredential.cred.valid_time is no more than 7 days. </del>  Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time <del> is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. Verify that the delegated credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del>  Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the

Reviewer comments:
Update the condition for validating a DC to the following: now() <= notBefore + valid_time <= now() + 7d
LGTM % nit

Revised text:
Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential  <ins> is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client-and-server-behavior). </ins> The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity  <ins> certificate to the peer's expected identity.  It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: </ins> Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time  <ins> does not exceed the expiry time. Verify that the delegated credential's remaining validity period is no more than the maximum validity period.  This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days). </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the
Original text:
Sent by servers when a client "application_layer_protocol_negotiation" extension advertises <del> protocols that the server does not support. </del>  New Alert values are assigned by IANA as described in iana- considerations.

Reviewer comments:
Follow up to PR . Add a link for the ALPN RFC to the relevant alert's description. (same as with other extension alerts above)
URL & No feature in the TLS 1.3 spec, optional or required, needs ALPN to work. We merely cite places where it needs to be taken into consideration if it is in use. It could be argued that it is an "optional feature" of TLS (as a whole), but not of this document, thus I don't think it meets the qualifications to be normative. I think staying as informative is correct.
There's a bunch of text that specifically mentions ALPN, some of it with normative statements. If those normative statements can't be understood, optional feature or not, then it's normative.

Revised text:
Sent by servers when a client "application_layer_protocol_negotiation" extension advertises  <ins> protocols that the server does not support (see RFC7301). </ins> New Alert values are assigned by IANA as described in iana- considerations.
Original text:
%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an <del> EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys derived from the client_early_traffic_secret. </del>  4.6.

Reviewer comments:
This follows naturally from the inclusion of EndOfEarlyData in the handshake transcript, but it doesn't hurt to mention it explicitly. See also, uh, 7511e2a259.
NAME I mention it explicitly because it tripped me up in implementation :)

Revised text:
%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an  <ins> EndOfEarlyData message after receiving the server Finished.  If the server does not send an "early_data" extension, then the client MUST NOT send an EndOfEarlyData message.  This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert. This message is encrypted under keys derived from the client_early_traffic_secret. </ins> 4.6.
Original text:
algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the <del> handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. </del>  If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

Reviewer comments:
There are a number of different alerts that may be suitable for sending to indicate a non-acceptable cert chain, e.g. certificaterevoked, certificateexpired, unknown_ca, etc. We should not restrict the client to only sending one specific alert.
I have updated this PR with the wording as suggested by NAME

Revised text:
algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the  <ins> handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see error-alerts for more). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such
Original text:
32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS <del> 1.2 or TLS 1.1.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </del>  The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK.  7.2. Once the handshake is complete, it is possible for either side to

Reviewer comments:
by Hugo Krawczyk.
Other than davegarrett's editorial notes, this looks good.

Revised text:
32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS  <ins> 1.2 or TLS 1.1, but the remaining bytes MUST be random.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK. <ins> Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased. </ins> 7.2. Once the handshake is complete, it is possible for either side to
Original text:
Removed support for non-AEAD ciphers <del> 1.3. This document is a revision of the TLS 1.1 RFC4346 protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms.  The major changes are: The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs.  All cipher suites in this document use P_SHA256. The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash.  Signed elements now include a field that explicitly specifies the hash algorithm used. Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS. Addition of support for authenticated encryption with additional data modes. TLS Extensions definition and AES Cipher Suites were merged in from external TLSEXT and RFC3268. Tighter checking of EncryptedPreMasterSecret version numbers. Tightened up a number of requirements. Verify_data length now depends on the cipher suite (default is still 12). Cleaned up description of Bleichenbacher/Klima attack defenses. Alerts MUST now be sent in many cases. After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list. TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite. Added HMAC-SHA256 cipher suites. Removed IDEA and DES cipher suites.  They are now deprecated and will be documented in a separate document. Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT.  Support will probably become a SHOULD NOT in the future. Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding. Added an Implementation Pitfalls sections The usual clarifications and editorial work. </del> 2. The goals of the TLS protocol, in order of priority, are as follows:

Reviewer comments:
TLS 1.1 [RFC 4346] & TLS 1.2 [RFC 5246] each only have a list of changes from the immediately previous version. This current draft has both the current changelog since TLS 1.2 and the old list of changes from TLS 1.1 to 1.2. The contents of this old section are no longer relevant, in particular it mentions TLSRSAWITHAES128CBCSHA as MTI which is no longer permitted at all. Suggesting just removing this now.
Thanks. Merged.

Revised text:
Removed support for non-AEAD ciphers  2. The goals of the TLS protocol, in order of priority, are as follows: