Re: DOM Tampering and Digital Signatures

On 11/25/2010 02:31 PM, Mark Birbeck wrote:
> What about signing the data via a predicate? If it's absent, a strict
> parser might ignore the triples. And if it's present, its value must
> match a value computed in much the same way that XML Signatures [1]
> work...or perhaps a little simpler. ;)
> 
> In fact...Manu mentioned to me the other day that his company recently
> had need to sign instances of JSON-LD; perhaps we need to look at
> generalising whatever it was that they did.
> 
> Any thoughts on this, Manu? Did you add the signature as a predicate,
> or was it outside of the RDF?

Our solution is specific to JSON-LD, but could probably be generalized
to other serializations of RDF as long as there is a way to normalize
the graph's serialization. We end up performing a single signature on a
specific subject:

{
...
   "ps:asset":
   {
      "@": "http://example.org/articles/1#asset",
      "a": ["ps:Asset", "ps:webPage"],
      "dc:title": "Payswarm Demo - Full Article #1",
      "dc:creator": "Digital Bazaar, Inc.",
      "ps:contentUrl": "<https://example.org/articles/1>",
      "ps:assetProvider": "<http://example.org/person/john-doe#me>",
      "ps:authority": "<http://whitelabel.payswarm.com/about#authority>"
   },
   "ps:signature":
   {
      "a": "ps:AssetSignature",
      "ps:signatureFor": "<http://example.org/articles/1#asset>",
      "ps:signer": "<http://dev.payswarm.com/person/john-doe#key-5>",
      "ps:signatureValue": "05c2c08e...192ef"
   }
...
}

You have to normalize the data in order to do the signature, and the way
that you normalize the data in JSON-LD is by doing the following
operation recursively:

1. Expand all CURIEs to IRIs.
2. Order all vocabulary terms in alphabetical order with their
   associated values.
3. Compress the string to be signed, removing any unnecessary
   whitespace.
4. Hash the string and digitally sign the hash.

So, the signature string would be:

{"@":"http://example.org/articles/1#asset","http://www.w3.org/1999/02/22-rdf-syntax-ns#type":["http://purl.org/payswarm#Asset","http://purl.org/payswarm#webPage"],
...

and so on.

To verify the signature, you fetch the key from
http://dev.payswarm.com/person/john-doe#key-5, do the same serialization
procedure and check to see if the signature is valid. Then you have to
make sure that you trust the key that is signing the data - in this
case, the "ps:assetProvider" URL must create a relationship between it
and the key that performed the signature. All the data is published via
RDFa (asset, keys, etc.) and signed using JSON-LD normalization rules.

To generalize this mechanism, we /could/ provide a mechanism that
outlines which fields are signed. For PaySwarm, there is a signing
algorithm for Assets, Payment information and digital Contracts - the
fields that are to be signed are mentioned in the (yet to be published)
spec. We are currently exploring whether or not this is a good idea.
That is, do we want to digitally sign the entire graph, or subsets of
that graph? We think signing subsets is very useful and is especially
important when financial transactions are at stake. However, we do also
want to provide the ability to add additional fields that can be signed.

We could provide individual statement support like so (note the
"ps:signatureFields" triples):

   "ps:signature":
   {
      "a": "ps:AssetSignature",
      "ps:signatureFor": "<http://example.org/articles/1#asset>",
      "ps:signatureFields":
         ["<dc:title>", "<dc:creator>", "<ps:assetProvider>"],
      "ps:signer": "<http://dev.payswarm.com/person/john-doe#key-5>",
      "ps:signatureValue": "05c2c08e...192ef"
   }

... but note that normalization has to be performed in one way and only
one way. Don't know if this works well for RDF/XML or Turtle.

As you guys have pointed out in this thread - digitally signing graphs
is far outside of our charter. Even writing a note on it, which is
doubtful considering the backlog of work to people that we have,
probably shouldn't be done until we're sure that whatever mechanism that
we describe has some field deployment under it.

Nathan, is it okay with you if we don't start an issue for this? It
would take a very long time to discuss, any data gleaned from a web page
via JavaScript has the same issue as RDFa, and I'm afraid that it would
distract us from getting the RDFa API finished and getting the rest of
the documents through the W3C Process. That is not to say that digitally
signing RDF graphs isn't important, our company certainly needs this
functionality, just that I don't think that we have the time to get it
done given everything else on our plate.

-- manu

> (Once you've finished your turkey, of course.)

:) - The meal was delicious, hope everyone was able to enjoy a good,
home-cooked dinner this week.

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Linked Data in JSON
http://digitalbazaar.com/2010/10/30/json-ld/

Received on Saturday, 27 November 2010 17:16:32 UTC