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

On 6/16/21 1:44 AM, Eric Prud'hommeaux wrote:
> On Mon, Jun 14, 2021 at 07:43:32PM -0400, Peter Patel-Schneider wrote:
>> On Mon, 2021-06-14 at 23:57 +0200, Eric Prud'hommeaux wrote:
>>> On Sun, Jun 13, 2021 at 04:26:57PM -0400, Peter F. Patel-Schneider
>>> wrote:
>>>> On 6/13/21 10:45 AM, Eric Prud'hommeaux wrote:
>>>>> On Sun, Jun 13, 2021 at 08:55:34AM -0400, Peter F.
>> [...]
>>>>> If you're OK with appending a signature to a document, how about
>>>>> appending a signature to an N-Quads representation of a graph?
>>>> Oh, yes, this is fine.   N-Quads has a unique expansion to triples.
>>>> (Module
>>>> case normalization of language tags.)
>>> Crap, I missed a step here. I wanted to explicitly ask about adding a
>>> signature to the RDF graph (à la the examples in
>>> <
>>> https://janeirodigital.github.io/rdf-sig-playground/index?manifestURL=examples/toy.yaml
>>> ). I think your answer about JSON-LD below says you're OK with
>>> signatures in the graph.
>> I am very uncomfortable with anything that is different in any way from
>> current cryptographic practice.  My understanding is that this practice
>> dictates a strict separation between the thing that is being protected
>> and the protecting information.   So in a signed document the thing
>> that is being signed is either separate or is encapsulated.  I was thus
>> being a bit simplistic in saying that I was OK with appending a
>> signature - I am only OK with this if there is a separation between the
>> signature and the thing being signed.  This is decidedly not what
>> appears to be happening in linked data signatures or in the interface
>> that you mention.
>>
>> One of these problems easily shows up when you take the output of the
>> signining interface and feed it back as input to itself be signed.  The
>> verifier refuses to verify the signed graph.   That's a major problem -
>> why should it not be possible to sign and successfully verify a graph
>> that has a signature in it?   This kind of problem shows up in the
>> algorithms in https://w3c-ccg.github.io/ld-proofs/
> The single-proof constraint that you consider a critical flaw, I
> consider to be a design limitation that's easy to work with. You can
> probably go further with rooted graphs or fresh graph labels but
> that's reseearch and the current approach is already quite useful.
>
> Likewise, the context-changing attacks that convince you that the work
> can't be done, I consider pretty easy to addresss in a spec and test
> suite. It's not a coincidence that the Digital Bazaar stack avoids
> this problem by using static documents. Here, the specification needs
> to capture more of the current practice.
>
Well then we disagree.

I expect a method for signing RDF graphs to handle RDF graphs that contain a 
signature.  If the method can't, then that's not a reason to work around the 
problem, that's a reason to not use the method.

I expect a method for verifiably sending JSON-LD documents to have the usual 
properties of verifiably sending documents, including not allowing senders to 
disavow their signatures.  I expect a method for verifiably sending JSON-LD 
documents to be as simple as verifiably sending any other document, with only 
a small amount of code inside the trust boundary.  If the method doesn't have 
these properties, then that's not a reason to work around the problems, that's 
a reason to not use the method.

peter

Received on Wednesday, 16 June 2021 10:55:44 UTC