Re: invoice and payments spec for bitcoin

On 12/02/12 09:15, Melvin Carvalho wrote:
> Why not JSON?
> 
> Invoice, Payment and Receipt messages could all be JSON-encoded. The 
> Javascript Object Signing and Encryption (JOSE) working group at the 
> IETF has a draft specification for signing JSON data that we could
> adopt and use.
> 
> But the spec is non-trivial. Signing JSON data is troublesome, so
> JSON that needs to be signed must be base64-encoded into a string.
> And the standards committee identified one security-related issue
> that will require special JSON parsers for handling JSON-Web-Signed
> (JWS) data (duplicate keys must be rejected by the parser, which is
> more strict than the JSON spec requires).

Hmm, we'll definitely have to dig into this a bit deeper.

It is true that JSON has to be serialized into something deterministic
in order to sign it... but that is true of any byte stream that needs to
be digitally signed. For JSON-LD, the digital signature process is
explained here, under the section titled Message Signature Algorithm:

http://payswarm.com/specs/source/web-keys/

In the JSON-LD case, the JSON isn't base64-encoded. It is normalized
into NQuads, and then digitally signed (using the algorithm above).

For the duplicate key attack vector, here is an off-the-top-of-my-head
analysis:

1. Duplicate keys are handled in the same exact way across the major
   browser (IE, Firefox, and Chrome). Last-defined wins.
2. There are typically at least two sides to a transaction when a
   digital signature is being used: the sender and the receiver. Both
   sides must serialize the JSON-LD data in the exact same way
   or the signatures will not match.

Rule #1 ensures that major browsers (and the PaySwarm Authority
implementation that we have) will generate matching signatures, throwing
out any old value for duplicate keys and using the new value.

So, even if a processor that doesn't do rule #1 generates a signature,
it will be rejected by the PaySwarm Authority due to rule #2.

If an attacker tries to take advantage of knowledge that the victim is
running a bad processor and will generate a bad signature (and thus
provides the bad signature), the victim won't know, but the PaySwarm
Authority will catch that issue due to rule #2. While the signature
provided by the attacker and the victim are the same, it will not match
the signature calculated by the PaySwarm Authority, and the transaction
will be rejected as a result.

The assertion is still concerning though, so we're going to look at this
pretty closely before the commercial launch and will report back here
once we've completed that analysis.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

Received on Wednesday, 19 December 2012 19:04:35 UTC