Partial signatures on the Via header

One of the foundational goals of the HTTP Message Signatures draft is that a signed message can be reasonably robust against expected transformations by intermediaries. The editors want some feedback from the experts in the community on a particular transformation: 

It seems that a fairly common case is for an intermediary to add a Via header to a message as it’s passed through. The originating client won’t have access to the value of this header, and therefore wouldn’t be likely to sign it. But an intermediary that adds the Via header might add its own signature covering that header, thereby giving downstream parties some assurance about the identity of the intermediary named in the header. Another intermediary :after: that first one would then add its own Via header, which would break the signature created by the first intermediary. This same process could be repeated N times as a message is passed through different intermediaries for processing.

Previously the HTTP Message Signatures draft had a feature that allowed a signer to sign a list-prefix of [n] items for any list-valued items, designed to allow an intermediary to sign the value of the Via header so-far but indicate that more would probably be added. However, this was defined in terms of Structured Fields, which Via is not defined as. Therefore, the target use case The list-prefix function was removed from the signatures draft because of that mismatch.

With the definition of several new specialty message components in the latest (-06) draft, the editors would like to propose an alternative approach for handling Via headers that might be more robust:

Instead of relying on structured fields directly and trying to make this a general purpose solutions could instead define an “@via” component identifier that takes a single numeric parameter indicating which value of the Via headers are signed. So if you had two Via headers (or one header with two values), you could sign “@via”;index=0 and “@via”;index=1 to indicate the specific values you’re signing. Someone downstream can add their own Via and sign “@via”;index=2, ignoring the other values if they want. 

This could possibly be extended to any list-format header, but it seems to make some sense to call out Via specifically because:

 - It is additive in nature; intermediaries tack on themselves to the existing list (right?)
 - It’s expected to be modified in this specific way most of the time

Since this is pretty specific functionality, it could also be targeted to an extension instead of the core signatures document, or it could just be another specialty identifier added to the current list.

Thanks in advance for your input,

 — Justin and Annabelle

Received on Friday, 10 September 2021 19:55:07 UTC