So far, the document signature is verified according to the signature algorithm defined in the user certificate, as explained in issue #25. However, that algorithm refers to the algorithm used to sign the certificate, not the document. This PR changes it to the algorithm defined in the signature JSON.
The old branch mw-include-sig-algorithm used OIDs. This PR uses strings to identify the algorithm. Therefore, we need to ensure that the correct string is used in the first place. E.g. the test_query.sh in the blockchain adapter passes secp384r1 while ecdsaWithSha256 will be required here.
We need to define which algorithms will be supported and document them in the Wiki including the identifying string.
Currently, a lot of algorithms are included in certificate/signature.go. We should delete unnecessary ones after the decision was made on what to use. Furthermore, the signatureAlgorithmDetails struct currently includes PublicKeyAlgorithm and Hash that aren't used so far. If they aren't required anywhere, they can also be removed.
The SignPayload() function now uses the same hashing and public key algorithm as used in the certificate. Hereby, it will be easy to test different kinds of certificates and algorithms.
So far, the document signature is verified according to the signature algorithm defined in the user certificate, as explained in issue #25. However, that algorithm refers to the algorithm used to sign the certificate, not the document. This PR changes it to the algorithm defined in the signature JSON.
The old branch
mw-include-sig-algorithm
used OIDs. This PR uses strings to identify the algorithm. Therefore, we need to ensure that the correct string is used in the first place. E.g. thetest_query.sh
in the blockchain adapter passessecp384r1
whileecdsaWithSha256
will be required here.We need to define which algorithms will be supported and document them in the Wiki including the identifying string. Currently, a lot of algorithms are included in
certificate/signature.go
. We should delete unnecessary ones after the decision was made on what to use. Furthermore, thesignatureAlgorithmDetails
struct currently includes PublicKeyAlgorithm and Hash that aren't used so far. If they aren't required anywhere, they can also be removed.