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

On Thu, May 27, 2021 at 11:07:20AM -0400, Peter F. Patel-Schneider wrote:
> 
> 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?

I think I just hit this in a reply about five mins ago. Basically, my
conclusion is that there could be more guidance there when there are
editors accepting PRs.


> > 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.

Methodically, when you hash the doc to create a proof or verify an
existing one, you can't have a proof there. (In principle, you could
whittle that down to the jws.) If you want to get cute and sign a
signature, you can define that (basically, just list the (ordered)
components that go into the hash). I haven't dug into into it but I
expect that signature chains do something like that.

This doesn't change the underlying signing mechanism; it parameterizes
the use of the currently-described signing mechanism. Some guidance
around algorithm li 3 could help folks create robust protocols for new
use cases.


> > >                                                                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 20:26:32 UTC