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

Hi Manu,

This is looking pretty good IMO.

A bit more feedback:

* I think you need to strip out all of the motivation text (i.e., substantial portions of 1.x); it makes claims that are hard to justify about how this helps with pervasive monitoring, and it also omits a lot of other potential uses for the spec. Just keep it simple.

* Section 2.1.3 - Is Date the default value if no ‘headers’ is specified, or is it always in the set of headers? It isn’t clear from this text.

* Section 2.3. - How is whitespace around field-values handled — is it included in the value or not? Note that as per <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26#section-3.2>, it isn’t (but it would be good if you made this explicit, both in spec and with examples)

* Section 2.3 - Request-line is HTTP/1 specific, and — again — the HTTP version is a hop-by-hop attribute of the message, so you’re going to get signature failures through intermediaries. Suggestion: use HTTP/2’s :method, :authority and :path pseudo-headers.

* Can trailers be included in a signature? Can a Signature header be included in the message trailers?

* You talk (often implicitly) about how a signature is created, but not what constitutes a valid signature. This is going to be especially important for the authentication scheme.



On 9 May 2014, at 7:41 am, Manu Sporny <msporny@digitalbazaar.com> wrote:

> After feedback from Mark Nottingham[1], Julian Reschke[2], folks in the
> HTTP Auth WG, and people in the Web Payments CG, we've modified the HTTP
> Signatures specification in the following ways:
> 
> 1. The specification has been renamed to "Signing HTTP Messages".
> 2. The specification now covers both a signature-based Authorization
>   mechanism (client-to-server) as well as a general mechanism to sign
>   HTTP messages (client-to-server and server-to-client).
> 3. A new "Signature" header has been introduced.
> 4. The layout has been modified heavily to streamline the information
>   conveyed in the spec.
> 5. New registries have been created for the algorithms referred to in
>   the specification.
> 6. We're now more specific in the way certain canonicalizations are
>   performed.
> 7. More examples have been added, including how to digitally sign
>   the body of an HTTP message.
> 
> The basic mechanism of generating the signatures has not changed (and
> has been stable for over a year).
> 
> The newest spec can be found here:
> 
> http://tools.ietf.org/html/draft-cavage-http-signatures-02
> 
> The diff is here:
> 
> http://tools.ietf.org/rfcdiff?url2=draft-cavage-http-signatures-02.txt
> 
> Matt, Yoav, Kathleen, if there are no show stopping review comments, I'd
> like to push this spec onto the RFC track in the HTTP Auth WG, or
> HTTPbis/2 WG. It'll be ready for a LC in a month or two. I realize that
> HTTP Auth may be shutting down next month, so what's the next step to
> get the HTTP Signatures spec further down the IETF RFC track?
> 
> -- manu
> 
> [1] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0038.html
> [2] http://lists.w3.org/Archives/Public/public-webpayments/2014Feb/0036.html
> 
> -- 
> 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 Monday, 19 May 2014 00:34:23 UTC