Signatures: Canonicalized Structured HTTP Fields

[rogerk-unifysquare]

While adding support for canonicalized structured HTTP fields to our library I've found that there seems to be some issue with knowns and unknowns causing inefficiencies by design. Consider the following scenario:

We have to verify a signature for which a component "x-custom-header";sf is included. Since we do not know what the field_type (according to section 4.2 of RFC 8941) of x-custom-header is, we have to resort to trying all of them according to the algorithm outlined in that section 4.2, i.e. we would first try list followed by dictionary, followed by item.

While this is of course perfectly possible, it seems inefficient by design, and I'm wondering if it wouldn't be better to pass the field_type as a parameter to this structured field component (e.g. include it as a value to the sf parameter, like "x-custom-header";sf=(list|dictionary|item)), so that for verification we know what we should expect for this component? After all, when serializing this for signing (according to section 4.1 of RFC 8941), we also need to know if we're dealing with a list vs dictionary vs item, right?

[jricher]

You definitely shouldn't be looping through all the types. If you don't know the type, the signature generation should fail, just like parsing/serialization of the field should fail according to RFC8941 if you don't know the type ahead of time. In our implementation we're using the table in the Retrofit draft, which will eventually be put into the HTTP Header registry: https://www.ietf.org/archive/id/draft-ietf-httpbis-retrofit-04.html#name-compatible-fields

[rogerk-unifysquare]

Thanks Justin. That helps for structured fields that are known upfront, but it still leaves the issue for custom headers. Would your implementation fail if a user were to add the sf parameter for any custom headers?

[jricher]

My implementation would fail because it wouldn't understand the custom header's type, but my implementations have all been pretty application-specific so far. In the library versions of my code, I plan to make that table configurable, or at least extensible, but I haven't gotten to that level of configuration in my own code yet.

I'm having a hard time explaining exactly why, but it feels dangerous to allow this level of choice at the application layer. From RFC8941 you are expected to know the type of the field ahead of time to properly process it, and that seems like the right approach for signatures to take as well.

[rogerk-unifysquare]

Thanks Justin, your explanation makes perfect sense and I think I understand your reasoning. I agree that knowing the headers used in the signatures is important. Or put differently: why include a header in a signature when the header is not understood?

I will consider an approach with a preconfigured table of headers too, and then reject headers (at least with the sf flag) when they're not known. Thanks a lot for taking the time to explain!