Design: Assinatura / Verificação do Módulo WASM

Acredito que também precisamos do equivalente no formato de texto, talvez algo como: (signature ...) .

Para CSP, a verificação da assinatura pode estar ATIVADA em https? Ou você acha que deveria estar ativado por padrão?

Hmmm, "CSP e verificação": isso seria muito no início do processo. Precisaríamos de uma (ou múltipla) chave pública do servidor ou qualquer outra instância para verificação, e deve ser uma chave pública usando EC (curva eclíptica).

Se fosse relacionado a um serviço baseado em HTTP (S), seria necessário obter acesso à chave pública correspondente (chave de curva elíptica). Talvez a chave pública correspondente possa ser incorporada como atributo de cabeçalho HTTP da página da web que está carregando os módulos WASM.

Tendo assinado os módulos WASM, eles podem ser buscados em qualquer local e verificados.

Haveria uma única organização (hoster) assinando arquivos WASM ou uma página da web buscaria módulos assinados de várias organizações / fornecedores?

No caso de múltiplas organizações, seja adicionando o "organization-id" à própria assinatura, ou definindo algum tipo de SignerOrg como Seção adicional (tamanho fixo também). o processo pode ser parecido com: primeiro anexar o SignerOrg Seciton e, em seguida, assinar ambos (bytecode do módulo original e seção signerorg)

parece que o caso de uso e o processo devem ser definidos primeiro;)

Gostaria de entender melhor como os mecanismos atuais da Web para assinatura e verificação falham e como o suporte de primeira classe do WebAssembly resolveria isso. Especificamente, a Web tem HTTPS e integridade de sub-recursos que, embora definitivamente não sejam perfeitos, já fazem muito por nós.

Você poderia explicar em detalhes o que deseja consertar e como sua proposta não apresenta as mesmas armadilhas?

Bem, eu posso tentar

Assinaturas incorporadas já são usadas para PDF, binários Win, drivers, documentos XML, etc.
Para que servem os módulos WebAssembly assinados?

Apenas imagine

• Aplicação Web executando o código WebAssembly para calcular os PINs do Banking.
• Aplicativos Rust / C ++ usando WebAssembly para mecanismos de execução incorporados, avaliando contratos de cripto-moeda
• HSM-s usando bytecode WebAssembly para calcular PINs no backend do servidor
• Dispositivos IoT cujo firmware é montado usando versões específicas de diferentes módulos WebAssembly (Content Addressable Storage / Linking)

No último caso, a versão do firmware dos dispositivos IoT seria uma lista de módulos WebAssembly usando versões específicas. Os dispositivos IoT podem espalhar sua versão dos módulos WebAssembly para outros dispositivos na vizinhança (http://www.korhal.io/whitepaper.pdf). Nenhum servidor de atualização central seria necessário.

Em todos esses casos, um transporte TSL não é suficiente para estabelecer a confiança, mas o código deve ser assinado para que o destinatário seja capaz de verificar a autenticidade, integridade em toda a cadeia de abastecimento, desde o desenvolvedor / fornecedor até o navegador da web ou execução motor.
A assinatura impede a violação de dados em repouso e no aspecto legal. Não repúdio para código de operação crítica.

Usar uma assinatura separada (em comparação com uma assinatura embutida no módulo WASM) seria mais complexo de manusear. A assinatura embutida simplificaria o manuseio ao longo da cadeia de fornecimento de bytecode.

Não estou convencido de que este seja um problema melhor abordado no nível do próprio WASM. As assinaturas podem ser adicionadas a qualquer dado. Por que eles precisam fazer parte da própria linguagem?

Além disso, parece-me que você pode estar interessado no padrão HTTP Origin-Signed Responses .

Triste ouvir. Parte do idioma, porque um wasm assinado manteria um arquivo wasm válido; portanto, não seria uma espécie de invólucro a ser removido antes da análise. Bem, graças à existência de CustomSection, é possível adicionar tais estruturas. Seria bom movê-lo de "recurso personalizado" para "recurso padrão".