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

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.


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


> These are both methods of subverting computer security that do not attack
> the core cryptographic functions but instead attack the association of the
> signature with the payload.  But it is just as important to prevent these
> attacks as other attacks.
> 
> > 
> > > You also appear to be saying that it might be possible to come up
> > > with qualifications that could fix this problem.
> > 
> > Yes, I suspect that technically it should not be difficult. I think the
> > harder part will be to reach a consensus on what qualifications to apply
> > in order to ensure G1 and G2 mentioned previously.
> 
> I would say that it is more important to ensure that the qualifications
> actually do ensure correct signing and verification.
> 
> > 
> > Best,
> > Aidan
> > 
> 
> peter
> 
> 
>

Received on Monday, 24 May 2021 13:35:52 UTC