- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Fri, 21 May 2021 13:48:13 +0200
- To: Peter Patel-Schneider <pfpschneider@gmail.com>
- Cc: Dan Brickley <danbri@danbri.org>, Aidan Hogan <aidhog@gmail.com>, semantic-web@w3.org
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. > peter > > > > >
Received on Friday, 21 May 2021 11:48:22 UTC