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.