Re: Signing and Verifying RDF Datasets for Dummies (like Me!)

On Mon, Jun 07, 2021 at 08:31:17PM -0400, Peter F. Patel-Schneider wrote:
> On Mon, 2021-06-07 at 22:49 +0200, Eric Prud'hommeaux wrote:
> > On Mon, Jun 07, 2021 at 03:37:44PM -0400, Peter Patel-Schneider
> > wrote:
> 
> [..]
> 
> >
> > Since then, you have claimed with full confidence that you have found
> > 10s of critical flaws with what I resolutely call "RDF Signatures".
> > None turned out to be critical flaws.
> 
> I would say a few, not 10s.  I pointed out what I think are flaws in
> 
> [...]
> 
> > A third related to changing the meaning of JSON-LD documents by
> > changing the @context. This isn't related to signatures, and if
> > anything, signatures give you a tool to prevent that because you've
> > signed a the resulting document and if someone changes the the
> > @context under you, you can't verify the signature.
> >
> > Those were, afaict, the only substantial critiques. Most were of the
> > form "if you change X, the hash changes and the signature breaks" to
> > which the reply is "by design".
> 
> Remote contexts are indeed problematic for JSON-LD documents.  They can
> cause failures in both directions.  If the remote context is changed the
> deserialization of the document may change, invalidating signatures of
> documents that use the remote context.  But I believe that attackers can
> also use remote contexts to change signed JSON-LD documents in a way that
> validation by recipients will succeed but when the recipient deserializes
> the document they end up with an RDF dataset that is not isomorphic to the
> dataset signed by the originator.  I believe that this is the case even if
> the orignal signed JSON-LD document did not use remote contexts.

Do you agree that in order to do so, they'd have to expand the
document more than once, and carry the conclusion of a valid signature
over from the first expansion?

The main thing RDF signatures is doing is canonicalizing and hashing
pairs of a document and a proof. The hashing technology is standard
fair used in lots of tech today. The canonicalization could only be
attacked if it produced the same result from different, non-isomorphic
graphs. The focus here seems to be based on tricking people into
signing something different from what they thought they were signing,
or presenting data different from what was signed.

I don't think one could say these are different in kind from either:
1. any other use of JSON-LD
2. the use of any tech where a remote doc tweaks the semantics (DTD).


> > If you approached this with a bit more humility, it would be less
> > galling, but as it is, you keep making strident claims, fighting them
> > for a while, and when the couter-evidence is overwhelming, quietly
> > dropping them in favor of some new strident claim. It doesn't really
> > give the impression that you're arguing in good faith.
> 
> I'm still waiting for an implementation of the algorithms that I can use to
> demonstrate my claimed attacks.  Once I have this implementation I'll try
> out my attacks using it and report back my experiences.  With the partial
> implementation I have been given I've noticed and reported that remote
> contexts in JSON-LD cannot be signed so I can't try the initial remote
> contexts attack I came up with.  I've also tried two of the simple problems
> with JSON (large integers and repeated keys).  The partial implementation
> silently modifies large integers and accepts repeated keys.
> 
> The Web GUI you put up at
> https://janeirodigital.github.io/rdf-sig-playground/index was useful but it
> doesn't take JSON-LD and appears to produce quite different output.

The default manifest file loads an example which creates a VC. RDF
Signatures are, as indicated in the proposed charter, a framework for
creating protocols like VCs and like what Manu signed. I stuck a
<select/> at the top to make it generate a proof like Manu's.

With this manifest:

https://janeirodigital.github.io/rdf-sig-playground/index?manifestURL=examples/toy.yaml

you should be able to reproduce (and step through) Manu's example
without ever dipping into JSON-LD. It doesn't accept his key pair
because key formats are beyond my ken (Manu, a PR would be welcomed).
In principle, if it did, you'd see a proofValue of

'z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6'
instead of my
'z5BK4yiC7Ee85EFjDYG3qSnRGrW7DrcmmMaJwEULMJknAN7ZmxTCcGZVthe71UMKreKaKbVx9rBWV3BkiWhxNpCXp'


> peter
>

Received on Tuesday, 8 June 2021 21:14:42 UTC