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

On 5/27/21 9:59 AM, Eric Prud'hommeaux wrote:
> On Mon, May 24, 2021 at 11:14:29AM -0400, Peter F. Patel-Schneider wrote:
>> On 5/24/21 9:35 AM, Eric Prud'hommeaux wrote:
>>>
[...]
>>
>> But what if I instead modify the signature block
>>
>> [[
>> <> a :Signature .                              # signed
>> <> :date ... .
>> <> :hash "e73c206562e219fcf4c0e80085f4b8e5" .  # signed
>> ]]
>> =>
>> [[
>> <> jwt: "abcd..1234abcd" .     # detached JWT signature
>> ]]
>>
>> Is this modification going to sneak through?  According to what I see in the
>> algorithms, this stuff isn't actually signed.
> You could *replace* it with your own signature, but you can do that in
> XML signatuers or any other system. You could even re-write the first
> part of the jwt (the part that has the protected headers, shortened to
> "abcd" in my example), but again, you'd have an invalid last part
> ("1234abcd" above).
>
> Protocols like VC concatonate the proof (minus the signature) to the
> graph being signed. That prevents someone from changing that
> data. That's not necessary if the protocol is just to sign because any
> corruption of the parameters will make the document unverifiable, but
> VCs include a bit of stuff work protecting like a created date and a
> proof purpose. (They also protect the verification method, which could
> matter if some perilously weak alternative existed.)

OK, I guess I see that, but is that really what the proof algorithm in 
https://w3c-ccg.github.io/ld-proofs/#algorithms is doing?

>
> See the VC example in <https://janeirodigital.github.io/rdf-sig-playground/index>
> signing: <https://github.com/janeirodigital/rdf-sig-playground/blob/main/index.js#L46>
> verifying: <https://github.com/janeirodigital/rdf-sig-playground/blob/main/index.js#L115>
> (These anchors will break pretty quickly so follow them soon.)
>
>
>>>                                                         Alternatively, it
>>> might be possible to add an extra signature block, and still have the
>>> verification succeed.
>>> You could only do that if you obtain a key that the consumer trusts.
>> So?   Even if I have a key that the consumer trusts I should not be able to
>> edit someone else's signed message and still have it verity.
> That's not "still verify", more "verfiy again". You've replaced the
> signature.

If I leave the signature there and add an extra proof node with my signature 
then it seems to me that everything will still verify with both signatures as 
according to the verification algorithm these proof nodes are removed.  So far 
so good, I guess.

But what happens if I have an RDF dataset that already has a proof node.  If I 
sign this dataset it appears to me that my signature will not be verifiable 
because my signature will be tried against the RDF dataset with all proof 
nodes removed, which is not what I signed.


>
>
>>                                                                Encapsulate,
>> sure, but adding an extra signature block doesn't seem to be exactly
>> encapsulation.  And if it isn't *exactly* encapsulation then this
>> possibility needs to be carefully examined.
> There is nothing anyone can do to prevent you from altering a document
> and re-signing that altered document. If someone trusts your key,
> they'll accept your signature.


See above.


peter

Received on Thursday, 27 May 2021 15:07:36 UTC