- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 20 Jul 2014 20:45:35 -0400
- 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 05/18/2014 08:33 PM, Mark Nottingham wrote: > This is looking pretty good IMO. Hey Mark, sorry for the very delayed response to your comments. My four day jobs got in the way. Responses and fixes below. > * 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. Done: https://github.com/web-payments/web-payments.org/commit/406758440f22291f115fc54cd6491572dcf6a393 > * 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. It's the default value if no 'headers' are specified. It is not always in the set of headers. For example, if the developer doesn't include it in the list of headers, it's not automagically added. I've tried to clarify the text: https://github.com/web-payments/web-payments.org/commit/c25f8c5c969f5500c3fd7868d98a5989bde0b1c8 > * 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) 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 > * 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. Are you asking me to: 1) Change the name `(request-line)` to something else like `(request-target)`? 2) Specify that the header field value should be constructed by concatenating the lowercased :method, an ASCII space, the :authority, an ASCII space, and :path pseudo-headers? I'm assuming that you think that :scheme shouldn't be included because it'll break when proxied internally between https->http? Speaking about proxies, isn't using :authority going to break the signature from hop-to-hop? Is it worth specifying that servers sitting behind a proxy should use the X-Forwarded-Host or Forwarded-Host headers as a replacement for :authority when recreating the signature? Now I'm wondering if there is an attack that allows an attacker to inject both X-Forwarded-Host and Forwarded-Host that would result in a compromised signature. I made both changes above, let me know if that's not what you wanted. https://github.com/web-payments/web-payments.org/commit/495584b09f88acd439734fcfa9f9826bf40173c3 > * Can trailers be included in a signature? In theory, yes. We've got another spec in the works about how to do this (although it's horribly out of date and we don't know if we're going to finish it any time soon... not much demand for it as far as we can tell): https://web-payments.org/specs/source/http-signature-trailers/ I imagine that if/when we do, we'll require something like this header: Signature: location=trailer and then have the actual signature in the trailers. > * Can a Signature header be included in the message trailers? In theory, yes. We need to spec exactly how this would work. The feature was deemed low-priority and out of scope for the base Signing HTTP Messages spec. > * 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. I tried to clarify by adding two sections. The first specifies how a signature is created, and the second specifies how a signature is verified: https://github.com/web-payments/web-payments.org/commit/d535b92c05f676c040c3e4efd417bd2e5b68ef68 ... but don't know if that's what you were looking for. Thanks a bunch for the input, let me know if some of the changes aren't in line w/ what you wanted. -- 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/
Received on Monday, 21 July 2014 00:46:07 UTC