On 12/16/2013 06:34 PM, Manger, James wrote:
> There might be some nice ideas in the JSON-LD-based Secure
> Messaging. However, a crypto spec that uses encryption without
> authentication (no AEAD), uses raw CBC mode,

The spec has been updated, it uses GCM now.

We thought picking the final authenc algorithm now would be premature.
We had considered that the side-channel attacks would be a problem for
reviewers but hadn't updated the spec because we wanted to have a more
detailed discussion w/ the security community before picking an authenc
algorithm. We may not pick GCM in the end, but just picked that one
right now so that this wouldn't continue to be a distraction.

The spec is rough, implementations lead it by many months. What we're
trying to get feedback on right now is the overall approach. We'll put
more work into polishing up the spec as soon as we've determined that
there are no serious issues with the approach.

> thinks CBC stands for *cyclic* block chaining,

A typo in the spec, fixed.

> puts "BEGIN *PRIVATE* KEY" in a field named publicKeyPem,

A typo in the blog post, fixed.

> requires RDF Graph Normalization that seems far removed from JSON,

We actually started out with a JSON-based normalization algorithm. We
quickly discovered that we could generalize the normalization to not
just JSON, but a general graph-based data model. This is useful when
you're exchanging Linked Data like the Web Payments work does. We are
able to use the same normalization scheme for a variety of Linked Data
languages (JSON-LD, RDFa, Microdata, Turtle, NQuads, etc.). So, one
could express the data in HTML5+RDFa (via a web page) or JSON-LD (via a
REST API) and share the same digital signature since the sig is on the
information and not the structure of the JSON message.

That's not to say that the normalization algorithm couldn't be switched
out pretty easily, but to date we haven't had a need for another one
that is JSON specific. If that need arises, the only modification to the
Secure Messaging spec that would be needed would be to define the @type
of that normalization algorithm. For example:

"signature":
{
  "@type": "JsonSignature2014", <-- this is the only change necessary
  "creator": "http://example.org/manu/keys/5",
  "created": "2013-08-04T17:39:53Z",
  "signatureValue": "OGQzN ... IyZTk="
}

JSON-LD[1] expresses Linked Data[2]. The data model is a graph of
information (like the Web). We digitally sign that information at the
data model layer, not the JSON syntax layer. Doing so allows us to use
the same digital signature across a variety of syntaxes. It's more
flexible than just hard coding the normalization algorithm to JSON.

-- manu

[1] http://www.youtube.com/watch?v=vioCbTo3C-4
[2] http://www.youtube.com/watch?v=4x_xzT5eF5Q

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Worlds First Web Payments Workshop
http://www.w3.org/2013/10/payments/