Re: HTTP Signatures specification updated

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.

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.

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

Received on Monday, 3 February 2014 16:41:20 UTC