Re: HTTP Signatures specification updated

On 02/03/2014 11:40 AM, Julian Reschke wrote:
> find below my feedback:

Hi Julian, thanks for the feedback, responses to you feedback with some
additional questions below.

> 1) The spec seems to be confused about whether it defines an HTTP 
> authentication scheme or not. If it does, it needs to follow the 
> requirements in 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-25.html#authentication.scheme.registry;
>
> if it does not, it shouldn't use the "Authorization" header field.

The specification started out as a way for clients to authenticate
themselves to the origin. We've had a few requests to use the same
general approach for the origin to authenticate certain parts of the
HTTP message back to the client (which can be useful over non-TLS
connections, or if you want to have extra security on top of TLS for
Pervasive Monitoring scenarios).

If we wanted to use the mechanism for both client-to-origin signatures
and origin-to-client signatures, what would you suggest that we do? We
could introduce a new header "Signature", that can be used by both
clients and origins, but didn't know if that would be the proper
approach. Thoughts?

For the time being, I think I've followed the requirements in the
draft-ietf-httpbis-p7-auth-25 spec. It's unclear exactly how I should
specify the registration. The registry doesn't exist yet. So I've added
an IANA Considerations appendix noting the requirement for a
registration to be made if the spec makes it through the IETF process:

https://web-payments.org/specs/source/http-signatures/#appendix-d

It would be helpful if the text in ietf-httpbis-p7-auth-25 gave an
example of how one does this, or linked to an RFC that describes how to
do this.

> 2) REQUIRED.  The `algorithm` parameter is used if the client and
> server agree on a non-standard digital signature algorithm.  The full
> list of supported signature mechanisms is listed below.
> 
> -  This should be aligned with other IETF specs using algorithm
> names.

The algorithm names are aligned w/ RFC6376:

http://tools.ietf.org/html/rfc6376

JOSE chose to use different algorithm names. Which IETF specs should we
align with, they're both current, no?

> 3) OPTIONAL.  The `headers` parameter is used to specify the list of 
> HTTP headers used to sign the request.  If specified, it should be a 
> quoted list of HTTP header names, separated by a single space 
> character.  By default, only one HTTP header is signed, which is the 
> `Date` header.  Note that the list MUST be specified in the order
> the values are concatenated together during signing.  To include the
> HTTP request line in the signature calculation, use the special
> `request- line` value.  While this is overloading the definition of
> `headers` in HTTP linguism, the request-line is defined in RFC 2616
> [RFC2616], and as the outlier from headers in useful signature
> calculation, it is deemed simpler to use `request-line` than to add a
> separate parameter for it.
> 
> - just state that the list order is significant for the signature
> algorithm

Done. I moved the explanatory text further down in the document.

https://web-payments.org/specs/source/http-signatures/#headers

> - for request-line, just pick a name that is guaranteed not to
> conflict (such as "(request-line)"). That being said, the request
> line is gone from HTTP/2, and it might be good to break the
> information down into components that are more generic.

Would still calling it "(request-line)" be fine and the state that for
HTTP2, the request line is built using the method, path, and the string
"HTTP/2"? For example:

GET /foo HTTP/2

would be the request line generated for creating and validating signatures?

> 4) OPTIONAL.  The `extensions` parameter is used to include
> additional information which is covered by the request.  The content
> and format of the string is out of scope for this document, and
> expected to be specified by implementors.
> 
> - the BNF says 'ext'

Removed the parameter based on your feedback below:

> - this will make it incredible hard to have more than one extension.
> why not allow extension specs to use (and register) new parameter
> names?

That's a better idea, fixed:

https://web-payments.org/specs/source/http-signatures/#appendix-b

> 5) REQUIRED.  The `signature` parameter is a `Base64` encoded
> digital signature generated by the client.  The client uses the
> `algorithm` and `headers` request parameters to form a canonicalized
> `signing string`.  This `signing string` is then signed with the key 
> associated with `keyId` and the algorithm corresponding to 
> `algorithm`.  The `signature` parameter is then set to the `Base64` 
> encoding of the signature.
> 
> - Which base64? Please pick a concrete on, such as the one defined
> in <http://tools.ietf.org/html/rfc4648#section-4>

I picked the one you mentioned:

https://web-payments.org/specs/source/http-signatures/#signature

> 6) 1.  If the header name is not `request-line` then append the 
> lowercased header name followed with an ASCII colon `:` and an ASCII
> space ` `.
> 
> - And the field value?

Fixed:

https://web-payments.org/specs/source/http-signatures/#canonicalization

> - Also: what if there are multiple instances of a given field name?

Added guidance if there are multiple instances:

http://sites.local/web-payments.org/specs/source/http-signatures/#canonicalization

> - What about leading and trailing whitespace in the header field
> value?

They are preserved, we want to stay as far away from canonicalizing the
headers as we can. If a library, client, proxy, or server adds/removes
whitespace, then the application is screwed. Canonicalization of header
field values is something we do not want to specify, even if it means
that signatures in some environments will fail.

That said, if this becomes a major issue, then an extension
specification can deal with it (or we can rev the spec to include some
basic canonicalization). Unfortunately, at that point we're firmly in
DKIM-Signature territory. One of the goals of this specification is to
not be more complex than necessary.

I added a note to mention that header field values must not be modified:

https://web-payments.org/specs/source/http-signatures/#canonicalization

> 7) Digest: SHA-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
> 
> - If this is the Digest header field defined in 
> <http://tools.ietf.org/html/rfc3230#section-4.3.2> then the spec
> should say so.

Fixed, the spec now refers to that RFC (although, informally as
Digest isn't required for the spec).

https://web-payments.org/specs/source/http-signatures/#canonicalization

> 8) Error handling: as this is relevant for security, the spec needs
> to state how to handle ambiguous values, such as multiple occurrences
> of the same parameter name in "Authorization".

The specification now states what to do w/ multiple occurrences of the
same Signature parameter in the Authorization header:

http://sites.local/web-payments.org/specs/source/http-signatures/#ambiguity

It also describes what to do with multiple header fields:

https://web-payments.org/specs/source/http-signatures/#canonicalization

Is there a list somewhere of other sorts of error handling that should
be taken into account with HTTP?

> Editorial:
> 
> - In the boilerplate, please say where to send feedback.

Done:

https://github.com/web-payments/web-payments.org/commit/0da85e2066011ab7e9eb8595ecd136affb6a5346

Although, I don't know if I added the note in the right way. The W3C
spec tool allows you to modify the Status section, I couldn't find out
how to do that w/ the xml2rfc tool.

> - Please cite the HTTPbis drafts instead of RFC 2616.

Fixed:

https://github.com/web-payments/web-payments.org/commit/83c9cba2a3fc99bef0e71bd0fadeb058b7576966

> - Please do not cite RFC 2617 except when talking about Basic and
> Digest

Done:

https://github.com/web-payments/web-payments.org/commit/6f97a12df79619b8eb264db8ce209ef149c30598

> - s/header/header field/

Fixed:

https://github.com/web-payments/web-payments.org/commit/e8c14fa0b2fdc291473f1aa7302281e4915ee66e

> - please use symbolic references (xml2rfc PI symrefs="yes")

I thought I was, but the xml2rfc tool doesn't seem to be picking it up?

https://github.com/web-payments/web-payments.org/blob/6f97a12df79619b8eb264db8ce209ef149c30598/specs/source/http-signatures/index.xml#L17

> - in xml2rfc, you get appendices by putting <section> elements into
> the <back> element

Fixed:

https://github.com/web-payments/web-payments.org/commit/e3ea00aa4e75b6791647baa2a0b5eecaeb87a72b

> - if BNF notation is needed, please use ABNF as defined in RFC 5234.

Fixed, I think:

https://github.com/web-payments/web-payments.org/commit/937875db36e7799fafdfd6b5c4e35fb9e0a7df79

> - (IANAL) the statement about Public Domain may or may not be in 
> conflict with the Copyright Statement on the front page

Fixed:

https://github.com/web-payments/web-payments.org/commit/0d21fa41cf9fec2aa06007919aca8bceefa13d28

> - OAuth reference missing

https://github.com/web-payments/web-payments.org/commit/774c7842f5c76e32e565f26303763e1c155242eb

> - the reference to RFC 3339 seems to be unused

Removed the reference.

Thanks a bunch for your input Julian, it really helped clean up the spec!

It would be great to hear your thoughts on whether this spec should
continue to use the Authorization header or if it should try to do
origin-to-client authentication as well. We'd like to do the latter if
there is a simple, clean way to do it. It would be nice if the HTTP
message information passed back from the financial servers that would be
using this spec could be digitally signed as well. Answers to the other
questions asked would also be greatly appreciated. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/

Received on Wednesday, 5 February 2014 21:13:42 UTC