W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2013

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

From: Kumar McMillan <kmcmillan@mozilla.com>
Date: Tue, 6 Aug 2013 17:31:44 -0500
Cc: Web Payments <public-webpayments@w3.org>
Message-Id: <D39EA3EB-6199-4878-A0C0-1C72725599E1@mozilla.com>
To: Manu Sporny <msporny@digitalbazaar.com>

On Aug 5, 2013, at 8:02 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 08/05/2013 01:01 PM, Kumar McMillan wrote:
>>> 
> 
> They can still implement it among agents that want to support the new
> encryption scheme. For example, if Elliptic Curve Crypto is desired, the
> digital signature can change from this:
> 
> 
> to this:
> 
> {
>  ...
>  "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 sounds like a custom signature addresses that problem, no? You can add a custom algorithm in a similar manner for encryption, right?

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

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

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.


-Kumar
Received on Tuesday, 6 August 2013 22:32:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:23 UTC