[foaf-protocols] WebID for signing RDF graphs
tai at g5n.co.uk
Wed Sep 22 00:59:18 CEST 2010
I've been doing a bit of work on this topic this afternoon and here's
what I've come up with:
It's a collection of Perl modules for signing and verification of RDF
graphs. It signs the graph as a whole; not just a serialisation of it.
That is, the same signature should be produced whether you sign the
data as Turtle or RDF/XML.
Here's a nice example:
On lines 10 to 18 you see me create a "Signer" object based on my
private key which is stored as a PEM file. I then use the Signer to
create a "manifest" which lists signatures for a few Turtle files. When
creating the manifest, I provide my WebID <http://tobyinkster.co.uk/#i>
in order that people wishing to verify the manifest can find my public
The manifest is itself an RDF graph, so can be signed.
On line 20, I verify the manifest and on line 21 print out the results.
Verification of the manifest checks each signature in the manifest,
dereferences the WebID used to create the signature, and verifies the
signature against the public key obtained giving a positive, negative or
null result (e.g. if the WebID cannot be dereferenced).
Additionally, I have a mechanism to embedded signatures - i.e.
signatures embedded in the RDF file itself. Clearly, if the signature
were embedded as a triple, it would effect the signature of the graph
as a whole, so instead it's embedded in the file as non-RDF data, using
hash-comments in Turtle, XML comments in RDF/XML and a special
attribute on the document root node in RDFa. This allows the signature
to "travel with" the signed document.
This all seems to work quite nicely. Once I have got encryption and
decryption working, I'll make a release.
For those interested, my signature algorithm is essentially this:
1. Convert the RDF to a canonical N-triples representation
<http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf> using single
spaces between S, P, O and the full stop, and CRLF line breaks.
2. Simply drop any "problematic triples" - i.e. those that cannot be
canonicalised. This is a slight security hole, in that it allows for
certain triples to be inserted into the graph without breaking the
signature, but an attacker is very limited in scope as to what sort of
triples those are. I do have a solution that improves this somewhat,
but still doesn't make things perfect - I've not immplemented it yet
3. Generate an MD5 hash of the result and then sign it using RSA. This
is equivalent to "cat input | openssl dgst -md5 /path/to/privkey.pem".
4. Encode the signature using base64.
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
More information about the foaf-protocols