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

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

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 05 Aug 2013 21:02:03 -0400
Message-ID: <52004B0B.9030607@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
On 08/05/2013 01:01 PM, Kumar McMillan wrote:
>> Bottom line: The Secure Messaging specification utilizes a much 
>> simpler approach than the JWA specification while supporting the 
>> same level of algorithm agility.
> 
> I am still a little uneasy at how Secure Messaging describes only one
> algorithm for signing/encryption. What if someone decides they want
> to support a different encryption scheme but they cannot get
> consensus on it? 

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:

{
  ...
  "signature":
  {
    "@type": "GraphSignature2012",
    "creator": "http://manu.sporny.org/keys/5",
    "signatureValue": "OGQzNG ... IyZTk="
  }
}

to this:

{
  ...
  "signature":
  {
    "@type": "EccGraphSignature2013",
    "creator": "http://manu.sporny.org/keys/6",
    "signatureValue": "OGQzNG ... IyZTk="
  }
}

Note that the only change is to the type of the signature, all other
data remains the same.

> Are they out of luck or could they make a custom
> context (or something) to support their own algorithm in their own
> system?

They just make a custom context. Really, they just need to add one entry
to the context. They could do it like this:

{
   "@context": [
     "https://w3id.org/security/v1",
     { "EccGraphSignature2013": "https://w3id.org/mysignatures/v1#ecc" }
   ],
   ...
}

The code above layers one more term on top of all of the ones provided
by the Security Vocabulary. They could do that, or they could do
something like this:

{
   "@context": "https://w3id.org/foo-application/v1",
   ...
}

The document located at the context URL above would declare the
EccGraphSignature2013 term.

> If there is consensus on a new algorithm then how do existing
> systems transition to the new algorithm? Can messages with the old
> algorithm pass through a new system?

Existing systems would add support for the new algorithm while not
removing the code path for the old algorithm. Messages using the old
algorithm would continue to be supported while the transition is
occurring. At some point, it will become too much of a risk for systems
to support the old algorithm. Typically, a move to the new algorithm was
triggered by the discovery of a security vulnerability in the old algorithm.

We could say that support for the old algorithm would have a hard sunset
date, but approaching technical upgrades based on sunset provisions
rarely happen on the timeline that a Working Group would like to see.
So, the fallback is to depend on the market to decide when the risk of
using the old algorithm isn't worth the cost of the algorithm being
compromised. For example, a PaySwarm Authority has a damn good reason to
care about the soundness of the digital signature algorithm because if
it's broken, then money starts being sucked out of the system without
the owner's consent via forged transactions.

> I like how JSON-LD uses URLs to define a context. You mention that
> because of this there is no need to define JWT claims (issued time,
> expiration time, etc). Is this because you would just define a custom
> context with parameters like expirationTime?

Yes. With Secure Messaging and JSON-LD, it's all just machine-readable
data that is signed. There's no concept of a claim because everything in
the data is a claim of some sort or another (it's just a list of
facts... of information).

If you want an expiration time, then you include such a thing in your
context and use it in your data. If a vendor needs to declare the number
of copies you purchased for a 3D-printable file, then they declare that
in their context and they use it in the data. There's no need for a
specification to declare exactly what a Claim Set consists of.

> I like how JSON-LD
> results in unambiguous JSON structures and how it has localization
> support.

+1

For those that don't know the benefits of these aspects of JSON-LD:

Unambiguous JSON structures allow you to write software that can work
with fuzziness. That is, while the application won't be able to
understand the entire data blob, it can still understand enough of the
structure to process it. So, take the case where a 3D printable file is
being sold. The asset can describe the dimensions of the file, printers
that it's compatible with, materials that can be used to print the
asset, curing time, etc. None of this information is probably going to
be used by the payment processor, however, the information will be
preserved and can be used by the 3D printing software.

For example, PaySwarm can understand enough about the financial and
licensing aspect of it to perform a sale of it. The printing software
can then use the digital receipt (which contains the asset and licensing
description) to send the print job to the proper printer.

Localization support allows you to create one asset that is multilingual
capable by default. So, say you're creating a Web App for sale. Using
JSON-LD, you can include the English, French, Japanese, Mandarin, Tamil,
and Afrikaans title and description in a single asset description in a
standard way.

> As for unencoded JSON vs. base64 encoded JWTs, the non-trivial
> normalization algorithm worries me a bit. Has this been a practical
> issue in any of the JSON-LD libraries yet?

Nope, not yet. There have been 6 different implementations of the
normalization algorithm over the years (at different points in its
development process). Nobody has really complained about it... in fact,
I think we're the ones that typically warn people about it because it's
an easy part of the spec to miss.

The normalization algorithm is much like SSL and TLS. That is, all you
need is an implementation in your language of choice and you never have
to know or care how it works.

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.

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

> It is nice to glance at a log
> and read an input string rather than have to base64 decode it though.
> OTOH, most HTTP data is already base64 encoded and our technology
> stacks (like web servers) hide that from us in logs and such.

While that's true, when you're writing software using JWS/JWT/Secure
Messaging, you will inevitably have a problem that you have to debug
that won't be in any log.

Printing out the object you're working with is much easier if you don't
have to then also base-64 decode strings (that may or may not be binary
data, as is the case with JWT). In Secure Messaging and JSON-LD, we only
base64 encode binary data... all other data remains as cleartext (and
thus easily debuggable).

-- 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 Tuesday, 6 August 2013 01:02:36 UTC

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