jiebi/CodeConvo huggingface dataset:
Code change:
This document designates the following headers, defined further in header and chain-header respectively, to carry the client certificate <del> information of a mutually-authenticated TLS connection from a reverse proxy to origin server. </del> <ins> information of a mutually-authenticated TLS connection.  The headers convey the information from the reverse proxy to the origin server. </ins> 2.1.

Related discussion:
text: attempt NAME "simple alternative" in to say the chain is in the same order as it appears in TLS rather than copying the language from TLS
There's a bunch of text in the draft about putting the certificate chain in the right order. This tries to crib from TLS and ends up being somewhat tricky to get right as TLS has a bunch of carefully worded and - frankly - ambiguous rules. As a simple alternative, how about we just state that the certificates need to appear in the same order as the client sent them in TLS.
Makes sense. Will look at adjusting the text accordingly.
I think this is a bit more fundamental than just the order. It's really a question of whether this is a certificate path, or a pile of input certificates to run verification over. That is, either: The origin runs path building, taking the unordered/unverified pile of input certificates from the header, in TLS order. The proxy runs path building and passes the result in the header. The origin assumes a path has been built and is merely applying ACLs based on some aspect of the resulting path. A mismatch here could result in security issues. For instance, suppose the origin wants to only allow chains issued by intermediate certificate I1 to access . If the header means (1) but the origin expects (2), this ACL is trivially bypassable: Client has a certificate chain EE -> I2 -> CA. Client connects to proxy and sends {EE, I2, CA, I1}. (Or perhaps {EE, I2, I1, CA}. Or whatever else. Different verifiers are differently permissive about path-building. Perhaps it omits I2 altogether and the path-builder picks it up some other way.) Even if the proxy runs certificate verification, a path-building verifier will build the EE -> I2 -> CA path and just consider I1 as a random unused certificate. , per the TLS order rule, contains {EE, I2, CA, I1} Origin server checks this and concludes "aha, this was issued by I1 and can access the resource". Conversely, the semantics are (2), the proxy needs to have enough information to validate the certificate, up to a valid trust anchor for the application. If you all intended to punt that to the origin, that's a different protocol.
Code change:
This document designates the following headers, defined further in header and chain-header respectively, to carry the client certificate <del> information of a mutually-authenticated TLS connection from a reverse proxy to origin server. </del> <ins> information of a mutually-authenticated TLS connection.  The headers convey the information from the reverse proxy to the origin server. </ins> 2.1.

Related discussion:
text: If the spec says TLS order, it's implicitly saying the interpretation is (1). But as that leaves a security-critical check to the origin, it should be explicit about this. Also, as it leaves all certificate validity to the origin, it'd need to further define an error-handling story to properly tell the client the certificate was invalid. But I know of no client that uses HTTP-level errors to clear client certificate decisions, only TLS alerts. I think (2) may be a more robust/compatible.
It is definitely 1. You do 2 and you don't need this client-cert-chain field at all. That doesn't mean that a proxy can't be configured to do the work and pass the info along. But one of the two needs to be in the hook for enforcement. A consequence of 1 is that alerts at the TLS layer won't be used to signal errors, aside from those that the proxy detects (or has to, like if the signature is invalid). That is ok, mostly. The main protocol issue here that might be a problem is validation of signatureschemecert. I can't see how failing to validate that would be a significant problem though.
In on the PR that introduced the chain I was aiming for 2. But eventually relented to MT. Some additional considerations about the security implications are likely warranted though.
I see. If it's (1), that should probably be clearer in the draft. That also means the draft needs to define an error-signaling scheme. Moreover, if the proxy doesn't then translate that error into TLS alerts, we'd need changes in clients for servers relying on this to work right. I'll file a bug.
I ran into real reservations as I looked at making this change. I still don't like pushing the trust chain validation to the origin. For many reasons. The proxy also has no means of signaling to the client which trust anchors the origin is okay with. The current text is somewhat ambiguous about what goes in Client-Cert-Chain but I think that's actually better than saying it has to be same as in the TLS handshake. I dunno, I think I might raise the question of WTF actually goes in Client-Cert-Chain at the next interim or real meeting.
At the last virtual interim (in May/June yikes!)
Code change:
This document designates the following headers, defined further in header and chain-header respectively, to carry the client certificate <del> information of a mutually-authenticated TLS connection from a reverse proxy to origin server. </del> <ins> information of a mutually-authenticated TLS connection.  The headers convey the information from the reverse proxy to the origin server. </ins> 2.1.

Related discussion:
text: Martin kindly suggested that I was making this too complicated and to just make the change (paraphrasing). I've tried to do that with changes in PR .
This works well enough on the critical points. Some points about readability though.
Code change:
4. <del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the </del> <ins> This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. </ins> <del> claim in the JWT.  Use of the JWT Issuer Metadata is OPTIONAL. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 4.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: </ins> <del> JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer </del> <ins> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: 5. This specification defines the JWT VC Issuer Metadata to retrieve the JWT VC Issuer Metadata configuration of the Issuer of the SD-JWT VC. The Issuer is identified by the claim in the JWT.  Use of the JWT VC Issuer Metadata is OPTIONAL. Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer </ins> Metadata configuration available at the path formed by concatenating the string

Related discussion:
text: If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.
Code change:
5. <del> As this document covers the Digital Map concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </del> <ins> As this document covers the SIMAP concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </ins> designing the solution. 6.

Related discussion:
text: Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters
Code change:
lowercased identifier followed with a colon "":"", a space "" "", and the identifier's canonicalized value (described below). <del> If Covered Content contains "(created)" and the signature's Creation </del> <ins> If Covered Content contains "*created" and the signature's Creation </ins> Time is undefined or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error. <del> If Covered Content contains "(expires)" and the signature does not </del> <ins> If Covered Content contains "*expires" and the signature does not </ins> have an Expiration Time or the signature's Algorithm name starts with "rsa", "hmac", or "ecdsa" an implementation MUST produce an error.

Related discussion:
text: Replaced unstructured header with and Dictionary Structured Header Fields. Defined content identifiers for individual Dictionary members, e.g., . Defined content identifiers for first N members of a List, e.g., . A signature in a request now looks like this:
I like this PR! We just need some tweaks, but it greatly improves the way the spec can be used.
This PR also fixes . Should we remove that appendix in this PR?
Redefine the Signature header field to use . This will simplify both the definition and the parsing of this header field value.
The Covered Content list, Algorithm, and Verification Key identifier should all be part of the Signature Input, to protect against malicious changes.
The Covered Content list contains identifiers for more than just headers, so the parameter name is no longer appropriate. Some alternatives: "content", "signed-content", "covered-content".
I like the direction this PR is taking: spec is more focused because it outsources spec of field format to draft-kamp-httpbis-structure dictionary format is more flexible and allows multiple signatures (important)
Code change:
CONNECT. A CONNECT request message does not have content.  The interpretation <del> of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </del> <ins> of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: … might be allowed by consenting adults
My previous comment:
NAME you pushed back on MUST. My position is that our task is to define what's interoperable in HTTP, and bodies on GET clearly aren't. Using SHOULD here is a concession to a vocal minority who want to use the protocol in this way because they have pairwise agreements; I understand that if we use MUST here it'll be violated, but that puts the responsibility squarely and unambiguously on their shoulders. NAME point is valid -- if we use SHOULD, that ought (ha!) to be contextualised. To do so here, we'd need to write something like: The problem is that the message can still be handled by software that isn't party to or aware of that negotiation -- especially, intermediaries. So this isn't really something we should be encouraging. Hence, MUST.
I continue to disagree for the reasons you cited me above. Explaining the "SHOULD NOT" would work for me. If you want a change here, we might want to get those involved who actually use it in practice.
NAME please disambiguate 'above'.
The 'people who use it in practice' are not using HTTP -- they're building private protocols based upon it that don't interoperate with normal HTTP implementations. What they're doing breaks HTTP and HTTP implementations.
RFC 7231: "A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request." I disagree that makes an implementation sending content "not HTTP". You are pushing for a change here, and I really believe you need better arguments to support that. If the intent is to discourage things like that, I'm all in, but using "MUST NOT" is not likely to achieve that goal.
We got here because the 7231 language was ambiguous enough that people misinterpreted it, so we added a RFC2119 requirement. Our AD is rightly pointing out that if we use SHOULD, we need to contextualise it with when it's acceptable to violate the requirement. What text do you propose to perform that function?
"A client SHOULD NOT generate content in a GET request, unless support for content is negotiated (in or out of band)." sounds good to me
As I explained above, that won't work. Out-of-Band negotiation isn't available to intermediaries.
Code change:
CONNECT. A CONNECT request message does not have content.  The interpretation <del> of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </del> <ins> of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: In-band negotiation is the SEARCH method (or whatever it ends up being called); it would be strange for the WG to allow other methods of negotiation when it's working on how to accommodate this properly. Also, while we place the requirement on the client here, realize that the impact here is really on the server -- it must not require a request to have a body in order to interoperate, because that precludes the client from using otherwise conformant HTTP implementations and infrastructure.
How so? Could you please clarify that? Are you saying that intermediaries are allowed to drop the payload? Where do we say that?
This discussion is not about future code, but about existing, deployed code which currently works for people, and which IMHO is not strictly forbidden by the existing spec. In past discussions, we agreed on strengthening how we discourage this, but a "MUST NOT" is very different from a "SHOULD NOT". For instance, do you expect HTTP libraries that currently support request bodies on GET to stop doing that, although there's production code relying on it?
No, I'm saying that the pressure we see to allow bodies on GET is being placed upon clients by servers who create services that use it, doing so because they read the current ambiguous language and find enough wiggle room to think it's allowed and a good idea. This is because the power dynamic between a client and server is often unbalanced, especially for APIs. It does not work in an interoperable fashion on the scale of the Internet - which is what we're documenting. Those are private agreements. The fact that it's not strictly forbidden is how we got here. Not any time soon, but those libraries aren't supporting HTTP in doing so; they're effectively supporting the creation of new, HTTP-derived protocols. How about:
Not following. It does work for some people (maybe because they use HTTPS or control the request path by other means). Saying that if something does not work "on the scale of the Internet" then it's not "HTTP" or shouldn't inform our spec does not work for me. If this was the case, we really would need to start removing many more pieces from the protocol. Also, telling libraries that they should stop supporting a use case that was allowed (with care) in RFC 2616 and 723x and which is used in practice doesn't look right to me.
Code change:
CONNECT. A CONNECT request message does not have content.  The interpretation <del> of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </del> <ins> of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: We are past WG LC and IETF LC; if you really really want to change this normative requirement now (instead of explaining the SHOULD), then you should get support for that on the mailing list.
What I mean is that if you create a resource that uses a body on GET, you can't just use any HTTP implementation - you have to find one that does bodies on GET. Here, 'implementation' includes the framework in use, the server software, reverse proxies, CDNs, description languages, etc. Likewise on the client side; it's no longer a HTTP service, in that I can use any HTTP client; I have to find one that supports this extra constraint. Furthermore for proxies I might want to use, etc. Effectively, it's HTTP+GETBODY, not HTTP. It's not an extension, because it's not backwards-compatible. You say it's "used in practice", but as far as I see it, it's a few large services using their popularity / market power to convince people to break the protocol. That ignores the security and interoperability issues that this practice brings. Practically no one uses , but that doesn't matter. This does. If you can suggest a qualification for the SHOULD that doesn't compound the problem, I'm all for it. Absent that, I'll take it to the list.
Also, looking at the text in situ, I think the current second sentence doesn't need modification, leaving the proposal as:
... and since we've tried to align this language in HEAD and DELETE, the change would also be made there.
I really disagree with changing this. There are enough mentions on the net about "what happens if I send a body with a GET" that it's pretty sure we're going to declare a few in-house deployments non-compliant. For example we could imagine that some local deployments use a request body for an auth scheme. We could even more imagine this with H2. And with H2-to-H1 gateways, the risk of seeing a request body with a GET is even higher. The real problem with this spec is that from the very early days we only say how to emit but much less what to receive, and that many implementors on the receive path tend to take the server's "MUST NOT" for granted and ignore corner cases.
Code change:
CONNECT. A CONNECT request message does not have content.  The interpretation <del> of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </del> <ins> of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: Marking a MUST NOT here would certainly re-open some smuggling issues just because some implementors would be less careful about this and would never check the presence of a content-length. So I definitely agree with Julian here, I'd rather keep the "SHOULD NOT unless negotiated by other means" at least to make sure everyone remains careful about this. Last, I'd rather not make GET such a special method after all the work we've done in 723x to try to uniformize processing for all of them! And as seen in a recent issue, at least both Apache and HAProxy deal fine with bodies in GET requests.
Maybe we split the difference -- there are certainly plenty of instances of "MUST NOT... unless..." in IETF specs.
I'm fine with this approach.
Am 16.07.2021 um 16:03 schrieb Mike Bishop: Hmmm. A "MUST NOT, unless..." really seems to be a "SHOULD NOT", no? Best regards, Julian
I think there's a difference, but it's subtle. "SHOULD NOT" implies that there are valid reasons you might choose to violate the spec, and describes what you should consider in making that choice. "MUST NOT unless" is an absolute prohibition outside of the described circumstance. I think Mark makes an excellent case for an absolute prohibition in the absence of prearranged support.
With that said, that will still declare all 723x-compliant gateways non-compliant, because they will emit this if they receive it. I'm really embarrassed by this last minute change considering the time spent on this during 723x before reaching that situation :-/
That is the very definition of a different protocol though. Why not just "MUST NOT" then?
It is HTTP. Is has not been forbidden in HTTP. It works in certain scenarios, and these are deployed. We can't undo that, even by "yelling". If we want to discourage people from doing this in new protocols, a "SHOULD NOT" wtih explanation is just right.
Right now you could use curl as the client, haproxy as the gateway and apache as the server and all of them would happily process this without a sweat because it properly respects the messaging. Regarding the semantics, it's up to the application making use of that to define it.
Code change:
CONNECT. A CONNECT request message does not have content.  The interpretation <del> of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </del> <ins> of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: Actually it is even already used and documented: the broadly used ElasticSearch explicitly documents how to perform JSON search requests using : URL So please let's stick to "SHOULD NOT" with Julian's "unless negotiated via other means" or something like this, instead of suddenly adding dangerous exceptions to the protocol and breaking interoperability between already deployed and working components.
Code change:
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. <del> Considerations related to message syntax, parsing, and routing are discussed in Messaging-security.considerations. </del> <ins> Considerations related to caching are discussed in Caching- security.considerations and considerations related to HTTP/1.1 message syntax and parsing are discussed in Messaging- security.considerations. </ins> The list of considerations below is not exhaustive.  Most security concerns related to HTTP semantics are about securing server-side

Related discussion:
text: " Considerations related to message syntax, parsing, and routing are discussed in Section 11 of [Messaging]." Make clear that these are only the HTTP/1.1 considerations. Optionally add links for HTTP/2 and HTTP/3.
Code change:
4. <del> To be added. </del> <ins> 4.1. Authorization Servers SHOULD follow the OAuth 2.0 Security Best Current Practice OAUTH2-BCP for client authentication. </ins> 5.  References

Related discussion:
text: Added a section in the security considerations to address topic raised by
Comment from Kelly: A.2.(D) I think AS in domain A at least SHOULD authenticate to AS in domain B. We have it as a MUST.
Perhaps this can be done in the security considerations.