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

On 2011-06-29, at 18:11, Jeremy Carroll wrote:

> 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."

I don't quite follow the logic there. I would expect it would be easier to bring about a denial of service if C14N is required? You could just send hard-to-canonicalise data (e.g. very deep tree, which requires rearrangement), with a bogus signature.

> 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.

Yep.

> 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 ...

I have to say that we've done a bit of work with XML Sig (in SAML requests), and from what I gather it's really tricky to work with, and the libraries that implement it aren't particularly well written. I don't know to what extent it's just difficult, and to what extent it's an engineering problem.

- 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 Thursday, 30 June 2011 11:32:06 UTC