Wasm module signatures

[asraa]

This is a proposal about formally introducing Wasm module digital signatures and verification of Wasm bytecode. There was a number of people who were interested in this and I have an interest in getting this working for Istio/Wasm as well as supporting Wasm types in sigstore (e.g. by supporting it in the transparency log).

Right now, there are people who are signing packages or whole .wasm files (https://bytecodealliance.github.io/lucet/Integrity-and-authentication.html, https://medium.com/wasmer/securing-wapm-packages-with-package-signing-3cf0d12f32f3 container signing). But, embedded signatures could allow implementations to validate and make decisions before instantiating the module. Custom sections are natural places to hold this information (see the linked implementations below) in the module.

There is a starter google doc attempting to capture and collaborate on the requirements/use cases that people may need: https://docs.google.com/document/d/1nTLpJMxKNQ4u03g6-KFGYPR7VVovcLKUX0nq0yVnJcw/edit

Links: https://github.com/WebAssembly/design/issues/1185 https://github.com/jedisct1/wasmsign
https://github.com/frehberg/wasm-sign https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/147

Please feel free to correct, add to, comment on.

[sunfishcode]

This is certainly important functionality needed by many use cases. My concern here is that WASI may not be the best forum for this work. WASI's primary focus is on APIs, and how two instances or an instance and a host can pass data and control flow between each other.

I understand that there may eventually be a need to add APIs to interact with signatures, and that might be something that could potentially be done with WASI, however my understanding is that the primary use cases here involve signature data stored in custom sections and validated before instantiation. What would you think about forming a new subgroup for this? For example, this has some similarities to the debugging subgroup, which is also working on formats for data in custom sections.

[jedisct1]

Hi Dan,

Initial discussions will indeed be focused on the signatures themselves and how they are stored and verified. API discussions will be a second step.

A new subgroup would totally make sense for this.

[asraa]

Yes! definitely in support for a having a dedicated subgroup. Right now we are still in the mode to collect information from users on their needs.

How would we start the process of a new subgroup?

[sunfishcode]

The main thing to do is submit a PR to add an agenda item to one of the upcoming CG meetings here. It may be useful to request enough time to give a brief presentation on what the subgroup will be about, and identify who the chairs will be, and then the CG can vote on whether to approve the subgroup and the chairs.

If there's a lot of material to introduce beyond what's in WebAssembly/design#1185, it may also be useful to file a new issue in the design repo in advance of the meeting, so that people can read up on it first.

[tlively]

Would it make more sense to create a proposal repo than to create a subgroup? That would still provide a dedicated forum for discussion, but would be a more light-weight process than creating an entire subgroup. Typically subgroups have broader mandates that span multiple individual proposals, but that doesn't seem to be the case here.

[jedisct1]

A repository would be more than enough for now.

Just to have a better way to organise our proposals than the Google Docs document that we are all commenting on right now, and that doesn't scale well.

[jedisct1]

The next WebAssembly CG meeting will be on April 27th.

Maybe a good opportunity to quickly present what we are working on, and ask for a repository.

Unfortunately I won't be able to attend on the 27th. Would someone else be interested in presenting? (@asraa ?)

Meetings dates and agendas are available here: https://github.com/WebAssembly/meetings

[linclark]

Deepti mentioned in the last CG meeting that the April 27 meeting will be dedicated to a single long conversation, so this likely won't be able to get on the agenda until the CG meeting after that.

[asraa]

Oh, I see. Assuming we still need to present this/get support at the CG meeting for a proposal repo rather than subgroup, I'll submit a PR to add to the agenda following April 27.

[jedisct1]

Thanks for mentioning this, @linclark !

Ok, so that would be May 11. Great!

@linclark can you confirm that a presentation is necessary to get a repos (not a subgroup)?

[linclark]

I'm not sure whether a presentation is necessary, but the CG chairs should know. You could either ask them on Discord, or open the PR and ask whether it's necessary in the issue field (and if it isn't actually necessary, you could cancel the PR).

@jedisct1 The process is documented in the Process document.

[linclark]

Since there's no work that should happen in the context of WASI for now, I'm going to go ahead and close this one out. We'd be happy to engage if it looks like WASI should play a part as the work on the proposal progresses.

Looking forward to seeing how it develops, good luck!