Design: WASM Module Signature/Verification

I believe we also need the equivalent in the text format, maybe something like: (signature ...).

For CSP, checking the signature could be ON over https? Or do you think that it should be on by default behavior?

Hmmm, "CSP & checking": that would be very early in the process. We would need a (or multiple) public key of the server or any other instance for verification, and it must be a public key using EC (eclliptic curve).

If it would be related to HTTP(S)-based service, it would be necessary to get access to the corresponding public-key (elliptic curve key). Maybe the corresponding public key could be embedded as HTTP-header-attribute of web-page which is loading the WASM modules.

Having signed WASM-modules, these could be fetched from any location and being verified.

Would there be a single organization (hoster) signing WASM files or would a web-page fetch signed-modules from multiple organizations/suppliers?

In case of multiple organizations, either adding the "organization-id" to the signature itself, or defining some some kind of SignerOrg as additional Section (fixed size as well). the process might look like: first attaching the SignerOrg Seciton and then signing both (original module-bytecode & signerorg-section)

it seems the use-case and process must be defined first ;)

I'd like to better understand how the Web's current mechanisms for signature and verification fail, and how first-class WebAssembly support would fix this. Specifically, the Web has HTTPS and Sub-Resource Integrity which, while definitely not perfect, do quite a bit for us already.

Could you explain in detail what you'd like fixed, and how your proposal doesn't have the same pitfalls?

Well, I can try

Embedded signatures are already used for PDF, Win-binaries, drivers, XML-documents, etc.
What might signed WebAssembly modules be good for?

Just imagine

• Web-Application executing WebAssembly code to calculate Banking-PINs.
• Rust/C++ applications using WebAssembly for embedded execution engines, evaluating crypto-currency contracts
• HSM-s using WebAssembly bytecode to calculate PINs in server-backend
• IoT devices whose firmware is assembled using specific versions of different WebAssembly modules (Content Addressable Storage/Linking)

In latter case, the firmware-version of IoT devices would be a list of WebAssembly-modules using specific versions. The IoT devices could spread their version of WebAssembly modules to other devices in the neighborhood (http://www.korhal.io/whitepaper.pdf). No central update-server would be required.

In all of these cases a TSL-transport is not sufficient to establish trust, but the code should be signed so the recipient is able to verify authenticity, integrity all along the supply-chain from developer/supplier up to the web-browser or execution engine.
The signature prevents tampering of data-in-rest and in legal aspect Non-repudiation for operation critical code.

Using a detached signature (compared to an embedded-signature into the WASM-module) would be more complex to handle. The embedded signature would simplify the handling all along the bytecode-supply-chain.

I'm not convinced this is a problem best addressed at the level of WASM itself. Signatures can be added on to any data. Why would they need to be part of the language itself?

Also, it sounds to me like you might be interested in the HTTP Origin-Signed Responses Standard.

Sad to hear. Part of the language, because a signed wasm would keep a valid wasm file; so it would not be kind of wrapper to be removed before parsing. Well, thanks to the existence of CustomSection it is possible to add such structures. Just, would have been nice to move it from "custom-feature" to a "standard-feature".