Http-Signatures

[adrianhopebailie]

Did you consider just using HTTP-Signatures:
https://web-payments.org/specs/source/http-signatures/

If you were aware of it I am interested to know why you felt it was insufficient?

[PierreRochard]

Some more feedback from Manu on this issue:

On 07/03/2014 02:58 PM, Adrian Hope-Bailie wrote:
Am I missing something or is this HTTP-Signatures with a small
twist?

If you're missing something, I'm missing it too. It seems like a really
restricted subset of HTTP-Signatures with a lock-in to the crypto
algorithm and "things that you can sign" with a few major security holes
thrown in.

Features that are missing from the solution that HTTP Signatures has:

• Ability to digitally sign HTTP headers (because you can do a lot of
  nasty things by modifying important headers... like 'Location:' ).
• Ability to not sign the body if that doesn't make sense (like when
  you're streaming GBs of data or using trailers or ...)
• Ability to sign the HTTP method, which is really important:
  GET /me/accounts/life-savings
  DELETE /me/accounts/life-savings
• Ability to identify keys in a greater variety of ways
  (URL, fingerprint, etc.)
• The server can specify when it expects a digital signature when
  accessing a resource.
• Easy to share keys between clusters of clients.
• HMAC support, because there are legitimate uses of it even though
  it's bad in general.
• Ability to select the key format and signing algorithm

I'm going to stop there, but the solution seems questionable. There's
nothing in there that I can see that the HTTP Signatures spec doesn't
already do.

The only thing that makes it similar in any way to BitCoin is the
use of a ECDSA secp256k1 keypair

Bitcoin is great so this must be great if it even uses a fraction of
Bitcoin technology, right? Marketing, marketing, marketing! :P

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

[jgarzik]

It does not seem to be Http-Signatures as the focus appears to be primarily on the data transported. There appears to be the presumption that you are tunnelling data (an underlying protocol) sufficiently able to handle issues related to message replay and MITM. e.g. the protocol being tunnelled includes a nonce and other protections.

On the plus side it is much closer to transport independence. You can argue whether it is positive or negative to keep HTTP metadata out of the security envelope.