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

On 6/29/2011 3:54 AM, Steve Harris wrote:
> On 2011-06-29, at 02:04, Jeremy Carroll wrote:
>
>> On 6/28/2011 3:45 AM, Steve Harris wrote:
>>> 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]
>> Yes this is a good process but has little to do with RDF since it is just about verifying the signatures on the source documents.
>> If this process suffices for the use case it is clearly better to use this.
> OK, thanks, that clears up some questions I had - so, to check my understanding, a C14N-based signing process isn't inherently superior, but it does meet other usecases?
>
> Regards,
>     Steve

Yes - fully agreed. The inherently superior signature method is signing 
byte streams: it is simple, generic, and reasonably well understood. 
However it doesn't do everything.

Personally I think things like XML Sig are overblown. The basic ability 
to sign a byte stream usually suffices (as in your case)
Reasons that you want more than that are things like:
-  you have data in a database that is not inherently in a byte stream
-  you want to have chains of signatures in which reconstructing the 
bytes streams may be hard work, so we can end up with bad complexity issues

I am trying to find the motivations for XML Sig, and am scanning 
workshop papers found here:
http://www.w3.org/2007/xmlsec/ws/papers/

This one
http://www.w3.org/2007/xmlsec/ws/papers/04-hill-isecpartners/
talks about denial of service attacks:

"It is unacceptable that a single or a very few poison messages can be 
used to disable critical business systems in a Service Oriented 
Architecture, or incapacitate the identity provider or single sign on 
gateway for an entire set of web applications and services."

A fundamental issue is that any use case in which a RDF document has 
already been read into a database and then business reasons require the 
later verification of the signature (e.g. for audit), then that business 
process does theoretically embed the graph isomorphism problem somewhere 
(GI). While this is of no practical significance in 'normal' data - it 
can be used in a poison message to disable critical business systems - 
this suggests that whatever method one uses should be robust against 
'hard-to-label' blank nodes.

The XML Sig people also seem to like signatures of signatures, 
overlapping signed segments, .... I don't get the impression that we are 
there yet with RDF data but ...

Jeremy

Received on Wednesday, 29 June 2011 17:11:46 UTC