├── .gitignore ├── README.md └── meetings ├── 2021 ├── 04-09.md ├── 04-23.md ├── 05-07.md ├── 05-21.md ├── 06-04.md ├── 06-18.md ├── 07-02.md ├── 07-16.md ├── 07-30.md ├── 08-13.md └── 08-27.md └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # WebAssembly modules signatures 2 | 3 | 4 | 5 | 6 | 7 | - [WebAssembly modules signatures](#webassembly-modules-signatures) 8 | - [Project scope](#project-scope) 9 | - [Current implementations and documents](#current-implementations-and-documents) 10 | - [Related projects:](#related-projects) 11 | - [Requirements and justifications](#requirements-and-justifications) 12 | - [Discussed options](#discussed-options) 13 | - [Scratch notes](#scratch-notes) 14 | - [Appendix 1](#appendix-1) 15 | - [Appendix 2](#appendix-2) 16 | - [Appendix 3](#appendix-3) 17 | 18 | 19 | 20 | ## Project scope 21 | 22 | This work is specifically about digital signatures in WebAssembly modules, not about package/OCI signatures. 23 | 24 | The goal is to converge on requirements that can be used to build out an initial and extensible specification. 25 | 26 | ## Current implementations and documents 27 | 28 | The proposal from [Appendix 2](#appendix-2) has documentation and implementations to experiment with: 29 | 30 | - [WebAssembly module signatures](https://github.com/WebAssembly/tool-conventions/blob/main/Signatures.md) document for implementers. 31 | - [wasmsign2 rust library and CLI tool](https://github.com/wasm-signatures/wasmsign2) 32 | 33 | ## Related projects: 34 | 35 | - [WasmSign](https://github.com/jedisct1/wasmsign) - a tool to embed signatures in WebAssembly modules 36 | - [wasm-sign](https://github.com/frehberg/wasm-sign) - another tool to sign WebAssembly modules 37 | - [Istio/Envoy example](https://github.com/proxy-wasm/proxy-wasm-cpp-host/pull/147) load-time check of WasmSign signatures 38 | - [Validation in Lucet](https://bytecodealliance.github.io/lucet/Integrity-and-authentication.html) 39 | - [WAPM package manager](https://medium.com/wasmer/securing-wapm-packages-with-package-signing-3cf0d12f32f3) signature verification 40 | - [Sigstore](https://sigstore.dev) transparency log 41 | 42 | ## Requirements and justifications 43 | 44 | - [X] Signatures may implement multiple signature algorithms 45 | - Compliance requirements 46 | - Public key size/signature size/verification CPU cost tradeoffs (ex: post-quantum schemes vs EdDSA) 47 | - Code and key reuse (ex: ECDSA-SHA3 for blockchains already leveraging SHA3, EdDSA to use existing SSH keys) 48 | 49 | - [X] It should be possible to verify a module file before execution 50 | 51 | - [X] It should be possible to add signed custom sections to a potentially signed module so that one can verify the original module and the additional custom section independently 52 | 53 | See [Appendix 1](#appendix-1). A user may want to add additional signed information (debug data, precompiled headers) to a signed module and then re-distribute. Users may or may not trust and choose to consume the additional information. 54 | 55 | - [X] Signatures should support streaming compilations 56 | 57 | - [X] A module may contain multiple signatures possibly with key identifiers for each signature 58 | - Required for key rotation 59 | - Keys may be short-term 60 | - There can be a signature for sections 1, 2, 3 and another one for sections 1, 2, 3, 4 in order to make section 4 optional, yet still verifiable when needed 61 | - [Oak](http://projectoak.com) use case, where each signature represents a property 62 | - The ability to require multiple signers to trust a module (ex: CI system + module maintainer) 63 | - Key identifiers can be used by verifiers to map to public key identifiers they have, and/or quickly reject a signature if it does not match. 64 | 65 | - [X] The format used to encode signatures and related should be extensible 66 | 67 | - [X] Arbitrary sections may not be signed (partial signature) 68 | 69 | - [X] Arbitrary sections may be ignored during verification (partial verification) 70 | 71 | ## Discussed options 72 | 73 | - **(a) Sign complete bytecode** 74 | 75 | Append “signature” section at the end of the file. 76 | 77 | - **(b) Sign all bytecode preceding the “signature” Section** 78 | 79 | This allows adding new Custom Sections after the signature was created. 80 | See [Appendix 1](#appendix-1). 81 | 82 | - **(c) Sign all bytecode since the previous “signature” section** 83 | 84 | Sign bytecode since the previous signature section or start of the module if there wasn’t any (i.e. signing consecutive groups of sections). 85 | 86 | This allows adding new custom sections after the signature was created, and removing consecutive groups of sections along with their signatures. 87 | 88 | - **(d) Sign hashes of consecutive sections** 89 | 90 | Split sections into parts (consecutive sections, delimited by a delimiter) that can be signed and verified independently, and sign the concatenation of their hashes. 91 | 92 | This allows complete and partial verification of a module using a single signature, as well as adding new custom sections with their signatures. 93 | 94 | See [Appendix 2](#appendix-2). 95 | 96 | - **(e) Include manifest in the “signature” section** 97 | 98 | In the signature section, include a manifest which describes which sections are signed using a given signature. This allows signing arbitrary sets of sections. 99 | 100 | ## Scratch notes 101 | 102 | - Should signatures have associated metadata/annotations? 103 | - Should the signature section include a timestamp, a module version, or more generally, should we define a minimal set of optional/required metadata that will be signed along with the rest of the module? 104 | - We may want the set of signature algorithms we support and the ones required by the [WASI-crypto](https://github.com/jedisct1/WASI-crypto/blob/main/docs/wasi-crypto.md#algorithms) proposal to overlap. 105 | - Add new “description” and “usage” Custom Sections, to be defined in this working group, then presented to the WebAssembly core as a standalone proposal. 106 | 107 | ## Appendix 1 108 | 109 | **Use case for adding new Custom Sections *after* the original signature was generated, and the need for signatures to be able to cover only part of the Wasm module.** 110 | 111 | 1. Wasm module author compiles Wasm module (bytecode) 112 | 2. Wasm module author signs Wasm module (`sign(hash(bytecode))`), and appends the signature in a “signature” (`A`) Custom Section. 113 | 3. Wasm module author distributes signed Wasm module: 114 | 115 | | sections | covered by "signature" (`A`) | 116 | | ----------------- | ---------------------------- | 117 | | bytecode | yes | 118 | | "signature" (`A`) | | 119 | 120 | 4. Customer uploads Wasm module to the Wasm optimization service, which verifies that the Wasm module is signed by the provided public key. 121 | “Wasm optimization” service compiles uploaded Wasm module (`compile(bytecode)`), appends it in a `precompiled_runtimeX` Custom Section, then signs the complete Wasm module (`sign(hash(bytecode+signatureA+precompiled_runtimeX))`), and appends the signature in a “signature” (`B`) Custom Section: 122 | 123 | | sections | covered by "signature" (`A`) | covered by "signature" (`B`) | 124 | | ---------------------- | ---------------------------- | ---------------------------- | 125 | | bytecode | yes | yes | 126 | | "signature" (`A`) | | yes | 127 | | `precompiled_runtimeX` | | yes | 128 | | "signature" (`B`) | | | 129 | 130 | ## Appendix 2 131 | 132 | This signature format allows full and partial signatures, as well as incremental updates. 133 | 134 | Two custom section types are required for this signature format: 135 | 136 | - Custom sections named `signature`, storing signature data, when this information is embedded in the module. 137 | - Custom sections named `signature_delimiter`, separating consecutive sections that can be signed and verified independently. 138 | 139 | Example structure of a module with an embedded signature and delimiters: 140 | 141 | | sections | 142 | | ----------------------------------------- | 143 | | signatures | 144 | | part _(one or more consecutive sections)_ | 145 | | delimiter | 146 | | part _(one or more consecutive sections)_ | 147 | | delimiter | 148 | | ... | 149 | | part _(one or more consecutive sections)_ | 150 | | delimiter | 151 | 152 | **Parts and delimiters:** 153 | 154 | A module can be split into one or more parts (one or more consecutive sections). 155 | Each part is followd by a delimiter. A delimiter is a custom section named `signature_delimiter`, containing a 16 byte random string. 156 | 157 | | sections | 158 | | ---------------------------------------------- | 159 | | `p1` = input part 1 _(one or more sections)_ | 160 | | `d1` = delimiter 1 | 161 | | `p2` = input part 2 _(one or more sections)_ | 162 | | `d2` = delimiter 2 | 163 | | ... | 164 | | `pn` = input part `n` _(one or more sections)_ | 165 | | `dn` = delimiter `n` | 166 | 167 | If a signature covers the entire module (i.e. there is only one part), the delimiter is optional. 168 | 169 | However, its absence prevents additional sections to be added and signed later. 170 | 171 | **Signature data:** 172 | 173 | The signature data is a concatenation of the following: 174 | 175 | - An identifier representing the version of the specification the module was signed with. 176 | - An identifier representing the hash function whose output will be signed. 177 | - A sequence of hashes and their signatures. 178 | 179 | A hash is computed for all the parts to be signed: 180 | 181 | `hn = H(pn‖dn)` 182 | 183 | A signature is computed on the concatenation of these hashes: 184 | 185 | `hashes = h1 ‖ h2 ‖ … ‖ hn` 186 | 187 | `s = Sign(k, "wasmsig" ‖ spec_version ‖ hash_id ‖ hashes)` 188 | 189 | One or more signatures can be associated with `hashes`, allowing multiple parties to sign the same data. 190 | 191 | The signature data can either be stored in the payload of a custom section named `signature`, or provided separately. 192 | 193 | If embedded in a module, the signature data must appear only once, and be the first section of the module. 194 | 195 | It contains a sequence of signatures, where the end of the last signature must coincide with the last byte of the signature data. 196 | 197 | | Field | Type | Description | 198 | | --------------- | ------------ | ------------------------------------------------- | 199 | | spec_version | `byte` | Specification version (`0x01`) | 200 | | hash_fn | `byte` | Hash function identifier (`0x01` for SHA-256) | 201 | | hashes_len | `varuint32` | Length of the concatenated hashes in bytes | 202 | | hashes | `bytes` | Concatenated hashes of the signed sections | 203 | | signature_count | `varuint32` | Number of signatures | 204 | | signatures | `signature*` | Sequence of `signature_count` `signature` records | 205 | 206 | where a `signature` is encoded as: 207 | 208 | | Field | Type | Description | 209 | | ------------- | ----------- | ---------------------------------------------------------- | 210 | | key_id_len | `varuint32` | Public key identifier length in bytes (can be `0`) | 211 | | key_id | `bytes` | Public key identifier | 212 | | signature_len | `varuint32` | Signature length in bytes | 213 | | signature | `bytes` | Signature for `hashes` that can be verified using `key_id` | 214 | 215 | **Signature verification algorithm for an entire module:** 216 | 217 | 1. Verify the presence of the signature section, extract the specification version, the hash function to use and the signatures. 218 | 2. Check that at least one of the signatures is valid for `hashes`. If not, return an error and stop. 219 | 3. Split `hashes` (included in the signature) into `h1 … hn` 220 | 4. Read the module, computing the hash of every `(pi, di)` tuple with `i ∈ {1 … n}`, immediately returning an error if the output doesn't match `hi` 221 | 5. Return an error if the number of the number of hashes doesn't match the number of parts. 222 | 6. Verify that the signature is valid for `hashes`. 223 | 224 | **Partial signatures:** 225 | 226 | The above format is compatible with partial signatures, i.e. signatures ignoring one or more parts. In order to do so, a signer only includes the hashes of relevant parts. 227 | 228 | By default, partial signatures must be ignored by WebAssembly runtimes. An explicit configuration is required to accept a partially signed module. 229 | 230 | **Partial verification:** 231 | 232 | The format is also compatible with partial verification, i.e. verification of an arbitrary subset of a module: 233 | 234 | 1. Verify the presence of the header, extract the specification version, the hash function to use and the signatures. 235 | 2. Check that at least one of the signatures is valid for `hashes`. If not, return an error and stop. 236 | 3. Split `hashes` (included in the signature) into `h1 … hn` 237 | 4. Read the module, computing the hash of every `(pi, di)` tuple to verify, immediately returning an error if the output doesn't match `hi` 238 | 5. Return an error if the number of the number of hashes doesn't match the number of parts to verify. 239 | 6. Verify that the signature is valid for `hashes`. 240 | 241 | Notes: 242 | 243 | - Subset verification doesn't require additional signatures, as verification is always made using the full set `hashes`. 244 | - Verifiers don't learn any information about removed sections due to delimiters containing random bits. 245 | 246 | **Multiple signatures:** 247 | 248 | The format also supports: 249 | 250 | - Multiple signatures for a given section set (`hashes`). Signatures can be added incrementally, without any overhead beyond the signature sizes. 251 | - Arbitrary section subsets and signatures combinations. 252 | - Signature verification even if sections have been reordered. 253 | 254 | **Equivalence between embedded and detached signatures:** 255 | 256 | Signatures can be embedded in a module, or detached, i.e. not stored in the module itself but provided separately. 257 | 258 | A detached signature is equivalent to the payload of a `signature` custom section. 259 | 260 | Given an existing signed module with an embedded signature, the signature can be detached by: 261 | 262 | - Copying the payload of the `signature` custom section 263 | - Removing the `signature` custom section. 264 | 265 | Reciprocally, a detached signature can be embedded by adding a `signature` custom section, whose payload is a copy of the detached signature. 266 | 267 | Implementations should accept signatures as an optional parameter. If this parameter is not defined, the signature is assumed to be embedded, but the verification function remains the same. 268 | 269 | **Implementation complexity:** 270 | 271 | We expect the most common scenario to be entire modules being signed and verified, using one or more signatures. 272 | 273 | Supporting additional use cases introduces implementation complexity, that can be summarized as follows: 274 | 275 | | Complexity | Signatures | Signed sections | Verified sections | Arbitrary combinations | Reordering | 276 | | ---------- | ---------- | --------------- | ----------------- | ---------------------- | ---------- | 277 | | 1 | 1 | all | all | no | no | 278 | | 2 | 1+ | all | all | no | no | 279 | | 3 | 1+ | any subset | signed subset | no | no | 280 | | 4 | 1+ | any subset | any subset | no | no | 281 | | 5 | 1+ | any subset | any subset | yes | no | 282 | | 6 | 1+ | any subset | any subset | yes | yes | 283 | 284 | The specification will define what implementations must, should and may implement based on real-world requirements. 285 | 286 | All support levels share the same signature format, so "must" and "should" feature sets can be updated incrementally. 287 | 288 | ## Appendix 3 289 | 290 | **Algorithms and identifiers:** 291 | 292 | Identifier for the current version of the specification: `0x01` 293 | 294 | A conformant implementation must include support for the following hash functions: 295 | 296 | | Function | Identifier | 297 | | -------- | ---------- | 298 | | SHA-256 | `0x01` | 299 | 300 | **Signature algorithms and key serialization:** 301 | 302 | For interoperability purposes, a conformant implementation must include support for the following signature systems: 303 | 304 | - Ed25519 (RFC8032) 305 | 306 | Public and private keys must include the algorithm and parameters they were created for. 307 | 308 | | Key type | Serialized key size | Identifier | 309 | | ------------------ | ------------------- | ---------- | 310 | | Ed25519 public key | 1 + 32 bytes | `0x01` | 311 | | Ed25519 key pair | 1 + 64 bytes | `0x81` | 312 | 313 | Representation of Ed25519 keys: 314 | 315 | - Ed25519 public key: 316 | 317 | `0x01 ‖ public key (32 bytes)` 318 | 319 | - Ed25519 key pair: 320 | 321 | `0x81 ‖ secret key (32 bytes) ‖ public key (32 bytes)` 322 | 323 | Implementations may support additional signatures schemes and key encoding formats. -------------------------------------------------------------------------------- /meetings/2021/04-09.md: -------------------------------------------------------------------------------- 1 | ## Agenda for the April 9th video call 2 | 3 | - **Where**: hangouts 4 | - **When**: April 9th, 15:00 - 16:00 UTC 5 | - **Location**: *link on calendar invite* 6 | 7 | ## Logistics 8 | 9 | The meeting will be on a google hangouts video conference. 10 | 11 | ## Agenda items 12 | 13 | ## Meeting Notes 14 | 15 | * Goal: Common approach for signing in the Wasm ecosystem 16 | * Signing OCI artifact 17 | * Adding signature in the module itself 18 | * Sigstore’s aim is to make it easier for devs to sign and verify 19 | * How do we go forward with setting the right specification? 20 | 21 | [intros] 22 | 23 | * [WAPM](https://wapm.io/) signing uses minisign 24 | * Wasmer runtime has some use-case for signature part 25 | * Wasme CLI (WebAssemblyHub) uses OCI format 26 | 27 | Implementation & Specification 28 | 29 | * Current status on signing (modules): 30 | * There is nothing official, wasmsign adds a custom section with ecdsa signature. 31 | * Need a clear idea of what people need to do (different embedded information, different algs, needs) 32 | * There was attempt to standardize as part of WebAssembly CG 33 | * Would need to standardize in WASI, probably wouldn’t be part of core spec 34 | * Probably need both Custom section + WAPM package signing + OCI format 35 | * complementary methods, verification at fetch and load 36 | * Signing definitely needs at several levels (packages, Wasm files). 37 | * Linking them. Current spec has some spec on linking, not too widely used, and things will change. 38 | * Streaming compilation and execution: a large Wasm file (e.g. 80 MB) can be used in some applications and streaming execution won’t work if we need to check signature of whole file 39 | * Signatures per function (minimal compilation units) or some manifest that signs bytecode per function, bytecode per section) 40 | * Nothing can start until the whole module is validated (have running checksum at streaming) 41 | * Issues with custom section signing: 42 | * custom sections was introduced for extensibility 43 | * as soon as we agree on name, versioning, de-facto standard of signing modules, no technical issues 44 | * Can add sections in different places 45 | * Data section: shared library could link with ability to check signature 46 | * Streaming may require signature up front (unless everything computes checksum) 47 | * Layered sigs: Existing signatures on original bytecode, then have precompiled may or may not be loaded depending on verifying 48 | * Project Oak signature use cases and requirement (multiple sigs, each signature represents a different property) 49 | * When/why are multiple signatures used? 50 | * Verification on each function/compilation unit in practical use cases? 51 | * pre-compiled sections: 52 | * original signature would only work on the original code 53 | * Maybe placement of signatures can have different semantics? 54 | * structure of signature may change depending on placement of signature (end may be over whole module), beginning may contain manifest with details of function level) 55 | * Placement may not matter, signature placeholder can be anywhere 56 | * Placement at start may be beneficial 57 | * Linking separate modules may not need access to the modules (it could be the engine’s responsibility to check signature and allow/disallow linking) 58 | * If a signature represents a level trust, it may or may not allow linking to a lower level of trust. 59 | * Licensing use-cases 60 | * Related to project oak cases -- information can’t flow “upstream” to trust-level 61 | * Second State (blockchain): 62 | * Relay provider is the mitm to the devs deploying Wasm to the network 63 | * Currently the node runtime/validator will verify the transaction signature, not the data itself 64 | * Can use external signature file or put signature in the custom section 65 | * Second case: create OCI image with Wasm file only, we prefer to put the sig inside the file. 66 | * Use EdDSA with SHA-3 67 | * Blockchain ecosystem: polkadot, [https://cosmos.network/](https://cosmos.network/), [ewasm](https://ewasm.readthedocs.io/en/mkdocs/) 68 | * In any case we will support multiple schemes and have an algorithm identifier 69 | * Compartmentalize section signing: 70 | * Can the Wasm module be modified without breaking the signature? 71 | * Signed module with debug data, how do I remove the debug data and leave the whole thing in touch? 72 | * If the runtime is configured with a public key, it will know it needs to verify and calculate digest. (missing sig == untrusted) 73 | 74 | Requirements: 75 | 76 | * Multiple signature support that can sign for different “trust/licensing” levels 77 | * Signatures that sign separate sections (additional custom sections, debug data) of the module 78 | * Support multiple signature algorithms 79 | * Support streaming compilation -------------------------------------------------------------------------------- /meetings/2021/04-23.md: -------------------------------------------------------------------------------- 1 | ## Agenda for the April 23rd video call 2 | 3 | - **Where**: hangouts 4 | - **When**: April 9th, 15:00 - 16:00 UTC 5 | - **Location**: *link on calendar invite* 6 | 7 | ## Logistics 8 | 9 | The meeting will be on a google hangouts video conference. 10 | 11 | ## Agenda items 12 | 13 | ## Meeting Notes 14 | 15 | * WASI suggested we go through their formal proposal process. [Roadmap](https://github.com/wasm-signatures/design/issues/1) 16 | * Starts with creating a proposal in WebAssebly/design [https://github.com/WebAssembly/design/issues/1413](https://github.com/WebAssembly/design/issues/1413) 17 | * Please add support and discussion there! 18 | * The proposal specification lives on [https://github.com/wasm-signatures/design](https://github.com/wasm-signatures/design) 19 | * Project Oak -- would be nice to have contact for their requirements 20 | * **Please comment on the proposal [issue](https://github.com/WebAssembly/design/issues/1413)!** 21 | * Multiple signature discussion 22 | * Multiple modules, one is a language runtime (re-used), and then the app that re-uses the language. Today we statically link and may sign the whole. But later, a higher level host may want to link the modules. 23 | * Signing patches. Do we want to runtime verify security patches? 24 | * Should dependent modules (on the security patches) have to re-sign? 25 | * Or does someone need to sign the linkage, not the contents. 26 | * A linkage (importing multiple modules) can be a small module that you can sign 27 | * Do we need to preserve signatures on reordered modules? 28 | * Historically, there was a discussion around providing a manifest (for preallocation byte sizes). An argument against requiring a manifest ahead of time was for streaming/unknown cases. 29 | * Target is that May 8th presentation in the CG 30 | * TODO[asraa]: Move meeting process + agenda to the repo 31 | * Anyone who wants to participate should sign up with [W3C](https://www.w3.org/Consortium/membership): 32 | * [https://webassembly.org/community/contributing/](https://webassembly.org/community/contributing/) 33 | * [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/) -------------------------------------------------------------------------------- /meetings/2021/05-07.md: -------------------------------------------------------------------------------- 1 | ## Agenda for the May 7th video call 2 | 3 | - **Where**: hangouts 4 | - **When**: April 9th, 15:00 - 16:00 UTC 5 | - **Location**: *link on calendar invite* 6 | 7 | ## Logistics 8 | 9 | The meeting will be on a google hangouts video conference. 10 | 11 | ## Agenda items 12 | * Finalize policy before CG video call on 05/11 13 | * Discuss who can be at the CG call 14 | * If so, submit agenda item PR at https://github.com/WebAssembly/meetings/blob/master/main/2021/CG-05-11.md 15 | 16 | ## Meeting Notes 17 | 18 | 19 | ### Logistics 20 | * Meeting minutes will be moving to the [repo](https://github.com/wasm-signatures/design) 21 | * Shareable calendar [https://calendar.google.com/calendar/u/0?cid=Y18wbjVqN3I3MWJqY2ZsMWljdWtxNjVrZzZia0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t](https://calendar.google.com/calendar/u/0?cid=Y18wbjVqN3I3MWJqY2ZsMWljdWtxNjVrZzZia0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t) 22 | * Finalize policy before CG video call on 05/25 (4pm-5pm UTC) 23 | * [https://github.com/wasm-signatures/design#webassembly-signatures](https://github.com/wasm-signatures/design#webassembly-signatures) 24 | * TODO: Add a presentation to the repo about goals, concrete use-cases, sketches of design 25 | * Who can be at the CG call 26 | * Asra 27 | * Frank 28 | * Piotr 29 | * Luke Wagner 30 | * <definitely more if you can!> 31 | * Sign up for W3C for participation 32 | * [https://webassembly.org/community/contributing/](https://webassembly.org/community/contributing/) 33 | * [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/) 34 | * TODO: submit agenda item PR at [https://github.com/WebAssembly/meetings/blob/master/main/2021/CG-05-25.md](https://github.com/WebAssembly/meetings/blob/master/main/2021/CG-05-25.md) 35 | 36 | ### Design discussion: 37 | 38 | * Current proposal has a rolling hash, which doesn’t work if we have unsigned (or signed by different parties) sections in the middle of a module (also doesn’t support reordering) 39 | * Both can be supported if we compute different hashes for each section 40 | * Use case for unsigned sections: 41 | * Stripping debug info -- maybe only custom sections? 42 | * We still want custom sections to be signed 43 | * Option C and D allow for removing parts 44 | * Do we all agree that nothing should be unsigned? 45 | * No real need 46 | * Signature format: 47 | * list of hashes, concatenation would be signed 48 | * but if we are parting signatures, a verifier will need to check that every section has been covered 49 | * Another meeting: talk/advertise about a demo 50 | * Detached signatures: 51 | * Will the signature remain valid if they are not attached 52 | * Certain sections don’t need to be ordered, a tool could read and write and reorder 53 | * In principal, reordering is “changing” the module, so sigs might not remain valid 54 | * Start of module may need metadata (version, hash algorithm, (possibly sections?) 55 | * Unless you have a fixed hash algorithm and spec that never changes (or provide that info with the public key) 56 | * Signature section needs structured data (TODO add to repo) 57 | * Could be JSON (no runtimes need JSON, but all know how to parse CustomSections) 58 | * Mirror the [name section](https://webassembly.github.io/spec/core/appendix/custom.html#name-section) 59 | * [https://webassembly.github.io/spec/core/binary/values.html](https://webassembly.github.io/spec/core/binary/values.html) 60 | * ** Please reach out to people to add use-cases!** 61 | -------------------------------------------------------------------------------- /meetings/2021/05-21.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/05-21.md -------------------------------------------------------------------------------- /meetings/2021/06-04.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/06-04.md -------------------------------------------------------------------------------- /meetings/2021/06-18.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/06-18.md -------------------------------------------------------------------------------- /meetings/2021/07-02.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/07-02.md -------------------------------------------------------------------------------- /meetings/2021/07-16.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/07-16.md -------------------------------------------------------------------------------- /meetings/2021/07-30.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/07-30.md -------------------------------------------------------------------------------- /meetings/2021/08-13.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/08-13.md -------------------------------------------------------------------------------- /meetings/2021/08-27.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/wasm-signatures/design/9d565c9ccb6628dc95fc8a7acc1576f4204d47a0/meetings/2021/08-27.md -------------------------------------------------------------------------------- /meetings/README.md: -------------------------------------------------------------------------------- 1 | # Wasm Signature meetings 2 | 3 | Meetings are held every other Thursday at 3:00 PM UTC. 4 | 5 | The link to the calendar is here https://calendar.google.com/calendar/u/0?cid=Y18wbjVqN3I3MWJqY2ZsMWljdWtxNjVrZzZia0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t 6 | 7 | ## Meetings 8 | 9 |
10 | 2021 11 | 12 | * [April 9th video call](2021/04-09.md) 13 | * [April 23rd video call](2021/04-23.md) 14 | * [May 7th video call](2021/05-07.md) 15 | * [May 21st video call](2021/05-21.md) 16 | * [June 4th video call](2021/06-04.md) 17 | * [June 18th video call](2021/06-18.md) 18 | * [July 2nd video call](2021/07-02.md) 19 | * [July 16th video call](2021/07-16.md) 20 | * [July 30th video call](2021/07-30.md) 21 | * [August 13th video call](2021/08-13.md) 22 | * [August 27th video call](2021/08-27.md) 23 | --------------------------------------------------------------------------------