Re: Signing and Verifying RDF Datasets for Dummies (like Me!)

On 6/12/21 6:11 PM, Eric Prud'hommeaux wrote:
> On Fri, Jun 11, 2021 at 07:37:57AM -0400, Peter F. Patel-Schneider wrote:
>> On 6/11/21 3:33 AM, Eric Prud'hommeaux wrote:
>>> On Wed, Jun 09, 2021 at 01:45:10PM -0400, Peter Patel-Schneider wrote:
>> [...]
>> The point here is that the algorithms in
>> https://w3c-ccg.github.io/ld-proofs/ require double expansion so any library
>> that uses these algorithms to both verify and expand will have to do double
>> expansion.  And to prevent manipulation all this has to be done within the
>> trust boundary.  And time and space have to be suspended.
> A couple messages back:
> [[
> Date: Wed, 9 Jun 2021 13:10:28 +0200
> From: Eric Prud'hommeaux <eric@w3.org>
> To: Peter Patel-Schneider <pfpschneider@gmail.com>
> Cc: semantic-web@w3.org
> Subject: Re: Signing and Verifying RDF Datasets for Dummies (like Me!)
> Message-ID: <20210609111028.GA6976@w3.org>
> ]]
> , I stepped through the algorithm and showed that it takes as input an
> RDF graph. Given that, I don't see the justification for your
> assertion that it requires double expansion.
>
>
>> Why require all this extra effort?  If the use of a document format that has
>> a unique expansion to an RDF graph or dataset is required then none of this
>> is necessary.
> I think "unique expansion" means no BNodes. If so, that's a pretty
> small subset of the RDF in common use.


Sorry, "unique expansion up to isomorphism", which means N-Triples or N-Quads.

>>                  The trust boundary can enclose a much smaller area.  The
>> document itself is signed so the validation is much closer to the standard
>> validation for documents.  Recipients can expand at their leisure.  (In any
>> case some recipients will expand at their leisure, trusting that this is
>> allowable because the validation succeeded.  The only way to prevent this
>> would be to encrypt the message so that only trusted libraries can expand
>> it.)
> No spec can prevent bad implementations; the best they can do is work
> with a community to see how to express the spec in a way that enables
> good implementations.
>
> It's trivial for an implementation to expand a JSON-LD document to
> RDF, pass it to canonicalizer, then hash it and verify the
> signature. If the sig is good, the app has the expanded doc to use
> however it sees fit. That document was expanded once in this process.
>
>
But this isn't how the algorithms in https://w3c-ccg.github.io/ld-proofs/ 
work.   Perhaps this change would alleviate some of the problems I have 
identified.

>>> This issue is further evidence that a WG product would increase
>>> security and community understanding around security issues. Most of
>>> the obvious ways ways to sign JSON-LD introduce this sort of
>>> vulnerability. No WG leads to any of:
>>>
>>> 0. No action: most folks won't consider dereferenced evaluation
>>>      vulnerabilities present in JSON-LD pipelines that don't include
>>>      some verification.
>>>
>>> 1. standard JWS over JSON-LD doc: this signs the JSON tree but not the
>>>      RDF expansion.
>>>
>>> 2. Homegrown signature stacks: likely to include atomic operations
>>>      that separate verification from expansion (for e.g. populating a
>>>      store) is subject to your timing attack.
>>>
>>> A WG product can raise awareness of these issues for these issues
>>> across all JSON-LD pipelines (or any dereferenced evaluation
>>> pipelines) and provide recipes and tools for securing them.
>> If you want to send a JSON-LD document, send it as a signed document.
> Do you mean (here and following) to just sign the bytes of the JSON-LD
> document? You were just arguing that the double expansion of a JSON-LD
> document is a flaw in RDF Signatures. Now it appears you're suggesting
> that folks sign the JSON, which takes zero precaution against somone
> changing the context at any point. It appears you have much looser
> requirements for the do-nothing proposal than for the charter.

If the use case requires sending JSON-LD documents around, then send signed 
JSON-LD documents and accept the issues with expansion to an RDF graph or dataset.

>
>>                                                                          If
>> you want to send an RDFa document, send it as a signed document.  If you
>> want to send a Turtle document, send it as a signed document.  If you want
>> to send an RDF graph or dataset send it as a signed N-Triples or N-Quads
>> document.  Don't send JSON-LD or RDFa or Turtle and some other stuff.  If
>> you want to canonicalize an RDF graph or dataset, canonicalize it.  If you
>> want to canonicalize and send, send signed a canonicalized N-Triples or
>> N-Quads document.   There is enough here for a WG.
> I suspect you're restricting the charter here but I'm not sure I
> understand the proposal. You'll have to be more explicit about what
> you intend to rule out.

I'm ruling out complex schemes where a document is sent unprotected along with 
a signature of something that the document sometimes turns into, for example 
sending JSON-LD along with a signature of the RDF graph or dataset that it 
expands to when the signer expands it.   This, to me, ends up with a complex 
verification system that has a large attack space.

>
>
>> If you want to create a vocabulary for proofs and other verification data
>> create a vocabulary.   There is enough here for another WG.

Received on Sunday, 13 June 2021 12:55:59 UTC