sbahloul
commented
8 years ago I agree with you about the complexity of the T&Cs in regards to an end-user consent and more generally to any document signature.
Specifically about T&C consent / signature: I would expect that the T&Cs will be signed thanks to an end-user confirmation and those signed T&Cs will be downloadable to allow a end-user double check. Which means that the signature does not apply to each and every page of the document but to the acceptation of the document at a global level. It is already an issue because the existing digital signature approach is based on a binary format that the end-user has no chance to understand (hash of the document)
vgalindo
If we are going to ask the user to confirm a list of terms and conditions, obviously we do not wish the full list of T&Cs to be included in the non-repudiation data. But how do we otherwise ensure that the version of the T&Cs displayed to the user is the same as the one signed by the user? Simply getting the user to sign a hash of the T&Cs is not sufficient, unless the full list of T&Cs is displayed through the Trusted UI along with its hash, since otherwise a fake list could be displayed to the user. But we've already stated that complex structured documents cannot be displayed through the Trusted UI, only simple text.
I am not seeing how asking the user to confirm that they agree with a particular version of the terms and conditions can be secure, because they can always claim that the fake T&Cs were shown to them.
"by producing with its own cryptographic key the binary data signature." This is an orphan sentence; delete.
We don't need "SECURITY NOTE" because this is all within the "Security Considerations" section.