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

On Fri, 2021-05-21 at 13:48 +0200, Eric Prud'hommeaux wrote:
> On Fri, May 21, 2021 at 07:01:02AM -0400, Peter Patel-Schneider
> wrote:
> > On Fri, 2021-05-21 at 09:20 +0100, Dan Brickley wrote:
> > > 
> > > 
> > > On Fri, 21 May 2021 at 00:34, Peter Patel-Schneider <
> > > pfpschneider@gmail.com> wrote:
> > > > On Thu, 2021-05-20 at 18:58 -0400, Aidan Hogan wrote:
> > > > > [...]
> > > > > 
> > > > > RDF Dataset canonicalisation has indeed undergone review by
> > > > > trained
> > > > > mathematicians as mentioned before, but to the best of my
> > > > knowledge,
> > > > > the 
> > > > > people involved (those findable from the explainer) are not
> > > > security
> > > > > or 
> > > > > cryptography experts. Which security and cryptography
> > > > > engineers
> > > > have 
> > > > > reviewed which parts? It would be good to see input from such
> > > > experts
> > > > > regarding (2) and particularly (3).
> > > > > 
> > > > 
> > > > Indeed.  As far as I know [3], i.e., the idea of augmenting
> > > > graphs
> > > > while signing and removing the augmentations while verifying
> > > > isn't a
> > > > standard part of security and cryptography.   Which experts
> > > > have
> > > > signed
> > > > off on this?
> > > > 
> > > 
> > > 
> > > On this detail, does it recurse reliably? 
> > > 
> > > If Ale writes some RDF, Brin signs it to assure basic integrity
> > > of the
> > > communication, publishes the result, and then a couple days later
> > > Cary
> > > signs it to indicate institutional endorsement of the original
> > > claims,
> > > etc. Are there any cases where manipulating an additional signing
> > > could
> > > mess with embedded earlier signings, to malicious ends?
> > > 
> > > Dan
> > 
> > Indeed, my reading of 
> > https://w3c-ccg.github.io/ld-proofs/#algorithms
> > leads me to believe that recursively signed graphs cannot be
> > verified.
> > I think the intent of recursive signing is slightly different than
> > your
> > gloss - the second signer is not signing the original graph but is
> > signing the signed graph, perhaps to lend their approval of the
> > first
> > signing.
> > 
> > Ale writes G.
> > Brin signs G and adds its own proof triples, resulting in G'.
> > Cary takes G', removes the proof triples in it to get G, and uses
> > Brin's proof triples to verify that Brin signed G.
> > Cary takes G' and adds its own proof triples, resulting in G''.
> > Dave takes G'', removes the proof triples in G'' to get G, and
> > tries to
> > use Cary's proof triples to verify that Cary signed G.  
> > But Cary did not sign G so the verification fails!
> > 
> > I believe that the described process for manipulation of the graph
> > permits an opponent to inject unsigned content into signed graphs
> > and
> > still have the verification succeed.
> 
> Of course, this is just a limitation of how you can sign graph.
> Nothing prevents you from creating a second graph which references
> the first, and signing that second graph, etc. I can sign your
> signature; I just can't sign it in the same document as your
> signature.

Signing remote objects has its own problems, as far as I can tell. 
What happens if the remote object is modified?  What happens if the
remote object is reverted to an earlier version?  You might be able to
include a signing of the remote object, but that's not part of the
current algorithms as far as I can tell.

You could sign named graphs in the same dataset, of course, and I think
that that would work reasonably well (as it is quite similar to signing
parts of an email message), except that I think you again run into
problems when you want to do recursive signing because RDF datasets
don't have named datasets.  But, again, this isn't part of the
algorithm in Linked Data Proofs 1.0.

So I'm waiting for some security expert sign-off on the entirety of the
proof algorithms in Linked Data Proofs 1.0, and also for an open-source
reference implementation of the algorithms.   I don't think that the WG
should start until both of these have been made available.

peter

Received on Friday, 21 May 2021 12:23:14 UTC