Re: Review of JavaScript Object Signing and Encryption (JOSE)

On 08/06/2013 06:31 PM, Kumar McMillan wrote:
>> { ... "signature": { "@type": "EccGraphSignature2013", "creator": 
>> "http://manu.sporny.org/keys/6", "signatureValue": "OGQzNG ... 
>> IyZTk=" } }
> 
> Thanks, I see how it works now. Out of curiosity, how is this a
> valid argument then? from the article: "the most common argument
> against the Secure Messaging spec...is that it lacks the same amount
> of cryptographic algorithm agility that the JWA specification
> provides."

It's a valid argument, just not a very strong one. With JWS and JWE, you
have a bunch of crypto algorithms that are defined in the spec and
basically ready to go. The spec requires that implementations implement
multiple algorithms, and good libraries will implement all of the ones
that the spec declares. So, switching algorithms would just be providing
different parameters to the library you're using and (if the library is
decent), you're good to go.

That said, not all JWS and JWE libraries will implement all algorithms
and you may inevitably have to switch libraries to support some sort of
cryptographic operation that you want to do.

This is one of the reasons Dave Longley has basically had to implement
every popular crypto algorithm in forge (which is used by a number of
the JWS/JWE/JWT libraries in one way or another). Even if you get 90%
coverage, you end up getting requests to put the other 10% in. That
bloats the software and you end up having to implement everything anyway.

That's the reason why we decided to not kitchen sink the Secure
Messaging spec w/ crypto algorithms that we really didn't think were
going to be useful to messaging on the web over the long term.

> It sounds like a custom signature addresses that problem, no?

Yep.

> You can add a custom algorithm in a similar manner for encryption,
> right?

Yep.

Digging a bit deeper, this is related (RSA could fall within 5 years):

http://it.slashdot.org/story/13/08/06/2056239/math-advance-suggest-rsa-encryption-could-fall-within-5-years

It's a bit of a bold claim, but let's assume RSA falls in 5 years. We
would have no choice but to move to ECC. Now, ECC has a number of patent
issues around the technology, but if RSA falls, the US government just
might step in and invalidate the patents due to the cryptocalypse,
allowing us to use ECC w/o a patent cloud looming over us.

At that point, we'd update the vocabulary to use this:

EccGraphSignature2014

We'd update the the signature algorithm to use SHA-256 w/ 256-bit ECCDSA
keys. Implementations would have to implement ECDSA, and I'd expec that
some might front-run the spec and do it anyway just in case (we'd
probably do this in forge). Upgrading would just be a matter of everyone
upgrading their keys to ECC keys (which can be expressed in PEM format,
which is what we use) and then detecting the new signature type and
applying the same Secure Messaging verification or decryption algorithm
to messages.

The spec work would take a day, switching implementations over would
take a week or so (and you wouldn't have to have a hard switch-over
date, it could happen gradually).

>> At present, I think we have production-quality JavaScript, PHP, and
>> Python implementations of the JSON-LD normalization algorithm. It
>> has also been implemented in C++ at one point, but we abandoned 
>> that implementation as no one seemed to be using it.
> 
> This may be a concern for us in mozPay(). Stable JWT libs exist for 
> more languages: Python, Ruby, Node.JS, PHP, Java, and .NET. In each 
> language there are typically multiple JWT libs to choose from. I 
> don't know what the usage is of each but Ruby and Java seem
> important for adoption among our intended audience: back-end web
> developers.

The normalization algorithm could be implemented in a week or two in
Java and Ruby. The JSON-LD Ruby library is written by one of the guys in
the Working Group, so expect an implementation of that waaay before we
go to production w/ any sort of graph signature stuff. A Java
implementation of JSON-LD already exists, so adding the graph signature
stuff to it wouldn't take that long. In the very worst case, our company
could implement both via a short 2-3 week contract work stint.

Also keep in mind that JSON-LD is pre-Candidate Rec. We haven't even
asked for implementations yet, and we already have 5 (that's pretty good
when it comes to a pre-LC spec).

Additionally, if the technology is useful, people will create libraries
for it. If we're creating a financial infrastructure for the world, we
want to use the best technology for the job, even if the implementations
aren't quite there yet. If we build something useful, those
implementations will come.

The question is, do all of the benefits of JSON-LD signatures outweigh
the number of implementations at present, and do we think those
implementations will appear in the future?

>>> When I see key sorting I get a little nervous since non-ascii 
>>> sorting (for example) may not always work the same across 
>>> platforms.
>> 
>> The sorting is done on UTF-8 strings. Are you saying that UTF-8 
>> sorting doesn't work the same across platforms?
> 
> If it's always in UTF-8 then that's probably fine. I have more of a 
> gut reaction than anything else ;) I've seen a fair share of subtle 
> sorting bugs.

Yes, it's always in UTF-8. We haven't seen any sorting issues wrt. UTF-8
and JSON-LD normalization. Somebody speak up if they know of any,
because this is the first time I've heard of there even being a
potential for sorting issues.

> btw, we've already seen some JWT problems where an implementation 
> accidentally used base64 decoding instead of *URL safe* base64 
> decoding (as specified). Reading specs is hard.

Yeah, at last count I think there were something like over 10 different
base64 encoding formats. :)

-- 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 Wednesday, 7 August 2013 00:41:25 UTC