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

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 15 Sep 2014 21:31:19 -0400
Message-ID: <541792E7.5030300@digitalbazaar.com>
To: Mark Nottingham <mnot@mnot.net>
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>
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:


> 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
Received on Tuesday, 16 September 2014 01:31:51 UTC

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