Re: Updated: Re: Giving up on XML DSig => JSON

On 2013-08-31 21:30, Jeffrey Walton wrote:
> Hi Anders,
> 
> I think these are personal nits, so take them with a grain of salt.

Hi Jeffrey,
I hope you don't mind me putting all your questions in a single response.

The naked truth is that I was a total JSON newbie just weeks ago and did
some assumptions that turned out to be dead-wrong.  I "thought" that JSON
properties were comparable to XML elements and yes, there _are_ parsers that
can deal with multiple instances of the same property and maintain strict
sequences as well. But the JSON experts told me (mostly in a nice way)
that this would be a bad foundation for a new system.

So JSON properties are rather like XML attributes.  I got that now :-) :-)

So lets focus on the details...

Properties and Sorting
======================
Parsed messages should not depend on any particular order of properties.
Canonicalization must therefore do this step.  This "new" constraint
didn't exactly kill the system, a single flag and line did the trick:

for (String property : sort ?
  new TreeSet<String> (object.properties.keySet ()).descendingSet ()
                      :
  object.properties.keySet ())
  {
  }

Detached Signatures
===================
JCS (JSON Clear-text Signature) was only designed to cope with
JSON-based messaging.  I takes a committee to "improve" a system so
that it covers everything.

Version
=======
Good idea, it's there now!

I have cleaned-up the document considerably based on the input I got.
I think that most if not all of your issues should be covered now.

Cheer
Anders

https://openkeystore.googlecode.com/svn/resources/trunk/docs/Enveloped-JSON-Signatures.pdf
> 
>> Canonicalization:
>> - Sort properties
> So, does that mean I reject anything that is not sorted? I'm happy to
> do so if that's the rules.
> 
> If properties must be sorted, then I will process a message as so:
> "properties must be sorted; these are not sorted; its not a well
> formed message; reject".
> 
>>     "Now": "2013-08-30T07:56:08+02:00",
>>     "ID": "lADU_sO067Wlgoo52-9L",
>>     "STRINGS": ["One","Two","Three"],
>>     "EscapeMe": "A\\\n\"",
>>     "Intra": 78,
> These are on the same level, but not sorted. I would reject this message.
> 
> If people are going to following it as if its a suggestion, then you
> might as well leave it out.
> 
>>         "SignatureValue": "MEYCIQCCAxLBoPw5h8hW4M...L5t0XscOTPWXE67c1SCT"
> I would prefer something that acts more like a detached signature.
> MessageSignature could be the tuple {MessageId, SignatureValue}, with
> MessageId acting like a [untrusted] hint.
> 
> But again, this is just my personal preference.
> 
> Jeff
> 
> On Sat, Aug 31, 2013 at 2:57 PM, Anders Rundgren
> <anders.rundgren.net@gmail.com> wrote:
>> Hi,
>> Based on the _extremely_ useful feedback received, I have decided to update the proposed clear-text JSON Signature scheme.
>>
>> Canonicalization:
>> - Remove whitespace
>> - Unescape "strings"
>> - Sort properties
>>
>> Signature scope: a JSON Signature signs the object (including possible child objects) it is declared in.
>>
>> That is, the final XML DSig "leftover", the awkward Reference has been shelved.
>> I expect the resulting code to be even shorter than today :-)
>>
>>    {
>>     "@context": "http://example.com/test-signature",
>>     "Now": "2013-08-30T07:56:08+02:00",
>>     "ID": "lADU_sO067Wlgoo52-9L",
>>     "STRINGS": ["One","Two","Three"],
>>     "EscapeMe": "A\\\n\"",
>>     "Intra": 78,
>>     "Signature":
>>       {
>>         "SignatureInfo":
>>           {
>>             "Algorithm": "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256",
>>             "KeyInfo":
>>               {
>>                 "SignatureCertificate":
>>                   {
>>                     "Issuer": "CN=Demo Sub CA,DC=webpki,DC=org",
>>                     "SerialNumber": 1377713637130,
>>                     "Subject": "CN=example.com,O=Example Organization,C=US"
>>                   },
>>                 "X509CertificatePath":
>>                   [
>>                     "MIIClzCCAX+gAwIBAgIG...RBYG3uk9W/uNIHdoyQn19w=="
>>                   ]
>>               }
>>           },
>>         "SignatureValue": "MEYCIQCCAxLBoPw5h8hW4M...L5t0XscOTPWXE67c1SCT"
>>       },
>>   }
>>
>> The sample shows the new KeyGen2 message structure which has been derived from JSON-LD (@context)
>>
>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/Enveloped-JSON-Signatures.pdf

Received on Sunday, 1 September 2013 04:57:17 UTC