- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sun, 13 Jun 2021 08:55:34 -0400
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: semantic-web@w3.org
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