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

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