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

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

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Wed, 26 May 2021 02:19:03 +0200
Message-ID: <CAE1ny+7d7bEG-rKYnVxMXWs5WJV8D3eguajc_LxFBzd0XW72Xw@mail.gmail.com>
To: Peter Patel-Schneider <pfpschneider@gmail.com>
Cc: Aidan Hogan <aidhog@gmail.com>, Dan Brickley <danbri@danbri.org>, Semantic Web <semantic-web@w3.org>
On Wed, May 26, 2021 at 1:54 AM Peter Patel-Schneider <
pfpschneider@gmail.com> wrote:

> On Tue, 2021-05-25 at 18:42 -0400, Aidan Hogan wrote:
> > [...]
> >  The issues being discussed here relate more to the definitions of
> > RDF
> > datasets -- how they are serialised or deserialised, how signature
> > metadata can be embedded and extracted, etc. -- than cryptography.
> >
> > - We are not inventing new cryptography. Rather we are black-boxing
> > cryptography. The complicated stuff in terms of how the cryptography
> > is
> > implemented and what guarantees this provides is done for us. The
> > issue
> > then is to take those guarantees and reduce the current RDFy
> > specifications to them. For example, the cryptography black box
> > presumably will provide guarantees with respect to the difficulty of
> > a
> > pre-image attack. Assuming this guarantee (without necessarily
> > understanding how it is implemented), one can then formalise
> > guarantees
> > regarding the difficulty of attacks on an RDF level that equate to a
> > pre-image attack (e.g., using proof by contradiction, showing that
> > the
> > RDF-level attack would constitute a pre-image attack). I think that
> > this
> > sort of task requires a more detailed understanding of RDF than of
> > cryptography.
> >
> Attacks on computer security come in different flavours.   There are
> attacks on the fundamental crypographic primitives.  There are attacks
> on how these primitive are used.  There are probablhy other kinds of
> attacks, for example attacks that depend on the resources needed to do
> RDF dataset canonicalization.
> Developing good cryptographic primitives is difficult and often
> requires inspiration.  Developing good usage may be even more difficult
> and generally requires a lot of persperation - to enumerate all the
> different ways that an opponent can take advantage of each and every
> aspect of the signing/proof process.

Hi, I'd like to point out that while there are no peer-reviewed
publications on the (lack of) security of the so-called Verifiable
Credential architecture and the problems with this kind of standardization
of things like "Linked Data Proofs", In fact, published a peer-reviewed
article explaining in detail how utterly broken the entire DID and Verified
Credential architecture is, and how this is damaging the credibility of the
W3C, and it was presented at Mozilla. It's online here:

Now, basically Peter is *absolutely* right and my recommendations in this
article still stand (TL;DR 1. Go to the IETF 2. Don't try to add signatures
to RDF as a free-standing work item).

First, the W3C is not the right standards body for security, and burnt what
goodwill they had from the security and privacy research community by
backing DRM without a security research covenant as put forward EFF. The
"audits" that Manu that he paid for and referenced earlier by "Math
Ph.D.s"  like Mirabolic Consulting are basically amateur at best. No actual
cryptographer has bothered to look at this, and there are no proofs.

Second, the problem is fundamentally conceptual, and the fact that this
Working Group charter is so confused on basic concepts kinda proves it's
not capable of doing the work. You can only sign bistrings, i.e. syntax.
You can't sign "semantics".  The use-cases of "securing RDF" just makes the
above worse, even if you could get a functional canonicalization algorithm
(and I'm not convinced you can). Thus, expanding the charter to signing
graphs of graphs and offline graphs (where folks like Gregg are just making
up terminology like "parallel signatures" rather than using the actual
terms used in practice, like aggregate signatures) will only compound
security problems.

Also, anyone with any historical memory of standards should remember how
badly XML-DSIG screwed this up, resulting in a Recommendation being
retracted and the Working Group reformed, and its use in the wild basically
being still broken. So, RDF has just the same problems in terms of
canonicalization and signing out of band documents as XML, but *worse* due
to blank nodes and semantics.

Furthermore, there isn't a magic black box for this. There are well-defined
security properties that signature schemes should have (EUF-CMA, etc.) and
these are relative to well-defined threat models, not a grab-bag of terms
in some "RDF vocabulary for security".

My recommendation is not to go forward with the charter, find new editors
that have actual background in the subject matter of security, and do the
work at the IETF - which as a very good track record now in cryptography
and access to the right experts at the CRFG, and has done a good job with
actual proofs at TLS 1.3 and new MLS work that have prevented and fixed
long-standing attacks in core web architecture.

In the mean time, there is no real-use case for this work. You can
serialize and sign JSON perfectly well, and if you really want to sign
"semantics" just serialize it as JSON and sign that using JWS algorithms
that use fairly well-vetted IETF work rather than re-inventing the wheel
badly. If you want two "equivalent" graphs to have the same signature, I
suggest you simply should probably not be using RDF due to RDF being a data
model, not a data format as a bit string. You could try to reboot the whole
history of RDF, but that's probably not worth doing.

I apologize in advance for not answering all the emails I will get from
Manu and his ilk, but honestly, I do not have all the spare time. I suggest
people find other life goals that perhaps do not involve trying to
prematurely optimize "the future of the Web" via writing broken standards
via chartering new Working Groups, as that went quite wrong with XHTML and
has hurt, rather than helped, the otherwise useful goals of the Semantic


> > (Ceci n'est pas un audit de sécurité.)
> >
> > Best,
> > Aidan
> peter
Received on Wednesday, 26 May 2021 00:19:28 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 26 May 2021 00:19:30 UTC