Signature handling and timestamps

[sschulz-t]

When the signature workflow was created, it was decided that we do not include the timestamp in the signature itself but rather rely on the timestamp of the associated blockchain transaction.

The signature workflow is described here: https://github.com/GSMA-CPAS/BWRP/wiki/Document-Signature-Process

The advantage is that this timestamp can not be "faked" and does not allow back dating of signatures. This is useful with regard to e.g. revoked certificates.

When using hash(timestamp + binarydata) as a signature one could use arbitrary values for the timestamp and i.e. back-date a signature. Example:

• day x: company A revokes a certificate as it was compromised by an attacker
• day x+1: the attacker signs hash(timestamp + binary) as company A and includes timestamp=x-1
• when we rely only on the timestamp of the cert we can not detect this, the blockchain timestamp is more reliable here

Using the on-chain timestamp this attack is not possible.

The thing I consider not optimal is that other signature standards (e.g. the signature in pkcs7) directly include the timestamp in the signature. I was wondering if we should do the same (maybe in addition?) or if all is fine/safe by our current approach.

This ticket is for discussion and reference/documentation purposes.

[andswk]

Out of scope for MVP 1, but might be considered later.

[informartin]

During the implementation of certificate revocations, it became apparent that including a timestamp to the signature would break the VerifySignatures() function, as it rebuilds signaturePayload internally from its stored components:

signaturePayload := hash(MSP <concat> referenceId <concat> referenceValue)

A added timestamp wouldn't be available, so that signaturePayload couln't be calculated.