Design: WASMモジュールの署名/検証

(signature ...)ような、テキスト形式の同等のものも必要だと思います。

CSPの場合、署名のチェックはhttps経由でオンになる可能性がありますか？ または、デフォルトの動作でオンにする必要があると思いますか？

うーん、「CSPとチェック」：それはプロセスの非常に早い段階です。 検証には、サーバーまたはその他のインスタンスの（または複数の）公開鍵が必要であり、EC（楕円曲線）を使用した公開鍵である必要があります。

HTTP（S）ベースのサービスに関連する場合は、対応する公開鍵（楕円曲線鍵）にアクセスする必要があります。 おそらく、対応する公開鍵は、WASMモジュールをロードしているWebページのHTTPヘッダー属性として埋め込まれている可能性があります。

WASMモジュールに署名すると、これらは任意の場所からフェッチして検証できます。

WASMファイルに署名する単一の組織（ホスティング業者）が存在するのでしょうか、それともWebページが複数の組織/サプライヤーから署名されたモジュールをフェッチするのでしょうか？

複数の組織の場合、署名自体に「organization-id」を追加するか、ある種のSignerOrgを追加のセクションとして定義します（サイズも固定）。 プロセスは次のようになります。最初にSignerOrgSecitonを接続し、次に両方に署名します（元のモジュール-バイトコードとsignerorg-セクション）

ユースケースとプロセスを最初に定義する必要があるようです;）

署名と検証のためのWebの現在のメカニズムがどのように失敗するか、そしてファーストクラスのWebAssemblyサポートがこれをどのように修正するかをよりよく理解したいと思います。 具体的には、WebにはHTTPSとサブリソースの整合性があり、完全ではありませんが、すでにかなりの成果を上げています。

修正したいことと、提案に同じ落とし穴がないことを詳しく説明していただけますか？

さて、私は試すことができます

埋め込まれた署名は、PDF、Winバイナリ、ドライバ、XMLドキュメントなどにすでに使用されています。
署名されたWebAssemblyモジュールは何に適していますか？

ただ想像する

• Web-Banking-PINを計算するためのWebAssemblyコードを実行するアプリケーション。
• 組み込み実行エンジンにWebAssemblyを使用し、暗号通貨契約を評価するRust / C ++アプリケーション
• HSM-sはWebAssemblyバイトコードを使用してサーバーバックエンドのPINを計算します
• 異なるWebAssemblyモジュールの特定のバージョンを使用してファームウェアがアセンブルされているIoTデバイス（コンテンツアドレス可能ストレージ/リンク）

後者の場合、IoTデバイスのファームウェアバージョンは、特定のバージョンを使用するWebAssemblyモジュールのリストになります。 IoTデバイスは、WebAssemblyモジュールのバージョンを近隣の他のデバイスに拡散する可能性があります（http://www.korhal.io/whitepaper.pdf）。 中央更新サーバーは必要ありません。

これらすべての場合において、TSLトランスポートは信頼を確立するのに十分ではありませんが、受信者が開発者/サプライヤーからWebブラウザーまたは実行までのサプライチェーン全体で信頼性、整合性を検証できるように、コードに署名する必要がありますエンジン。
署名は、保存データの改ざんを防止し、法的な側面では、操作が重要なコードの否認防止を防ぎます。

（WASMモジュールに埋め込まれた署名と比較して）切り離された署名を使用すると、処理がより複雑になります。 埋め込まれた署名は、バイトコード-サプライチェーン全体の処理を簡素化します。

これがWASM自体のレベルで最もよく対処される問題であると私は確信していません。 署名は任意のデータに追加できます。 なぜ彼らは言語自体の一部である必要があるのでしょうか？

また、 HTTP Origin-Signed ResponsesStandardに興味があるように思えます。

聞いて悲しい。 言語の一部。署名されたwasmは有効なwasmファイルを保持するため。 したがって、解析する前に削除するラッパーのようなものではありません。 そうですね、CustomSectionの存在のおかげで、そのような構造を追加することが可能です。 ただ、それを「カスタム機能」から「標準機能」に移行できればよかったのにと思います。