feat(crypto): CRP-2420 add new signature verification package initially supporting canister signatures

[przydatek]

Setup ic-signature-verification package, which is intended to be a standalone crate with minimal dependencies
for verifying signatures supported by the Internet Computer.

Add the first utility function to the package, namely verify_canister_sig() for verifying canister signatures.
More comprehensive tests are needed, and they will be added in a follow-up PR.

[przydatek]

Hi @fspreiss ,
In addition to the more comprehensive tests, there could be (at least) two more extensions/changes (maybe as follow-up PRs, or future work)

1. Argument types: right now we have mostly &[u8], but maybe we could wrap these e.g. as CanisterSigPublicKeyDer([u8]), or CanisterSignatureCbor([u8]), so that it is not so easy to put the arguments in a wrong order.
2. The return value is just Result<(), String>, which on one hand is nice because it is simple/generic, but maybe a more elaborate error-enum could be introduced, maybe not for the main function, but for internal reporting between the helpers, and for a potential additional API to be consumed internally by the replica code.

Wdyt?

[fspreiss]

Thanks a lot, @przydatek: I didn't check all verification details yet, but this PR looks really good! Above Below you find my comments so far. The code is very concise (partially enabled through the use of ic-certification) and nice to read.

Hi @fspreiss , In addition to the more comprehensive tests, there could be (at least) two more extensions/changes (maybe as follow-up PRs, or future work)

1. Argument types: right now we have mostly &[u8], but maybe we could wrap these e.g. as CanisterSigPublicKeyDer([u8]), or CanisterSignatureCbor([u8]), so that it is not so easy to put the arguments in a wrong order.

You are right in that having multiple/only &[u8] as parameter types is suboptimal. Introducing newtype wrappers like CanisterSigPublicKeyDer would help, but ideally these types are somewhat smart because being able to instantiate a struct called CanisterSigPublicKeyDer with invalid DER is also suboptimal. The good thing in our situation is that if a caller passes the arguments in the wrong order, nothing bad can happen: the verification will simply fail, which might mean that the &[u8] parameters are good enough. Still, at least for the use of the library in the replica code, dedicated types might help. We can also discuss offline how to proceed here.

2. The return value is just Result<(), String>, which on one hand is nice because it is simple/generic, but maybe a more elaborate error-enum could be introduced, maybe not for the main function, but for internal reporting between the helpers, and for a potential additional API to be consumed internally by the replica code.

Agreed. String is nice and simple, but indeed we want to use this library later in the CryptoComponent/Replica code (instead of the current canister sig verification code) and for that a proper error type may actually be good to have, at least internally. Anyway, this is also what Roman would recommend.

[przydatek]

Thanks, PTAL.

[fspreiss]

I now double-check the verification logic agains the spec, and this looks very good.

[przydatek]

Thanks, PTAL.

[fspreiss]

Thanks for the various changes, @przydatek!

[przydatek]

Thanks, will merge once green.