Addressing questions from pre-proposal presentation

[asraa]

Opening this issue to address thoughts we got from the 05/25 meeting (https://github.com/WebAssembly/meetings/blob/main/main/2021/CG-05-25.md). I'll try to classify some of the concerns, and then reply.

1. Why does this need to be part of the Wasm structure itself? It would be hard to implement in all runtimes, and we can already leverage existing standards for signatures in a higher layer.

2. How do the design proposal for embedded signatures fit into a typical use case of a browser validating the module its loading is the one I generated?

3. How does this interoperate with module-linking and component-model?

4. Can this address scenarios where an application is a combination of JS and Wasm?

[asraa]

Based on discussions:

• Doesn't need to be implemented by every runtime. Signatures in custom sections can be ignored by hosts that don't implement signing/verification. Rather the specification for verification can rely on runtime that implement code signing. Would not expect browsers to implement (as there are other web based solutions for resource signing).

• Rationales for proposing signing in the Wasm structure: there are many contexts (web, containers) where signatures can happen, and this would unify/converge on signing so modules can appear in signed in multiple contexts rather than relying on higher layers.

[lukewagner]

As someone who doesn't know anything about signatures, I'm interested in this proposal since it addresses a request we've heard consistently from the beginning of wasm ("add code signing!") but have consistently punted on due to our initial MVP focus on the browser, which already has its own holistic set of features in this space. Also, we lacked the concrete context for how wasm would be used outside the browser to even begin to think about signatures.

One simple reason that I think a standards effort is valuable here is that we can already see multiple (at least 3, maybe more, iiuc?) examples of new wasm hosts doing their own in-the-wasm-module signing in a non-standard way. So there's a classic "pave the cowpath" argument.

Asking why these hosts have chosen to design something new, instead of reusing an existing format which includes signatures (e.g., OCI): iiuc, it's because the fundamental unit (of deployment) is a wasm module, as opposed to some bigger "application" bundle of which the wasm module is only one part. Thus, retrofitting some existing container format would add complexity/overhead.

Another reason to have a wasm standard (of the same variety as the name custom section), is that, from what I understand of the proposal, it benefits from being integrated with the structure of a module binary. In particular, integration support various use cases like adding extra sections and signing the addition while maintaining the existing sections/signatures. Thus, the "things" being signed aren't simply whole wasm modules as black boxes.

Another, more hypothetical (and out of scope of the current proposal) benefit of integrating signatures with wasm modules is integration with module-linking. In particular, I'm imagining a module A that module-imports a module B and wants to sign the complete linked graph without simply inlining B into A (thereby allowing code sharing without giving up the gurantees of signing). There are even more fun use cases where A wants to sign not just an exact B version, but also compatible future versions, as long as they are signed by the right entity, specified by A. (But this is just me guessing b/c I don't know anything about signatures.)

All of that is to say: my impression is that this proposal is interesting enough to the CG to meet the bar of entering Stage 1.