Re: http signature and WebID

On 10/13/2015 04:10 PM, henry.story@bblfish.net wrote:
> • In section 3.1 is written [[ The following sections also assume 
> that the "rsa-key-1" keyId refers to a private key known  to the 
> client and a public key known to the server. ]] it is a bit weird to 
> have a string refer to two different things simultaneously. It seems 
> like a way to pave the way for confusion. ( Just a worry )

Another way of stating this is that "this is a key identifier that can
be used by both the client and the server".

What do you think about this text instead?

"""
The following sections also assume that the "rsa-key-1" keyId identifies
a public/private keypair that can be used by the client to create
digital signatures and by the server to verify digital signatures.
"""

> • What about an upload mechanism to allow a client to upload its 
> certificate to the server, so as to not require the communication to 
> depend on another server being up. Proposed one option for this here:
>  
> https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0388.html

We've identified key registration as specifically out of scope for the
HTTP Signatures spec. A number of organizations do it in different ways.
We do mention a key registration protocol in the LD Signatures spec, but
that registration protocol should probably be removed into its own spec:

https://web-payments.org/specs/source/ld-signatures/#the-key-registration-process

> • keyId: It would be useful if the client could make sure when the 
> KeyId could be a dereferenceable URL. This would allow a client to 
> not have to upload the certificate when making a connection. 
> Something like that is described in: 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0388.html

Again, out of scope for HTTP Signatures. We're trying to keep the spec
lightweight. In general, though - if the keyId is a URL, the assumption
is that it is dereferenceable and data should exist at the endpoint. For
example, here's one of my keys that I should be able to use in an HTTP
Signatures exchange:

curl -sk https://dev.payswarm.com/i/manu/keys/4

> It may just be best if the spec was clear that the keyId must be a 
> URI, but could be a relative one, which may be access controlled,
> and so only known to the server itself. Otherwise one is not quite
> sure how to interpret this.

The keyId is meant to be an opaque string. That opaque string can be
interpreted by other specs and systems in more specific ways. Again,
trying to limit the complexity in the HTTP Signatures spec while
enabling other specs to build on top of it.

> • Headers maintenance over transport:
> 
> 'If there are multiple instances of the same header field, all
> header field values associated with the header field MUST be
> concatenated, separated by a ASCII comma and an ASCII space `, `, and
> used in the order in which they will appear in the transmitted HTTP
> message.'
> 
> - what is the chance that proxies actually somehow reorder or add 
> headers to a message sent?

Proxies do stuff like this on a regular basis.

> Is there an RFC that actually states this should not be done?

Not that I know of, no. Even if there was one, there is plenty of
evidence that proxies rewrite headers.

> re JS libs: do they keep the order of headers or other such things. -
> what are the headers that XMLHTTPRequests clients can actually
> control? ( Is there perhaps a howto somewhere for these types of
> issues ? ) - for POSTing, or PUTing of larger contents I suppose the
> JS may not at all be in control of the number of chunks by which the
> content is sent, so the Content-Length field may only be calculatable
> very late in the game.

In general, the way we've approached this problem is to tell people not
to sign things that may be modified by proxies. You want the signature
to fail if data is modified in transit. If all else fails, you can add
your own header that merges the data you want to sign into an
application-specific header. There are solutions out there to the
"proxies ate my data" problem.

> • reference to HTTP/2 incorrect
> 
> If the header field name is `(request-target)` then generate the 
> header field value by concatenating the lowercased :method, an ASCII 
> space, and the :path pseudo-headers (as specified in HTTP/2, Section 
> 8.1.2.1 [5]). ... [5] 
> http://tools.ietf.org/html/rfc3447#section-8.2.1
> 
> but RFC3447  "Public-Key Cryptography Standards (PKCS) #1: RSA 
> Cryptography" does not have anything about :method
> 
> I think the reference was meant to be to 
> https://httpwg.github.io/specs/rfc7540.html "8.1.2.3 Request 
> Pseudo-Header Fields"

Hmm, the link was wrong, but didn't point to what you state above. In
any case, I've updated the link to point to the latest RFC:

https://github.com/web-payments/web-payments.org/commit/75231c102c7b92426d6183422190adcdcf5d0454

> • Is there a test suite? I need to build one, but would be happy if
> I could verify against another one.

Unfortunately, no. That's been on our to-do list for a long time.

> It would be worth having a web page that lists howtos and other uses 
> that go beyond the RFC. It could also list such other protocols. 
> Those don't seem to be correctly specified, but knowning that Amazon 
> has something similar makes a pretty good case for it.

The one from Amazon looks close to the HTTP Signatures spec because
that's where it came from (originally). Quite a bit has been changed
since then, but Mark Cavage (one of the co-authors on the spec), based
it off of a lot of hard lessons he learned at Amazon wrt. signing HTTP
messages.

Thanks for the review of the spec, Henry, that was very helpful. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/

Received on Wednesday, 14 October 2015 03:07:20 UTC