Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mention HTTP Message Signatures (for #2286) #2310

Merged
merged 2 commits into from Nov 11, 2022
Merged

Mention HTTP Message Signatures (for #2286) #2310

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
02fcd5c
Mention HTTP Message Signatures (for #2286)
bc-pi Nov 10, 2022
c778826
less use of the word standard
bc-pi Nov 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
11 changes: 8 additions & 3 deletions draft-ietf-httpbis-client-cert-field.md
View file
Open in desktop
Expand Up @@ -50,6 +50,8 @@ informative:
display: HTTP/2
RFC9114:
display: HTTP/3
I-D.ietf-httpbis-message-signatures:
display: HTTPSIG

--- abstract

Expand Down Expand Up @@ -341,7 +343,10 @@ ways, which will vary based on specific deployments. The communication between a
TTRP and backend or origin server, for example, might be authenticated in some
way with the insertion and consumption of the `Client-Cert`
and `Client-Cert-Chain` header fields occurring
only on that connection. Alternatively the network topology might dictate a
only on that connection.
{{Appendix B.3 of ?I-D.ietf-httpbis-message-signatures}} gives one example of
this with an application of HTTP Message Signatures.
Alternatively the network topology might dictate a
private network such that the backend application is only able to accept
requests from the TTRP and the proxy can only make requests to that server.
Other deployments that meet the requirements set forth herein are also possible.
Expand Down Expand Up @@ -471,10 +476,10 @@ could inject its own values that would appear to the backend to
have come from the TTRP. Although numerous other methods of detecting/preventing
field injection are possible; such as the use of a unique secret value as part
of the field name or value or the application of a signature, HMAC, or AEAD,
there is no common general standardized mechanism. The potential problem of
there is no common general mechanism. The potential problem of
client field injection is not at all unique to the functionality of this draft,
and it would therefore be inappropriate for this draft to define a one-off
solution. In the absence of a generic standardized solution existing currently,
solution. In the absence of a generic common solution existing currently,
stripping/sanitizing the fields is the de facto means of protecting against
field injection in practice today. Sanitizing the fields is sufficient when
properly implemented and is a normative requirement of {{sec}}.
Expand Down