W3C home > Mailing lists > Public > semantic-web@w3.org > June 2021

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

From: Peter Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 04 Jun 2021 14:19:01 -0400
Message-ID: <f5f1e6e778af320238c5a2fce8d734e6c34dfc01.camel@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, semantic-web@w3.org
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 or blank nodes because
canonicalization reduces to canonicalizing IRIs and strings, removing
comments, and then sorting the file and eliminating duplicate lines.


peter
Received on Friday, 4 June 2021 18:20:55 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:46:08 UTC