Custom verifier with public key fetching based on KID

[lovasoa]

Dear Ophir,

I hope it’s ok I contact you like this. The issue management for the cosette repository is disabled, so this is the best way I could think of.
Like you, I am working on verifying EUDCC/DGC signatures, and I am wondering if it is possible to use cosette to get the kid before calling the verify method, or if you know of a better way to verify & decode it given a set of keys (like the one you posted in the EUDCC github thread today).
Great job with posting the keys and the bot by the way. I think a lot of people will find that useful. I am still waiting for a reply from the Swedish authorities to see if they can provide another list for backup/double-verification purposes.

Piotr

by @piotrblasiak
initially received by email

[lovasoa]

Hello,

I just enabled issues in cosette :)

You can pass an array of verifiers with a kid for each to the verify function: https://github.com/lovasoa/cosette/blob/master/lib/sign.ts#L116-L151

I understand that this is not optimal, and a PR adding a new verifier type (with an async callback that would let the user fetch the public key for a KID however they want) would be welcome.

And even better, if you are interested in verifying dgc in javascript, let's not duplicate work ! We have a full implementation in sanipasse

• https://github.com/lovasoa/sanipasse/blob/master/src/lib/digital_green_certificate.ts
• https://github.com/lovasoa/sanipasse/blob/master/src/lib/digital_green_certificate_types.ts

Would you like to work with us on extracting that to a library and publishing it to npm ?

[piotrblasiak]

That's great! Looks like you're a bit further ahead than me. I'd love to help. What can I do?

[lovasoa]

First, in cosette : make sign accept a callback as its verifier argument. The callback is async, takes a kid as argument and returns a verifier (with a public key that cosette can use).

Second, I'll create a new repository with the dgc verification code from sanipasse, and add you to it.

[piotrblasiak]

I'm actually not sure it's needed. At least for my use-case, first downloading all the verifiers and having them in-memory would be better for speed and I don't see that becoming a big problem with too many verifiers. Don't you agree? So on-demand fetching sounds a bit unnecessary to me. But perhaps I've missed something?

[lovasoa]

If we implement a callback , we will support BOTH use cases: ahead-of-time fetching, and just-in-time fetching of public keys. This will let users implement their trust store however they want. It may be in a simple js object, in indexedDB, or online. And all we have to do to support all these usecases is just to make the function take a callback.

[piotrblasiak]

If we implement a callback , we will support BOTH use cases: ahead-of-time fetching, and just-in-time fetching of public keys. This will let users implement their trust store however they want. It may be in a simple js object, in indexedDB, or online. And all we have to do to support all these usecases is just to make the function take a callback.

Alright, you're probably right that it can't hurt. I'm on it.

[piotrblasiak]

I see the tests don't pass as the test/Examples directory is empty. Is this on purpose? Also, the more I look at this the more I wonder if this shouldn't be something done with the cose-js library instead as it clearly duplicates work as you say...

[lovasoa]

It is not empty. Looks like you cloned the repository without subrepositories.

https://git-scm.com/book/en/v2/Git-Tools-Submodules

just clone with --recursive

[piotrblasiak]

Ok, sorry. But question still remains why not work together with the authors of the original cose-js. They apparently put in a lot of work already.

[lovasoa]

There is an open PR : erdtman#45
They have multiple open issues and PRs, I don't think they are interested...

[piotrblasiak]

Ok I just commented on that one to see what me fellow Swede has to say.