W3C home > Mailing lists > Public > public-webpayments@w3.org > September 2014

Re: Review Request for third draft of "Signing HTTP Messages"

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 20 Sep 2014 09:54:17 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, Mark Cavage <mark.cavage@joyent.com>, "Julian F. Reschke" <julian.reschke@gmx.de>
Message-Id: <C7A9521B-8670-4689-991E-279935615412@mnot.net>
To: Manu Sporny <msporny@digitalbazaar.com>
Hey Manu,

Thanks for following up. Some responses below.

On 15 Sep 2014, at 6:31 pm, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> 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

I think thatís pretty good. There are some quibbles that might come out in review later, but itís pretty good. (hint: theyíll likely come from Julian).


>> 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?

I meant <http://http2.github.io/http2-spec/#PseudoHeaderFields>

Specifically, :scheme :authority and :path.

WRT breaking the signature in proxy situations ó yes, it will, and Iíd argue that thatís the responsibility of the people doing that reverse proxying. The origin (scheme, host, port) is CRITICAL in the Web security model, and leaving it out of any signature scheme simply doesnít make sense.


> 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?

See above.


> 
>>>> * 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/

--
Mark Nottingham   http://www.mnot.net/
Received on Saturday, 20 September 2014 16:54:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:39 UTC