jiebi/CodeConvo huggingface dataset:
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <del> Likewise, either party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </del> <ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a corresponding certificate in anticipation of a request shortly being blocked.  Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist in associating the certificate request with a particular HTTP transaction. </ins> 2.3.
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: If the TLS certificate does not contain the new origin, but the server has claimed support for that origin (with an ORIGIN frame, see <del> RFC8336) and advertised support for HTTP-layer certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </del> <ins> RFC8336) and advertised support for HTTP-layer server certificates (see setting), the client MAY send a "CERTIFICATE_REQUEST" frame </ins> describing the desired origin.  The client then sends a "CERTIFICATE_NEEDED" frame for stream zero referencing the request, indicating that the connection cannot be used for that origin until
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: stream zero.  Multiple "CERTIFICATE_NEEDED" frames on any other stream MUST be considered a stream error of type "PROTOCOL_ERROR". <del> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: to a request that has not yet been received, servers SHOULD cache the indication briefly in anticipation of the request. <del> Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an </del> <ins> Receipt of more than one unsolicited "USE_CERTIFICATE" frame or an </ins> unsolicited "USE_CERTIFICATE" frame which is not the first in reference to a given stream MUST be treated as a stream error of type "CERTIFICATE_OVERUSED".
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: specifies a desired certificate.  This describes the certificate the sender wishes to have presented. <del> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which has not advertised support for HTTP-layer certificate authentication. </del> <ins> The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" setting. </ins> The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero.  A "CERTIFICATE_REQUEST" frame received on any other stream MUST be
Code change:
Instead of a four-byte exporter, uses an eight-byte exporter and splits into two values. Support for exchanging server certificates and client certificates is now indicated separately.
The current advertisement scheme does not allow for a client to decide it is willing to implement secondary server certificates but not client certificates or vice versa. It may be worth having two SETTINGS values, one for whether you're willing to do either of the two flows.

Related discussion:
text: This draft adds entries in three registries. <del> The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in iana- setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </del> <ins> The feature negotiation settings is registered in iana-setting.  Four frame types are registered in iana-frame.  Six error codes are registered in iana-errors. </ins> 7.1. <del> The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 Settings" registry established in RFC7540. SETTINGS_HTTP_CERT_AUTH 0xSETTING-TBD 0 This document. </del> <ins> The SETTINGS_HTTP_CLIENT_CERT_AUTH and SETTINGS_HTTP_SERVER_CERT_AUTH settings are registered in the "HTTP/2 Settings" registry established in RFC7540. </ins> 7.2.
Code change:
though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.

Related discussion:
text: The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" <del> setting. </del> <ins> setting.  An endpoint which receives a "CERTIFICATE_NEEDED" frame but did not advertise support MAY treat this as a connection error of type "CERTIFICATE_WITHOUT_CONSENT". </ins> The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the "half-closed (local)" or "closed" states RFC7540.  A client that
Code change:
though I'm not sure it's yet precise enough. There are three general classes of errors: The peer did something wrong. There are relatively few of these possible -- indicating more certificates to use than were requested, or more than one unsolicited certificate; sending CERTIFICATE_NEEDED to a peer that didn't indicate support for this extension. The authenticator is corrupt. This might indicate a problem with the TLS connection. The certificate isn't acceptable. There are lots of reasons this might happen. The first two should be at least stream and possibly connection errors. The latter should be handled at the HTTP layer, but previously had error codes defined for them. This PR removes several error codes and recommends handling at the HTTP layer if the certificate isn't accepted.
It is very unclear from the draft how exactly the client should handle a secondary server certificate it rejects. Presumably a bad secondary certificate should not be fatal to streams which don't use it. The draft seems to handwaive at this (though not very clearly, which means uncertainty for the server) in section 4. At the same time, the draft says: This is inconsistent with that idea. Suppose the server pushes some CERTIFICATE frame along with some resources it thinks the client would want. If the client rejects that certificate, this text implies the client must tear down the entire connection, interrupting unrelated requests. A useful heuristic for reasoning through all this would be to consider a client which blindly rejects every secondary certificate. This is especially relevant if the draft does not act on .
The restriction on the server is that it not push unless it has first sent the certificate. If the client rejects the certificate, clearly it will discard the push; the question is whether the client will be able to differentiate failure-to-send from cert-not-accepted. That depends on whether you assume that clients will look at the certificates, even if they aren't accepted; otherwise, I suspect that it can't. However, I think you're right that this is an overreaction. RFC7540 requires that a PUSH_PROMISE for an unproven origin be treated as a stream error, but doesn't specify on which stream. The parent stream still seems excessive, since the server can't know for which origins the client considers it authoritative.

Related discussion:
text: Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any). <ins> If the authenticator cannot be validated, this SHOULD be treated as a connection error of type "CERTIFICATE_UNREADABLE". </ins> Once the authenticator is accepted, the endpoint can perform any other checks for the acceptability of the certificate itself. Clients MUST NOT accept any end-entity certificate from an exported
Code change:
Automatic use of client-proffered certificates was removed a while back; clients can indicate which certificate (if any) they want the server to consider by sending a frame with the flag set. There was text talking about automatic use of the server-proffered certificates, but there wasn't corresponding text disallowing that behavior for client certificates, simply the absence of permission. This PR forbids considering "available" certificates until the client indicates which certificate to use.
The secondary certificates draft leaves the authentication state of exchanges like the following unclear: In stream 1, the client is unambiguously using certificate A in the request to . Is it also using it for ? If the client believes the answer is no, while the server believes the answer is yes, secondary certificates introduces a . Some examples to consider: HTTP/2 cross-name pooling means one connection may service multiple origins. The client may choose to use a client certificate with some origins but not others. The web platform makes both anonymous and credentialed requests (see CORS). Keeping those straight is critical to avoid CSRF attacks. For now, browsers do not pool them due to various problematic connection-level auth mechanisms in HTTP/1.1, but there is discussion on relaxing this for the vast majority of connections that don't use these. This puts a heavier dependency on protocols getting these kinds of details right. This is especially important to make unambiguous because the original renegotiation-based hack for reactive client auth did rely on ambient authority. Once you renegotiated with a certificate, the unwritten interpretation was that all subsequent requests on this connection pick up the certificate. A server implementation may then be tempted to apply a similar logic to client certificates. The spec needs a MUST-level requirement not to do this, and make it clear that this is a server security vulnerability. Instead, client wishing to approximate the original renegotiation-based hack would send proactive frames on subsequent credentialed requests. This is especially important for HTTP/2, where there is both larger scope of pooling from cross-name bits and where multiplexing means we requests overlap temporally.

Related discussion:
text: current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <ins> Certificates supplied by clients MUST NOT be considered by servers when processing a request unless the client explicitly authorizes their use.  Clients MAY send "USE_CERTIFICATE" frame with the "UNSOLICITED" flag set to indicate that an available certificate should be considered on a new request. </ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a
Code change:
Automatic use of client-proffered certificates was removed a while back; clients can indicate which certificate (if any) they want the server to consider by sending a frame with the flag set. There was text talking about automatic use of the server-proffered certificates, but there wasn't corresponding text disallowing that behavior for client certificates, simply the absence of permission. This PR forbids considering "available" certificates until the client indicates which certificate to use.
The secondary certificates draft leaves the authentication state of exchanges like the following unclear: In stream 1, the client is unambiguously using certificate A in the request to . Is it also using it for ? If the client believes the answer is no, while the server believes the answer is yes, secondary certificates introduces a . Some examples to consider: HTTP/2 cross-name pooling means one connection may service multiple origins. The client may choose to use a client certificate with some origins but not others. The web platform makes both anonymous and credentialed requests (see CORS). Keeping those straight is critical to avoid CSRF attacks. For now, browsers do not pool them due to various problematic connection-level auth mechanisms in HTTP/1.1, but there is discussion on relaxing this for the vast majority of connections that don't use these. This puts a heavier dependency on protocols getting these kinds of details right. This is especially important to make unambiguous because the original renegotiation-based hack for reactive client auth did rely on ambient authority. Once you renegotiated with a certificate, the unwritten interpretation was that all subsequent requests on this connection pick up the certificate. A server implementation may then be tempted to apply a similar logic to client certificates. The spec needs a MUST-level requirement not to do this, and make it clear that this is a server security vulnerability. Instead, client wishing to approximate the original renegotiation-based hack would send proactive frames on subsequent credentialed requests. This is especially important for HTTP/2, where there is both larger scope of pooling from cross-name bits and where multiplexing means we requests overlap temporally.

Related discussion:
text: If a client receives a "PUSH_PROMISE" referencing an origin for which it has not yet received the server's certificate, this is a stream <del> error (see section 8.2 of RFC7540).  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </del> <ins> error on the push stream; see section 8.2 of RFC7540.  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </ins> 2.3.2.
Code change:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Related discussion:
text: Some algorithms, although registered, have since been found vulnerable: the MD5 algorithm MUST NOT be used due to collision <del> attacks CMU-836068 and the SHA algorithm is NOT RECOMMENDED due to collision attacks IACR-2019-459. </del> <ins> attacks CMU-836068 and the SHA algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>
Code change:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Related discussion:
text: Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  The <del> SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. </del> <ins> SHA algorithm MUST NOT be used as it's now vulnerable to collision attacks IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: obsoleted </del> <ins> Status: deprecated </ins>
Code change:
Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm

Related discussion:
text: However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to <del> collisions attacks, so MD5 MUST NOT be used and SHA-1 is NOT RECOMMENDED for use with "Digest". </del> <ins> collisions attacks, so they MUST NOT be used with "Digest". </ins> 11.3.
Code change:
adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256

Related discussion:
text: 9.2. <ins> Requests without a payload body can still send a Digest field applying the digest algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha- <del> 256" digest-values are the same. </del> <ins> 256" digest-values in the response are the same. </ins> Request:
Code change:
adds an example of a request with no payload body (eg. HEAD) mention an use-case in the Signature section.
NAME do you think this is consistent with content-coding like aes128gcm?
An example of using Digest in a request with no payload body. There is a misconceptions that Digest does not apply to request with no payload body. As it's not a special case URL for sha-256 we can just use Other algorithms are free to define a different computation, and the examples will only be tied to sha-256

Related discussion:
text: A "Digest" field using NOT RECOMMENDED digest-algorithms SHOULD NOT be used in signatures. <ins> Using signatures to protect the Digest of an empty representation allows receiving endpoints to detect if an eventual payload has been stripped or added. </ins> 11.7. When used in trailers, the receiver gets the digest value after the
Code change:
References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.

Related discussion:
text: 1.2. <del> The concept of "selected representation" defined in Section 6 of I- D.ietf-httpbis-semantics makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with I-D.ietf-httpbis- semantics concepts. </del> <ins> The concept of "selected representation" defined in Section 6 of SEMANTICS makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with SEMANTICS concepts. </ins> Basing "Digest" on the selected representation makes it straightforward to apply it to use-cases where the transferred data does require some sort of manipulation to be considered a representation, or conveys a partial representation of a resource eg. <del> Range Requests (see Section 8.3 of I-D.ietf-httpbis-semantics). </del> <ins> Range Requests (see Section 8.3 of SEMANTICS). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.