Re: Thinking on Endorsement use case

On Wed, 2012-01-18 at 09:33 -0800, Gavin Carothers wrote:
> On Wed, Jan 18, 2012 at 7:36 AM, Sandro Hawke <sandro@w3.org> wrote:
> > What threat model is addressed by either the hash or the signature that
> > isn't address by using a bnode (and no crypto)?   (maybe answer in
> > telecon; I probably wont read email before then.)
> 
> If Alice wishes to clearly identify what it is she's endorsing, and
> doesn't want someone else to change it for her she needs to use a name
> that clearly refers to the exact triples she wishes to endorse, and
> provide a way of verifying that Alice said she endorsed them. The
> simplest and widely accepted way of uniquely identifying an exact set
> of bytes for endorsement is by using a hash. This has wide deployment
> in not only identifying bundles of bytes, but in the case of magnet
> URIs in RESOLVING to a bucket of bytes.

I love secure hashes, but I don't see how they help in this use case.
Let's try adding some more details:

 1. As you said, Bob provides some triples, at a URL he controls

   At http://example.org/bob/foaf.ttl, we have this document:

     @prefix foaf: <http://xmlns.com/foaf/0.1/> .

     <#me> foaf:name "Bob",
           foaf:homepage <http://mytotallyfakesite.com> .

 2.  As you said, Alice publishes a statement that she endorses one of
     Bob's triples, at a URL she controls.  I think the following will
     do it, using a TriG/REST design.  (It's even easier with TriG/Equality
     or with Explicit-Relations.)

     At http://example.org/alice/foaf.ttl, she says:

       @prefix foaf: <http://xmlns.com/foaf/0.1/> .
       @prefix foo: <http://example.org/foo/>

       { <#me> foo:endorces <g7732>.
         <g7732> a rdf:StaticGraphContainer. }

       <g7732> { 
          <http://example.org/bob/foaf.ttl#me> foaf:name "Bob" .
       }

     I think best practice would be to put that triple at
     http://example.org/alice/g7732, or use a non-dereferenceable URI.

 - adding more details: Charlie trusts Alice but doesn't trust Bob, so
   he's only going to accept that triple of Bob's (about his name) if
   he can get a trustworthy copy of Alice's endorsement.

 - the threat is that Bob (or someone else) is trying to trick Charlie
   into thinking Bob has some other name.  It particular, he wants
   Charlie to accept this:

   <http://example.org/bob/foaf.ttl#me> foaf:name "Mary".

   Given that Charlie trusts Alice but not Bob, how can Bob do that?

   I think the only way is for him to pretend to be Alice.  We haven't
   said what sort of trusted path there is between Charlie and Alice,
   but I think this problem is orthogonal to RDF.  Maybe Charlie
   trusts everything he gets from any URL starting
   "http://example.org/alice" as coming from Alice.  Maybe he needs it
   to come from https://example.org/alice using the right SSL
   certificate.  Maybe he needs the page to be signed using XML
   digital signatures, with a public key Charlie obtained out-of-band.
   Alice could even prepare different serializations for each client
   and emit everything using AES256 (with a SHA512 checksum), using a secret
   key she and Charlie set up beforehand.   How could Bob trick Charlie, 
   then?

Basically, I don't see what kind of attack is prevented by making
Alice put hashes in her RDF/TriG.  (There might be some situations
where using a hash could give greater performance, but let's consider
those separately.)

    -- Sandro

> > On Tue, 2012-01-17 at 13:38 -0800, Gavin Carothers wrote:
> >> Also on Wiki at
> >> http://www.w3.org/2011/rdf-wg/wiki/Example_of_Endorsement_Use_Case
> >>
> >> ## Endorsement (3rd Use Case from Sandro)
> >>
> >> A system wants to convey to another system in RDF that some person
> >> agrees with or disagrees with certain RDF triples.
> >>
> >> ## Concrete Example
> >>
> >> Alice wants to say that she agrees that Bob is named Bob.
> >>
> >> Bob has stated in a foaf record that he is named Bob. He did so in a
> >> Turtle document he hosts on http://example.org/bob/foaf.ttl
> >>
> >>       @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> >>
> >>       <#me> foaf:name "Bob",
> >>           foaf:homepage <http://mytotallyfakesite.com> .
> >>
> >> Alice Requests the Turtle document. After reading it she decides that
> >> she wants to agree with Bob's name, but doesn't with to endorse the
> >> totally fake site as Bob's homepage.
> >>
> >> In order to use any sort of HMAC or other signing system Alice will
> >> need to produce a byte stream for the message. An example byte stream:
> >>
> >>       0000000 3c 68 74 74 70 3a 2f 2f 65 78 61 6d 70 6c 65 2e
> >>       0000010 6f 72 67 2f 62 6f 62 2f 66 6f 61 66 2e 74 74 6c
> >>       0000020 23 6d 65 3e 20 3c 68 74 74 70 3a 2f 2f 78 6d 6c
> >>       0000030 6e 73 2e 63 6f 6d 2f 66 6f 61 66 2f 30 2e 31 2f
> >>
> >> Or in ASCII:
> >>
> >>       <http://example.org/bob/foaf.ttl#me> <http://xmlns.com/foaf/0.1/name> "Bob".
> >>
> >> Once Alice has the byte stream she uses it to compute a hash
> >> 64487b3448548b7c8a5cfaeb0147bf54. She also creates a full signature
> >> using her private key. She then writes this all down in a new TriG
> >> document:
> >>
> >>       @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> >>       @prefix foo: <http://example.org/foo/>
> >>
> >>       @base <http://example.org/alice> .
> >>
> >>       { <#me> foo:endorces urn:md5:64487b3448548b7c8a5cfaeb0147bf54;
> >>                   foo:signature "SomeSigningBytes";
> >>                   .
> >>       }
> >>
> >>       @base <http://example.org/bob/foaf.ttl> .
> >>
> >>       urn:md5:64487b3448548b7c8a5cfaeb0147bf54 {
> >>               <#me> foaf:name "Bob" .
> >>       }
> >>
> >> Alice then sends the document to Charlie. Charlie is able to take the
> >> triples in the graph statement labeled
> >> urn:md5:64487b3448548b7c8a5cfaeb0147bf54 produce the same byte stream
> >> and verify both the hash and Alice's signature.
> >>
> >> ## Results
> >>
> >> I am unaware of any use case around endorsement or authority that
> >> would not require some level of cryptographic signing. Once going down
> >> that road it's easy to use the byte stream required by ANY HMAC system
> >> to name the set of triples. This sort of use of IRIs containing hashes
> >> for identity of arbitrary data is already in wide use today.
> >> http://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_containing_hash_.28xt.29
> >>
> >> --Gavin
> >>
> >>
> >
> >
>

Received on Wednesday, 18 January 2012 19:56:17 UTC