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

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:
> > On Mon, May 24, 2021 at 06:09:26AM -0400, Peter F. Patel-Schneider wrote:
> > > On 5/24/21 2:05 AM, Aidan Hogan wrote:
> > > > On 2021-05-23 7:06, Peter F. Patel-Schneider wrote:
> > > > > So it appears that you agree with me that signing a document
> > > > > serializing an RDF dataset according using the algorithms in Linked
> > > > > Data Proofs 1.0 do not meet the usual computer security
> > > > > requirements.
> > > > Hmm, I'm not sure. I guess it depends on the specific security
> > > > requirements (and I'm not an expert on such topics).
> > > > 
> > > > However, I think most of the issues you mention might lead to a verify
> > > > returning *false* "unexpectedly" because while verifying, you extract a
> > > > dataset (or signature parameters) different from the original graph (or
> > > > signature parameters) passed to the sign function. This type of false
> > > > negative seems to affect something more akin to "usability" rather than
> > > > security: it seems to me to err on the side of caution.
> > > > 
> > > > If verify were returning *true* unexpectedly, I would have to imagine
> > > > that that would be more worrying in terms of security requirements, but
> > > > I don't think such issues are likely as they would seemingly break some
> > > > of the guarantees of the underlying cryptography (used in sign).
> > > It appears to me that changing the data associated with the signature could
> > > result in an unexpected true, as this data is not part of the graph that is
> > > verified.  This does require that there be data in the signature that can be
> > > changed without affecting the verification function.
> > Can you give an example how you are more likely to get unexpected true
> > than to get e.g. an unexpected md5 hash collision?
> > 
> > It's fine to have unprotected metadata. For instance, if I hash a
> > document that says "good luck!\n" and have a signature algorithm that
> > specifically protects the type arc and a :hash property:
> > 
> > [[
> > <> a :Signature .                              # signed
> > <> :hash "e73c206562e219fcf4c0e80085f4b8e5" .  # signed
> > ]]
> > =>
> > [[
> > <> jwt: "abcd..1234abcd" .     # detached JWT signature
> > ]]
> > 
> > , I can add as much unprotected metadata as I want:
> > 
> > [[
> > <> :pubKeyId <http://a.example/my/pub/key> . # unsigned
> > <> :origText "good luck!\n" .                # unsigned
> > <> :hashAlgorithm "md5" .                    # unsigned
> > <> :hashedBy mailto:eric@w3.org .            # unsigned
> > ]]
> > 
> > You peevishly edit that graph and confound a consumer by e.g. changing
> > metadata about the :hashAgorithm:
> > [[
> > <> :hashAlgorithm "sha256" .
> > ]]
> > 
> > All you've done is make it harder for the consumer to stumble on the
> > correct way to verify the signature (i.e. they have to say "sha256
> > didn't work; let's try md5"). Most importantly, you've not increased
> > the odds of incorrectly accepting the signature at all.
> 
> 
> 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.)

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.


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


> > [...]
> > > peter
> > > 
> > > 
> > >

Received on Thursday, 27 May 2021 13:59:44 UTC