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

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.


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


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

Received on Monday, 24 May 2021 15:14:45 UTC