Re: [http-auth] Review Request for third draft of "Signing HTTP Messages"

Dear Manu,

> We've had to avoid specifying the mandatory use of scheme, port, and
> hostname because there are edge cases where proxies that want to check
> the signature before proxying the request on would generate the improper
> signature string during the check. We recommend the following
> pseudo-headers in the current spec:

Could you explain a bit more about the "edge case"?
IMO, the hostname is quite essential for the verification
of message source in any cases, even though the
intermediate reverse-proxy is deployed.

Even in the existence of the reverse-proxy, the end server
could generally know how the content is delivered to the client
(iow, for which URL the client is requesting a resource),
even though the actual URL the proxy is requsting for
the server is different from that.
As far as this holds, there is no problem for including
the host part to the signature.
(Also, it is anyway required for generating 3XX responses,
 Refresh: header and other absolute URLs from applications.)

Our Mutual-Auth proposa  has a slightly resembling
requirement (for verifying the source host of the response).
The server-side module has a configuration parameter
for the host-string and TLS certificate hash,
which will override the default values acquired from
the server configuration and used for generation of
verification tokens, and it works.


2014-09-16 10:31 GMT+09:00 Manu Sporny <msporny@digitalbazaar.com>:
> On 07/27/2014 09:38 PM, Mark Nottingham wrote:
>>> Whitespace around field values is not included. The spec now refers
>>> to the appropriate section in draft-ietf-httpbis-p1-messaging-26:
>>>
>>> https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b18deebb30f4d4b03d4b4a75
>>>
>>>
>>>
>> Is this straight concatenation, or with a comma?
>>
>> E.g., if you have
>>
>> Cache-Control: max-age=60 Cache-Control: must-revalidate
>>
>> Would the canonicalised string be:
>>
>> Cache-Control: max-age=60must-revalidate
>>
>> or
>>
>> Cache-Control: max-age=60,must-revalidate
>>
>> or...?
>>
>> While your text isn't ambiguous really, people are very used to
>> concatenate-delimit-with-comma (plus some whitespace, usually), and
>> it might be good to point out what you mean (even if with an
>> example).
>
> I've updated the spec to clarify
> concatenate-delimit-with-comma-plus-single-space character and added an
> example to make sure we're crystal clear in the spec about this:
>
> https://github.com/web-payments/web-payments.org/commit/921c90dbd1a1c92ac2e56dadf9ef82669fd4dd02
>
>> What I'd suggest is to actually use the :-prefix that http/2
>> specifies, because it can't be part of a valid http header
>> field-name. The method isn't part of the request-target, so that
>> would leave you with these "special" header field names:
>>
>> :method :uri
>>
>> For :uri, I'd refer to the Effective Request URI in RFC7230 Section
>> 5.5; that's the concept you're looking to hook onto, I think, and it
>>  should be stable between HTTP versions.
>
> I couldn't find the :-prefix pseudo header in RFC7230 or
> draft-ietf-httpbis-http2-14. Using the effective Request URI would
> include the protocol scheme and host in the signature string and could
> break checking the signature in certain http->https proxy scenarios
> (among others), right?
>
> We've had to avoid specifying the mandatory use of scheme, port, and
> hostname because there are edge cases where proxies that want to check
> the signature before proxying the request on would generate the improper
> signature string during the check. We recommend the following
> pseudo-headers in the current spec:
>
> :method :path
>
> Is that an issue?
>
>>>> * Can trailers be included in a signature?
>>>
>> Cool. Note that the Trailer header
>> <http://tools.ietf.org/html/rfc7230#section-4.4> already allows this;
>> e.g. you'd have:
>>
>> Trailer: Signature
>>
>> to indicate that Signature is coming in the trailers.
>
> Oh hey, that's way better, thanks!
>
> If you're good w/ the changes we've made above, then the comments on the
> spec have slowed down to the point that we're going to do a final call
> for implementations to get the 4 current libraries updated to the latest
> version of the spec and get any other new implementations started.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth



-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Received on Saturday, 20 September 2014 02:48:36 UTC