Re: Giving up on XML DSig => JSON

On 08/30/2013 09:49 AM, Anders Rundgren wrote:
> On 2013-08-30 05:47, Manu Sporny wrote: There are tons of issues 
> here, I almost feel that we should talk over the phone to get more on
> the same page but I try to answer here anyway...

We could add this to the next telecon agenda... although, we did discuss
a big part of this during the last telecon:

https://payswarm.com/minutes/2013-08-21/

I know that voice is better to work some of these things out, but the
downside to that is that the rest of the community can't keep up with
the discussion. I think this discussion is worth having on the mailing
list if you're okay with that. :)

>> On 08/29/2013 12:51 AM, Anders Rundgren wrote:
> I think we both face the same dilemma: Is our respective security 
> solutions private to our "frameworks", or should we engineer them so
>  that they could become standards?

If it seems like the technology could be useful to others, and I think
it can be, then we should engineer it so that they are standards-track.

The Secure Messaging spec (aka HTTP Keys) has been engineered to be
standards-track:

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

It's already marked up in the W3C spec format. The spec itself is a bit
rough around the edges, but there are implementations of it in Python,
PHP and JavaScript:

The JavaScript one is the reference implementation, and it's up-to-date.
https://github.com/digitalbazaar/payswarm.js/

The Wordpress one uses Secure Messaging, but the Secure Messaging
specific code should probably be broken out into its own package:
https://github.com/digitalbazaar/payswarm-wordpress/

The Python implementation is pretty far behind, but we did have it
working at some point. We update this library as we find the time (which
is not that often):
https://github.com/digitalbazaar/payswarm-python

> IMHO, none of the schemes meet the latter goal but I don't think we 
> should be too concerned about that since it is the frameworks that we
> actually work with, right?

With respect to the work we do here, especially since we need digitally
signed JSON for the PaySwarm and Web Commerce API specs, it's important
that we get a spec in good shape to be submitted to the Web Payments
Working Group when it gets started.

> Now over to your specific questions...

To be clear, canonicalization has more to do with JSON-LD Normalization
than it does Secure Messaging:

http://json-ld.org/spec/latest/json-ld-api/#data-round-tripping

http://json-ld.org/spec/latest/rdf-graph-normalization/

>> What do you do with floating point numbers?
> 
> http://lists.w3.org/Archives/Public/public-identity/2013Aug/0004.html

I don't quite understand the answer there. Let me be more specific
about the question. How do you canonicalize these two values?

 "partsPerMillion": 0.000000999
 "partsPerMillion": 9.99e-7

in JSON-LD, it is canonicalized to this string:

"0.000000999"

Unfortunately, there will be issues on 16-bit vs. 32-bit JSON
implementations, but the number of people out there trying to digitally
sign RDF on 16-bit machines is probably non-existent.

>> What do you do w/ leading zeros in integers?
> 
> Verboten

So, the canonicalization algorithm strips them from the input? Or it
converts them to a number that doesn't have a leading zero?

 "comments": 023

In JSON-LD, it is canonicalized to this:

"23"

>> What are the quoting requirements for map keys?
> 
> I'm not sure what that means.

Some parsers allow you to not use double quotes. Are double quotes
always required? Some parsers, like PHP, escape the double quotes like this:

 \"foo\": \"bar\"

So, which form do you use?

>> How are the keys sorted?
> 
> If key means property then: Verboten.

If you don't sort the keys in some way, it won't work. You have to give
order to the JSON map keys as they're fundamentally unordered in JSON.

>> What do you do with control characters in whitespace CRLF vs CR? 
>> Tabs? vertical tabs?
> 
> Interpreting as the RFC specifies.

If you do that, then two documents that look the same end up not
generating the same hash, for example:

 "foo": "bar"

and

 "foo":\t"bar"

This leads to lots of headaches for the developers using the
canonicalization algorithm. All whitespace should really be stripped to
provide the easiest and most error-free form for developers.

>> What do you do with trailing commas?
> 
> Verboten.

Good.

>> What escape sequences are supported?
> 
> All specified but \/

What's the canonical form of these three values?

15\u00f8C
15°C
15\u00f8\u0043

What happens when one document uses one of the forms above, and another
document uses the other form?

>> If you don't have answers to at least all of these questions, your 
>> solution doesn't work. :)
> 
> I believe it works great but it won't work with arbitrary JSON 
> parsers. Given the KeyGen2 specific context it doesn't have to.

That's a problem if it doesn't work with arbitrary JSON parsers. That
means that people will have to write their own JSON parsers, which is a
non-trivial exercise.

Maybe you mean that arbitrary JSON parsers won't canonicalize into the
form you have above natively? If that's the case, then that's fine
because canonicalization is a special operation (since there is no
single way to canonicalize JSON).

One important thing to note w/ JSON-LD's Canonicalization method is that
it works across multiple Linked Data languages - HTML5+RDFa, TURTLE,
JSON-LD, N-Triples, N-Quads, etc. So, you can use the same
canonicalization method regardless of your input document format.

> removes whitespace automatically and that's all you need if you add
> the property order constraint which I forgot to mention.

This seems to contradict some of the stuff you said above, but I'll just
assume that you meant what you say here. All whitespace is removed
(good), properties are ordered.

How are properties ordered? What do you do in the case where there are
two properties?

  "foo": "bar",
  "foo": "bar"

> I also have some questions :-)
> 
> Where can I read about things like @context which seems to be a part
>  of the framework rather than Secure Messaging?

This video is a good introduction to JSON-LD's @context feature:

http://www.youtube.com/watch?v=vioCbTo3C-4

If you want to read more about the feature in the JSON-LD spec, here's
the link:

http://json-ld.org/spec/latest/json-ld/#the-context

> Wouldn't multiple signatures fail to validate?

Not if they're nested, no. For multiple signatures at the same level, we
haven't spec'd that behavior yet mainly because no one has asked for the
feature. We do have a technical solution, which would basically be:
{
  ... data ...
  "signature": [SIG1, SIG2, SIG3]
}

To verify a signature chain, you'd peel off SIG3, verify the message,
peel off SIG2, verify the message, then peel off SIG1, and verify the
message. It works kind of like how certificate chains work.

The downside to this approach is that you can't add data and sign it,
but if you want to do that, you'd embed signature objects inside one
another:

{
  ... data 2 ...
  "data1": {
    ... data 1 ...
    "signature": SIG1
  }
  "signature": SIG2
}

> FWIW, I got quite inspired by your work!!!

Great! :)

> I also have some "constructive criticism" of Secure Messaging which 
> you are free to ignore but here we go...

We welcome all constructive criticism on the spec, it's the only way
it'll improve. :)

> Shared keys have limited use in payment systems but in KeyGen2 they 
> are the the core.

We have discussed a number of issues with shared keys here in the past.
We don't believe they're a good solution for a payment platform because
a read-only compromise at a payment processor would cause a massive
theft of sensitive information (the shared secret). Using public/private
keys, a read-only compromise in wouldn't give the attacker any sensitive
information (from a data signatures perspective).

That said, there is no reason that a shared key can't be used to do the
digital signature in Secure Messaging. We just don't support it in the
core spec because we think there are too many issues with shared secrets.

> Key agility is really only interesting if there is support for it in
>  the protocol. This may be hard to achieve in payment systems.

It's there in the protocol, you can switch algorithms pretty easily. The
hard part is getting consensus on what to switch to. It's pretty easy to
achieve in payment systems as long as the community works together well.

> HTTP Keys in't a very cool name.  I'm looking for a nice name for my 
> own stuff as well.  Still haven't come up with anything :-(

We had to rename it to HTTP Keys from Web Keys because a company
asserted their trademark rights on the "Web Keys" name:

http://lists.w3.org/Archives/Public/public-webpayments/2013Jul/0025.html

We did a quick poll, and the HTTP Keys name was the one that was picked.
A number of us really don't like the name and would rather use "Secure
Messaging". We're going to have to revisit the name at some point as
it's really difficult to give a talk to non-technical folks and mention
"HTTP Keys" in the slide deck. People just don't get what it does.

They do, however, get what "Secure Messaging" is about.

> BTW, I find JOSE's algorithm names somewhat strange (HS256 - 
> really?).  I thought the world had already settled on URIs as the 
> proper way to name things.

Yep, totally agree.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Saturday, 31 August 2013 19:08:57 UTC