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

On Sun, Jun 13, 2021 at 08:55:34AM -0400, Peter F. Patel-Schneider wrote:
> 
> 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.

Can you state where the aglorithm dicates double-expansion? My reading
of the algorithm is that it starts with an RDF graph and never hints
at any sort of expansion after that.


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

Just to be clear; your objections to the charter include an attack
based on changing the context in between a verification and acting on
the expansion. Instead, you advocate offering no signature of the
expansion.


> > > 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 I convince you that the algorithm does not dictate
double-expansion, or if you convince me that it does and we get it
fixed so it doesn't, would that change your position?

If your objection is that a cryptographic signature should not be
appended to a readable document, you've ruled out most signature
systems I can think of (XML DSig, JWS, PGP Mime). That's just how they
work.

[following are broken out to be easy to reply to]

If you're OK with appending a signature to a document, how about
appending a signature to an N-Quads representation of a graph?

If you're OK with appending a sig to an N-Quads graph, how about other
representations of the same graph?

What if those other representations include JSON-LD?


> > > 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 14:46:07 UTC