Reword description of the process of document signing

Description

Currently common_im document says in section 6.2.7. Digital signature, last paragraph: "The signing computation has to be performed on the server side of a system, just prior to committal, since one of the data elements included in the signed content is the committal timestamp.".

It is very unlikely the process of signing can be performed on the server as that would require that the user sends her private key to the server for the purpose of signing.

Environment

None

Activity

Show:
Thomas Beale
March 9, 2016, 11:33 PM

I've had a better look at the spec. The error in it is that signing is described as being the whole ORIGINAL_VERSION. The signature should just be of the version contents i.e. COMPOSITION being passed to the server. The spec currently says:

"At the time of committal of a Version, a digital signature of the object can be made. In this process, a Version object (an ORIGINAL_VERSION or IMPORTED_VERSION) is serialised into canonical form which is then hashed to produce a digest. If public key or equivalent infrastructure is in place so that users are able to sign content, a digital signature can be created from the hash, using the user’s private key."

We should change this to refer to the data item being committed by the user. This means that the generated signature also needs to be passed as an argument to the commit call.

Heath Frankel
March 10, 2016, 6:30 AM

I am OK with Tom's suggestion, but I still think this is system level signatures, not user signatures. See Section 4.2.4 of Common_im (in r1.0.2) for description of Attestation.proof for user level signatures.

Thomas Beale
April 5, 2016, 1:15 PM

After staring at the current specs a bit more I would propose to do no more under this CR, and to accept it with just the minimal change that Bostjan asked for. The specs are still wrong, but fixing them properly means coming up with a better signing design, which I suspect is both on client side and server side, as Heath implies. Such a change is clearly a 1.1.0 or later change.

Pablo Pazos
April 28, 2016, 3:23 AM

@Thomas +1

Pablo Pazos
April 28, 2016, 3:29 AM

BTW if this will be reworked in the future, I would like to analyze the possibility of storing user keys on the server side and server side singing using those keys. Also would like to contemplate different scenarios of client/server signing requirements.

Reporter

Boštjan Lah

Labels

None

Components

Affects versions

Priority

Major
Configure