Re: Chartering work has started for a Linked Data Signature Working Group @W3C

On Fri, 4 Jun 2021 at 19:28, Peter Patel-Schneider <pfpschneider@gmail.com>
wrote:

> On Fri, 2021-06-04 at 12:00 -0400, Manu Sporny wrote:
> >
> > On 6/4/21 10:16 AM, Dan Brickley wrote:
>
> [...]
>
> > > Perhaps the WG charter should cover only use of self-contained
> Linked Data
> > > / RDF format, eg Turtle/TRiG?
> >
> > If you are loading a JSON-LD Context from disk, it is self-contained
> Linked
> > Data. If you are using embedded JSON-LD Contexts, it is self-
> contained Linked
> > Data.
>
> There is an easy escalation-of-privileges attack on loading a context
> from a file.  All the attacker needs is create and write access to any
> part of the filesystem.
>
> > A significant number of use cases exist in the Verifiable Credentials
> > ecosystem, which is JSON-LD that refers to JSON-LD Contexts using
> HTTP Links
> > and loads them from disk. We shouldn't be talking about putting those
> use
> > cases out of scope since that is a significant amount of the
> implementer
> > community for this work.
>
> So the implementation of the security primitives use some special sauce
> that is not specified in the algorithms?  That's not implementing the
> algorithms, but something else, which might be more secure or less
> secure.
>
> > > And then try to secure hypertext / multi-stakeholder RDF syntaxes
> (json-ld,
> > > grddl, ...) as a stretch goal rather than core business?
> >
> > As Ivan mentioned, this is already covered by previous changes that
> were made
> > to the Charter based on your input. This "don't load remote contexts
> when
> > doing a digital signature" falls under "additional Linked Data
> Integrity
> > techniques" in "Other Deliverables". It's not mentioned in the core
> LDP
> > algorithms because it's an "additional Linked Data Integrity
> technique"... we
> > will probably want to speak to it in the Security Considerations.
> >
> > I will note that we put this stuff out of the critical path because
> it was
> > requested to not be a focus of the group and now people are
> simultaneously
> > frustrated that it's not mentioned in the LDP algorithm (Peter) and
> not
> > completely out of scope (you).
> >
> > -- manu
>
> Yes, indeed, I am certainly frustrated that there is no reference
> implementation of the algorithms.  I am still unable to determine just
> how linked data documents are to be signed and verified.  I'm even
> unable to determine what a consumer is supposed to be able to determine
> when a signed linked data document is verified.
>
> I'm also unclear as to whether HTTP contexts actually are bad practice.
> Example 6 in https://w3c-ccg.github.io/ld-proofs/ appears to use a
> remote context in a signed linked document.
>
> I'm coming to the conclusion that there is no way to reliably sign and
> verify JSON-LD documents as linked data.  About all I'm willing to
> guess is that it is likely possible to reliably sign and verify NQUADS
> documents that do not contain relative IRIs


If the relative IRIs are in a syntactic context that expects IRIs, then it
would be invalid NQUAD syntax.

https://www.w3.org/TR/n-quads/#sec-iri

“ IRIs <http://www.w3.org/TR/rdf11-concepts/#dfn-iri> may be written only
as absolute IRIs.”

... so presumably careful software would object strenuously.

or blank nodes because
> canonicalization reduces to canonicalizing IRIs and strings, removing
> comments, and then sorting the file and eliminating duplicate lines.


I don’t follow this point

Dan

>
>
>
> peter
>
>
>
>