- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 13 Nov 2018 15:51:30 +1300
- To: ietf-http-wg@w3.org
On 12/11/18 11:33 PM, Sven Neuhaus wrote: > Hello, > > I read the draft dated November 9th 2018 and there doesn't seem to be a way for a publisher to limit what intermediate parties are allowed to transfer the signed content on their behalf. > Why is this necessary? > - the publisher may want an agreement with intermediates to receive the access log for the signed http exchanges they are otherwise not aware of Why is the server distributing its access log in the first place? If you mean an intermediary generating its own "access log" information. Any intermediary can do so regardless of what signing or any protocol specification says. So long as any detail is transmitted, intermediaries can log it. > - the publisher may only trust certain intermediates with the privacy considerations as listed in section 7 > Why is the publisher concerned with intermediaries? If the content is sensitive it should be transmitted only to specific recipients, possibly using encrypted payload types (Content-Encoding:aes) only able to be interpreted by the known recipient. Whatever agreement is in place at a human/political level about where those authorized recipients can send a message needs to be enforced at that same level where the repercussions and incentives can be enacted better. I.e. by legal contract between the publisher and distributor(s). Such details can be configured in software, no need to specify human-level contract details into the transfer protocol itself. > There are probably more reasons why adding a mechanism to only authorize certain intermediates (for example by hostname) is desirable. > There are a lot of _human_ reasons, but not technical ones AFAIK. When the human level needs control over the exact hops a path goes through there are other protocols like TOR that supply such needs. Free flow of messages through any number of intermediaries is a part of the HTTP architecture. As with packet routing it adds a major contribution to the robustness of the protocol against network breakages and delays. FWIW: The Via, Forwarded, X-Forwarded-* mechanisms are/were used by some servers to deny their traffic going through intermediaries. The universal reaction to that has been admin erasing those headers from traffic to get users access to those servers "working" again. AYJ
Received on Tuesday, 13 November 2018 02:51:59 UTC