Resumo

  • Um conjunto de Endorsers confiáveis não informa qual deles pode acrescentar alegações sobre aplicação, sistema operacional, firmware ou hardware.
  • A assinatura do fornecedor do OS pode ser autêntica e ainda assim estar fora de escopo quando descreve a camada física.
  • A revisão 11 admite que o vínculo de escopo fique na política, na Evidence ou em ambas; o recibo precisa registrar qual fonte de autoridade foi usada.

Uma plataforma de atestação pode verificar todas as assinaturas e mesmo assim conceder voz à empresa errada. O caso não exige invasor. Basta reunir fornecedores de aplicação, OS, firmware e hardware numa única lista de confiança e esquecer que confiança tem assunto.

A revisão 11 de RATS Endorsements descreve essas quatro camadas como Target Environments. Cada fornecedor pode anexar claims adicionais sobre sua parte. O Verifier, porém, deve distinguir qual Endorser está autorizado a produzir Endorsement sobre qual ambiente. O próprio texto usa o contraste: confiar no Endorser do OS para o OS não o autoriza a falar do hardware.

O certificado resolve identidade e integridade. Não resolve competência. Se o software transforma “cadeia válida” em “declaração admitida em qualquer camada”, a criptografia mascara a ampliação do mandato.

O rascunho não obriga uma única localização para esse vínculo. A Appraisal Policy for Evidence pode contê-lo. A Evidence pode declarar quem pode complementar um Target Environment. Uma implementação pode combinar os dois. Isso acomoda modelos diferentes, mas torna insuficiente arquivar só a Endorsement assinada.

Dois Verifiers podem receber a mesma mensagem e divergir porque usam mapas de camada, versões de política ou delegações na Evidence diferentes. Sem registrar o vínculo efetivo, um auditor verá quem assinou, mas não por que aquela alegação entrou no julgamento.

RFC 9334 ajuda a manter a separação: Endorser fornece claims; Verifier Owner governa a política de avaliação; Relying Party Owner decide o que fazer com o Attestation Result. Provar origem, avaliar confiança e liberar uma ação são atos distintos.

Uma regra condicional também não substitui o mandato. Ela pode decidir quando um conjunto de claims se aplica, mas não decide por si só se o dispositivo é confiável e não autoriza o Endorser sobre toda a máquina. Um casamento exato pode aceitar uma claim verdadeira no formato e ainda errada na autoridade.

Nem a descoberta da chave encerra a questão. O UEID de RFC 9711 pode orientar a busca do material de verificação. A revisão 11 deixa a outros protocolos a granularidade da chave — instância, classe ou outro conjunto de claims. A chave certa não define automaticamente a camada certa.

O registro mínimo precisa unir: Evidence com frescor; identidade, cadeia e vigência do Endorser; mapa e identificador do Target Environment; regra que autoriza aquele ator para a camada e classe de claim; versão de Endorsement escolhida; identidade do Verifier e da política; decisão do Relying Party e efeito observado.

O histórico coloca a revisão 11 em IESG Evaluation e na agenda de 8 de outubro de 2026. O diff 09–11 permite inspecionar as mudanças. O texto da revisão 11 continua sendo Internet-Draft, não RFC.

A revisão 11 de CoRIM oferece um contexto de dados concreto. Sua adoção não comprova que a implementação aplicou corretamente o escopo de cada Endorser.

Fontes