Wrapping problematic fields for signatures #2189
Conversation
|
In general, is this even needed or are we over-engineering here? If the main use case is |
|
|
||
| ### Binary-wrapped HTTP Fields {#http-header-byte-sequence} | ||
|
|
||
| If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in {{security-non-list}}, the signer MAY include the `bs` parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. |
There was a problem hiding this comment.
This is not a MAY, it's at least a SHOULD because not using it would result in a security issue.
There was a problem hiding this comment.
I'm actually fine with this being a SHOULD for the reasons given.
| If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in {{security-non-list}}, the signer MAY include the `bs` parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. | |
| If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in {{security-non-list}}, the signer SHOULD include the `bs` parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. |
|
|
||
| ### Binary-wrapped HTTP Fields {#http-header-byte-sequence} | ||
|
|
||
| If the value of the the HTTP field in question is known by the application to cause problems with serialization, particularly with combination of multiple values as discussed in {{security-non-list}}, the signer MAY include the `bs` parameter in a component identifier to indicate the values of the fields need to be wrapped as binary structures before being combined. |
There was a problem hiding this comment.
If we are aware of other common fields that need to be handled this way, let's list them in {{security-non-list}} as well.
There was a problem hiding this comment.
Set-Cookie is the only common one that I found that fits this, but I didn't want the language to preclude other weirdness out there.
| 1. For each field value in the set: | ||
| 0. Strip leading and trailing whitespace from each item in the list. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this will be a no-op in a compliant implementation. | ||
| 1. Remove any obsolete line-folding within the line and replace it with a single space (" "), as discussed in {{Section 5.2 of HTTP1}}. Note that this behavior is specific to {{HTTP1}} and does not apply to other versions of the HTTP specification. | ||
| 2. Encode the string as a Byte Sequence |
There was a problem hiding this comment.
What does this mean? Maybe: encode the list as a structured field Byte Sequence using the list's ASCII representation. (This assumes that only ASCII is allowed, but that's really part of the problem.)
There was a problem hiding this comment.
@mnot is this an accurate way to say "take the header value as a binary"? To create the examples I encoded the strings, and field values are already a subset of ASCII characters allowed.
| 2. Encode the string as a Byte Sequence | |
| 2. Encode the resulting field value's ASCII representation as a Byte Sequence |
This adds a binary wrapper for fields that don't follow the List or Dictionary format for multiple values, such as Set-Cookie. The wrapper is selected
using the
bsparameter, and the component value is made by wrapping each individual field value in a Byte Sequence and putting them into a List, thendoing a strict serialization on those values.
Closes #2166