Re: Giving up on XML DSig => JSON

On 2013-08-30 05:47, Manu Sporny wrote:

Hi Manu,
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...

> On 08/29/2013 12:51 AM, Anders Rundgren wrote:
>> Therefore I
>> created system that writes and reads JSON from Java. In addition, I
>> adopted a scaled-down version of XML DSig's enveloped-signatures.
> 
> Did you look at the Secure Messaging spec (digital signatures for
> JSON-LD)? It looks pretty close to what you've done. Here's a fairly
> complete comparison between JOSE and Secure Messaging signatures:
> 
> http://manu.sporny.org/2013/sm-vs-jose/

I haven't seen that before and it was *very* interesting!

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?

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?


>> The concept of enveloped signatures have been slammed by some people
>> due to a belief that canonicalization issues will be hard.


Now over to your specific questions...

> What do you do with floating point numbers?

http://lists.w3.org/Archives/Public/public-identity/2013Aug/0004.html


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

Verboten


> What are the quoting requirements for map keys?

I'm not sure what that means.


> How are the keys sorted?

If key means property then: Verboten.


> What do you do with control characters in whitespace CRLF vs CR? Tabs?
> vertical tabs?

Interpreting as the RFC specifies.


> What do you do with trailing commas?

Verboten.


> What escape sequences are supported?

All specified but \/


> 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.


>> Why bother with this you may wonder?  Well I can't imagine converting
>> the previous cool stuff to something yucky like JOSE's JWS:
> 
> That's one of the issues that we had with JOSE JWS.
> 
>> Canonicalization (=removal of whitespace):
> 
> Canonicalization isn't just the removal of whitespace, there are a
> number of other concerns (outlined above). Interesting in hearing what
> you have to say about Secure Messaging and JSON-LD digital signatures.

The current 250-line parser
https://code.google.com/p/openkeystore/source/browse/library/trunk/src/org/webpki/json/JSONParser.java
removes whitespace automatically and that's all you need if you add the property order constraint
which I forgot to mention.

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?

Wouldn't multiple signatures fail to validate?

FWIW, I got quite inspired by your work!!!  I'm thinking of doing a major revision
and make signatures implicitly sign the JSON object they are contained in.  By
doing that I can remove the "Reference" and maybe nuke another 50 lines of
code.  However, that would require a new message structure to be useful since
the current builds on a top element that is alone and of course the message
element must be signeable.

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

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

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

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 :-(

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.

Cheers
Anders


> 
> -- manu
>

Received on Friday, 30 August 2013 13:50:32 UTC