Subject: [KEYPROV] Giving up on XML DSig => JSON

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Aug 2013 08:53:34 +0200

Since Google doesn't support XSD or XML DSig in Android I began looking at other alternatives.
There were none :-( Now there is :-)

https://openkeystore.googlecode.com/svn/resources/trunk/docs/Enveloped-JSON-Signatures.pdf

Comments are welcome!

Cheers
Anders

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Aug 2013 10:35:42 +0200

You wrote:

> Since Google doesn't support XSD or XML DSig in Android I began
> looking at other alternatives. There were none :-( Now there is :-)
> 

Did you implement JWS or something else?  If the latter, why not JWS?
It seems to be where everyone in the JSON-world is headed.

http://tools.ietf.org/html/draft-jones-json-web-signature-04

/Simon

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Aug 2013 11:54:21 +0200

On 2013-08-29 10:35, Simon Josefsson wrote:
> Did you implement JWS or something else?

I did not use JWS.

> If the latter, why not JWS?

Because JWS is based on in-line signatures of base64-encoded payloads.
This would ruin the readability of the already complex KeyGen2 protocol
and make the switch from XML look bad.

> http://tools.ietf.org/html/draft-jones-json-web-signature-04

Yes, but these guys only work with comparatively simple authorization systems
like OAuth and OpenID.

In addition, KeyGen2 uses a bunch of non-standard constructs including
SM (Secure Messaging) so having a proprietary signature mechanism seems
like a minor problem.

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Aug 2013 13:39:31 +0200

Update: A comparison with JWS was included in the document
as some kind of rationale...

I did not use JWS.

Cheers,
Anders

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 29 Aug 2013 13:55:37 +0200

You wrote:

> This would ruin the readability of the already complex KeyGen2
> protocol and make the switch from XML look bad.

Why can't you hash the data you want to sign, and then use JWS to sign
the hash?  Then you get readability and don't have to invent something
new.  However, your example blob in the PDF is hardly readable, so I
don't fully follow the argument about readability to begin with.

/Simon

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Aug 2013 14:26:45 +0200

> You wrote:
Hi Simon,

> the hash?

Such a thing would still require most of what I have done anyway,
wouldn't it?  I mean, "Reference", canonicalization etc.

Existing JSON parsers probably don't support canonicalization since
this hasn't been an issue until now.  By building-in all that from
the beginning you get a cool and rather smallish system as well.

> Then you get readability and don't have to invent something new.

I actually enjoy inventing new things.  Don't you like my brand new octagonic wheel? :-)

To be a bit more serious: I'm not overly convinced that clinging on
to standards always is the best solution.  I have don my clinging
with XML DSig now and it turned out to be a mistake :-(

It is like PKCS #11 and on-line provisioning; it will never work although
the OASIS PKCS11 TC claims that. Why? Because PKCS #11 wasn't designed for
a remote SO and that is a bit hard to add as an afterthought, not to
mention getting all drivers up-to-date.  IMO - Simply undoable.

> However, your example blob in the PDF is hardly readable, so I

There are blobs but they at least have labels.

Here is the XML version of KeyGen2:

http://webpki.org/papers/keygen2/keygen2.junit.run.html

It is rather pretty (IMO...).  The JSON version will be _almost_
as nice but but only use 1/3 as much code (including third-party
libraries and all).

Cheers
Anders