Re: [http-auth] HTTP Signatures specification updated

Since we're giving feedback on this:

* There are many ways that signatures could be useful in HTTP, and this is just one way. So, "HTTP Signatures" is a terrible name for this; it's way to generic. Please change it. Suggestion: "The 'Signature' HTTP Authentication Scheme' (but see Julian's comment below).

* Abstract - The term 'origin' is defined by RFC6454, and I don't think that's how you're using it here; at best, you're authenticating the client *to* the origin. 

* 1. Introduction - this is a protocol extension, not a protocol in and of itself.

* 1. Introduction - "However, it is common place..." -- this sentence is probably going to get you in more trouble than it's worth :)  Recommend dropping it. Also, you don't cover why Digest auth isn't good.

* 2.1.1.2 algorithm - "The full list of supported signature mechanisms is listed below."  This sort of thing is usually delegated to a registry, so that you don't have to revise the whole spec to modify the list.  Also, "supported" is odd here, because this is a protocol specification, not a product specification.

* 2.1.1.3 headers - Signing the *whole* request-line is a very bad idea, because the HTTP version is a hop-by-hop artefact, not end-to-end. Also, the spacing of the request-line can be irregular. I'd suggest you define how to canonicalise the request method + URI (ideally, the effective request URI, *not* the request-target; see <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-5.5>).

* 2.1.2 Signature String Construction - You need to define how to canonicalise headers before processing, taking into account that headers can recur, have varying whitespace between the field-name, colon and value, whitespace at the EOL and varying line termination.  

* You don't define a corresponding challenge. Your use cases might not require a 401 + WWW-Authenticate, but have you considered that some will want this?

A few more comments below.


On 4 Feb 2014, at 3:40 am, Julian Reschke <julian.reschke@gmx.de> wrote:

> Manu Sporny:
>> In order to make Web Payments (and REST APIs in general) more secure on
>> the Web, this group has been working on extensions to the HTTP protocol
>> so that you can digitally sign HTTP headers and content.
>> 
>> We just pushed an update to the specification and believe that it's
>> ready for public comment. The specification is already deployed in
>> production at Joyent and Digital Bazaar:
>> 
>> http://tools.ietf.org/html/draft-cavage-http-signatures-01
>> 
>> This technology is useful when you just need to make a secure request to
>> your financial provider to transmit money from you to someone else, make
>> a payment, create an invoice, etc. without having to perform a login
>> handshake (OAuth, user+pass, etc.).
>> ...
> 
> Hi Manu,
> 
> find below my feedback:
> 
> Technical:
> 
> 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; it it does not, it shouldn't use the "Authorization" header field.

See especially <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-25#section-5.1.2>. 


> 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.
> 
> 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
> 
> - 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.
> 
> 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'
> 
> - this will make it incredible hard to have more than one extension. why not allow extension specs to use (and register) new parameter names?
> 
> 
> 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>
> 
> 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?
> 
> - Also: what if there are multiple instances of a given field name?
> 
> - What about leading and trailing whitespace in the header field value?
> 
> 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.

This confused me too.

> 
> 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".
> 
> 
> Editorial:
> 
> - In the boilerplate, please say where to send feedback.
> 
> - Please cite the HTTPbis drafts instead of RFC 2616.
> 
> - Please do not cite RFC 2617 except when talking about Basic and Digest
> 
> - s/header/header field/
> 
> - please use symbolic references (xml2rfc PI symrefs="yes")
> 
> - in xml2rfc, you get appendices by putting <section> elements into the <back> element
> 
> - if BNF notation is needed, please use ABNF as defined in RFC 5234.
> 
> - (IANAL) the statement about Public Domain may or may not be in conflict with the Copyright Statement on the front page
> 
> - OAuth reference missing
> 
> - the reference to RFC 3339 seems to be unused
> 
> Best regards, Julian
> 
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 4 February 2014 02:54:56 UTC