W3C home > Mailing lists > Public > public-rdf-wg@w3.org > June 2011

Re: Need for a canonical byte stream for an RDF graph

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 28 Jun 2011 11:45:02 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <1BCA2D54-6270-423A-AFAF-1E5F34F4CEA3@garlik.com>
To: Jeremy Carroll <jeremy@topquadrant.com>
On 2011-06-28, at 01:28, Jeremy Carroll wrote:

> On 6/27/2011 4:07 PM, Steve Harris wrote:
>>> - signature is of length O(N) in the size of the graph (i.e. the signature includes the serialized form)
>> I'm not sure about that. The implementations I'm familiar with - WoT (http://xmlns.com/wot/0.1/), OAuth, and HTTPS - don't require that, at least in a way which is obvious to me. Arguably OAuth and HTTPS don't count, but they're commonly used for HTML, XML, JSON, etc.
> OK
> So with WoT
> Let's suppose I have an RDF Graph in a triple store, to sign it, I need to turn it into a document. This document is of length O(N) in the number of triples. This gives me say a 128 byte signature after a bit of cryptography.
> To verify the 128 byte signature it is not sufficient to have the graph in the triple store (or some other triple store). I also need the document: and not any document containing that RDF graph, but the one that was the input into the cryptographic part of the process. Thus, from the RDF processing point of view, the signature is the 128 bytes and the document used in the serialization.
> Doing the signature verification against my triple store requires me to parse the signing document and do the graph isomorphism between that parse result and contents of triple store
> Thus all the claims I made earlier

That's what I meant about only being able to do the verification at retrieval time.

The process we followed was: (from memory)

1) fetch document from URL
2) check for WoT data
3) fetch WoT data [if present]
4) verify fetched document against WoT data [if present]
5) assert 1 into triplestore [if 4 passed]

At that point, we know that as long as the graph that the data was asserted into isn't disturbed (enforced in the application layer in our case), that the document in 1 has been signed as per 2.

That's probably not sufficient for all usecases, but it suited ours fine, and it doesn't have complexity issues.

For OAuth and HTTPS steps 1-4 are done as part of the implementation of the standard, but for WoT we did them manually.

There's also WebID which maybe fits in there somewhere, as it uses x509 certificates, but I'm not au fait with it. 

- Steve

Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 28 June 2011 10:45:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:59 UTC