- From: Dave Reynolds <dave.e.reynolds@gmail.com>
- Date: Tue, 01 Mar 2011 14:41:56 +0000
- To: Ivan Shmakov <oneingray@gmail.com>
- Cc: semantic-web@w3.org
On Tue, 2011-03-01 at 20:16 +0600, Ivan Shmakov wrote: > >>>>> Dave Reynolds <dave.e.reynolds@gmail.com> writes: > >>>>> On Tue, 2011-03-01, Peter Frederick Patel-Schneider wrote: > > […] > > >> This thrust for a canonical serialization puzzles me. What problem > >> would a canonical serialization solve? > > > The argument I've heard before is that if you want to sign an RDF > > graph (as opposed to a specific serialization of that graph) then a > > good way of doing that is to sign a canonical serialization. > > > There are at least two weaknesses in that argument, neither fatal. > > > First, it is possible to sign a graph without canonical ordering by > > using a set hash [1]. > > Actually, that one depends on a canonical representation just as > well! The algorithm suggested allows for the hash to be > computed irrespective of the /order/ of the triples, yet it > assumes that both the hashing and verifying party have some > canonical representations for the triples themselves. Good point, too many years since I read that paper. > (Definitely one of the must read papers to anyone interested in > RDF hashing, BTW.) > > > Second, in some applications you don't actually need to sign the graph > > but could sign a particular serialization. > > Yes, but this leads to specific burden on tracking these > serializations, if — and that's one of the points of having > digital signatures — the authenticity of information would have > to be proven to a third party. Sure, hence the phrase "in some applications". Sometimes validating that the document you have processed is the one you were intended to process is all that is required and document level signing can be appropriate then, sometimes you want more. Dave
Received on Tuesday, 1 March 2011 14:43:14 UTC