Resumo

  • suit-report-reason-invoke-pending existe porque o relatório de atestação pode precisar ser assinado antes de chamar um programa que talvez nunca devolva o controle.
  • O log usa o manifesto como dicionário; sem o manifesto exato validado pelo digest, os SUIT_Record não podem reconstruir com segurança o caminho executado.
  • O encerramento de uma implantação exige testemunhos posteriores para entrada no código, continuidade de execução e efeito do serviço.

Um recibo emitido na soleira

O processador chegou ao comando de invocação. Enquanto ainda controla a execução, consegue montar e assinar um relatório. Depois do salto, não há garantia de retorno. Esperar o desfecho pode significar nunca produzir evidência; declarar sucesso antes do salto produz evidência sobre algo que ainda não aconteceu.

A revisão 22 do relatório SUIT escolhe uma terceira resposta. suit-report-reason-invoke-pending registra que a invocação está prestes a ser tentada e que o resultado final não é conhecido. O texto explica que um “success” incondicional seria enganoso se o código falhasse depois.

O termo é útil porque preserva a posição temporal do narrador. Não afirma falha. Também não permite que uma etapa preparatória seja contabilizada como serviço em execução. A assinatura torna aquela declaração resistente a alteração; não amplia seu alcance.

Compactar o log cria uma obrigação de custódia

O SUIT_Record guarda coordenadas: caminho na árvore de dependências, sequência de comandos, deslocamento, índice de componente e propriedades medidas. O significado completo permanece no manifesto. É esse arranjo que permite um relato pequeno em dispositivos limitados.

Por isso, a recepção do relatório não encerra a coleta. O destinatário deve obter o manifesto correspondente e validá-lo por suit-report-manifest-digest. Se houver URI de referência no manifesto raiz, o valor do relatório deve ser idêntico. Sem essa correspondência, os records não podem ser usados para reconstrução.

O número de sequência não substitui o digest. Em um ambiente com vários signatários confiáveis, dois manifestos podem repetir um número. O digest resistente a colisões aponta para a única coleção de bytes capaz de interpretar os offsets.

As system-property-claims carregam um identificador de componente e podem ser processadas antes do manifesto. É uma autonomia específica, não uma licença para adivinhar o sentido dos demais waypoints.

Uma organização que retém o relatório, mas expira o manifesto, conserva autenticidade sem legibilidade. O par relatório-manifesto é a unidade de evidência.

Quatro verificações que não são uma só

Autenticação protege origem e integridade. Freshness — por nonce ou pelo contêiner de atestação — protege contra replay. O digest escolhe o dicionário correto. A avaliação das medições pergunta se o software que produziu a evidência era aceitável.

É possível passar em uma e falhar em outra. Um invoke-pending recém-produzido não é sucesso. Um relatório antigo de sucesso pode estar corretamente assinado. Um manifesto pode corresponder ao digest enquanto o Report Generator executa uma versão reprovada pela política.

Painéis que reduzem tudo a “verified” retiram do operador a pergunta decisiva: o que, exatamente, foi verificado?

O produtor do relatório entra na avaliação

Para uso como Attestation Evidence, o rascunho requer medições do ambiente gerador. O escopo típico inclui Manifest Processor, Report Generator e bootloader ou sistema operacional que os habilita.

Isso trata o gerador como parte da cadeia, não como observador neutro. Uma chave legítima pode proteger a saída de um componente comprometido. Só a avaliação das medições permite distinguir “mensagem intacta” de “mensagem feita pelo software esperado”.

A RFC 9334 separa Attester, Verifier e Relying Party. O Attester produz Evidence; o Verifier aplica política e produz Attestation Results; a Relying Party decide. No caso SUIT, o Verifier ainda precisa do manifesto correspondente para converter waypoints em claims úteis.

Confiança continua sendo uma decisão local. A presença de um contêiner assinado não transfere essa decisão ao emissor.

Proteção de transporte não é testemunho de execução

Relatórios remotos precisam de canal autenticado e confidencial ou proteção equivalente, como EAT ou COSE. Quando a política exige autenticação, o destinatário não pode emitir um relatório não autenticado; um relato parcial obedece à mesma política de integridade.

Essas medidas bloqueiam falsificação e exposição. Elas transportam o limite com fidelidade. Não o removem. invoke-pending chega ao servidor ainda significando que o passo seguinte não foi observado.

O primeiro recibo posterior pode provar que o entry point recebeu controle. Outro, que o processo permaneceu saudável. Um teste externo, que o serviço entregou o comportamento esperado. Misturar os três recria o mesmo erro em outro ponto.

Uma sequência que não pula etapas

Registre os bytes originais, método de proteção, signatário, validação e mecanismo de freshness. Recupere o manifesto exato pelo digest e reconstrua caminho, sequência, offset e componente. Avalie as medições do processador, gerador e plataforma de inicialização. Preserve o resultado original sem substituí-lo pelo que veio depois.

Só então acrescente os testemunhos de runtime:

relatório autêntico → freshness → manifesto exato → reconstrução → ambiente medido → handoff → primeira execução → continuidade → efeito

Na data da pesquisa, a revisão 22 era Internet-Draft ativo, destinado a Proposed Standard. Estava na fila do RFC Editor, bloqueado por uma referência de segunda geração. Não era RFC nem comprovação de implementação.

Fontes