Re: HTTP Signatures specification updated

On 2014-02-05 22:13, Manu Sporny wrote:
> 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?

Not at this point :-)

> 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

In the meantime the registry does exist; your registration looks right 
to me, although I'd make the "Reference" entry just say "Section 2 of 
this document" (and make the Section # an actual link).

> 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.

You got it right, so the text appears to be sufficient. (note we are at 
-26 in the meantime).

>> 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?

Dunno. The security experts should know the answer.

> ...
>> - 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?

(a) Why do you need the protocol name?

(b) Wouldn't it be wiser to use the full effective request URI?

> ...
>> 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

Concatenated with no delimiter?

>> - 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.

I believe this is going to break with many libraries. It would be wiser 
to leave out leading/trailing whitespace.

> ...

>> Editorial:
>>
>> - In the boilerplate, please say where to send feedback.
>
> Done:
>
> https://github.com/web-payments/web-payments.org/commit/0da85e2066011ab7e9eb8595ecd136affb6a5346

Looks good.

> 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.

You can't change the status.

>> - Please cite the HTTPbis drafts instead of RFC 2616.
>
> Fixed:
>
> https://github.com/web-payments/web-payments.org/commit/83c9cba2a3fc99bef0e71bd0fadeb058b7576966

...should be in the References section.

>> - 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

Because you don't have any references at all it seems :-) See 
<http://greenbytes.de/tech/webdav/draft-reschke-xml2rfc-latest.html#element.references>.

> ...
> 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. :)
> ...

I know little about the use cases. You really ought to solicit feedback 
of the httpauth working group.

Best regards, Julian

Received on Tuesday, 11 March 2014 16:43:39 UTC