I expected any change to the string would render the certificate's signature in the chain invalid. However, this doesn't seem to be the case necessarily. For instance, double signing is possible using the follwing certificates:
The only difference is the letter v that turned to q in the end of the second line. Both certificates are deemed valid though. I assume the encoding captures some part of the certificate that is not signed by the respective CA.
Therefore, a more elaborate mechanism is required, e.g. using the certificate's serial number.
EDIT: The root cause is probably that there is no actual validation of the certificate in the storage process, as described in issue #41. Nevertheless, a more robust implementation as proposed may still be beneficial, as new line encodings etc. could imply distinct strings while after decoding the certificate may be deemed valid.
Currently, double signing is preventing by merely comparing the certificate strings: https://github.com/GSMA-CPAS/BWRP-chaincode/blob/afff34c4b1787d034c35dc094a8905291f7e4b38/hybrid/contract/roaming.go#L593
I expected any change to the string would render the certificate's signature in the chain invalid. However, this doesn't seem to be the case necessarily. For instance, double signing is possible using the follwing certificates:
The only difference is the letter v that turned to q in the end of the second line. Both certificates are deemed valid though. I assume the encoding captures some part of the certificate that is not signed by the respective CA.
Therefore, a more elaborate mechanism is required, e.g. using the certificate's serial number.
EDIT: The root cause is probably that there is no actual validation of the certificate in the storage process, as described in issue #41. Nevertheless, a more robust implementation as proposed may still be beneficial, as new line encodings etc. could imply distinct strings while after decoding the certificate may be deemed valid.