Resumo

  • O measured component reúne nome estável, versão opcional, valor bruto ou digest com algoritmo e identificadores opcionais das autoridades que assinam ou identificam o componente. Essas autoridades não identificam o attester que assinou o EAT externo.
  • O profile precisa definir o papel e a ordem de authorities e o sentido dos 64 bits de flags. Sem conhecer esse profile, o consumidor deve rejeitar o EAT que contenha esses campos.
  • O recibo operacional liga componente, limite da amostra, medição, autoridade, profile, assinatura externa, freshness, referências, política do verificador, resultado e decisão autônoma da relying party.

O painel dizia apenas “authority verified”. Isso parecia suficiente até o dia em que uma equipe entendeu “fabricante do firmware”, outra leu “dispositivo que produziu a evidência” e uma terceira tratou a frase como autorização de acesso.

A RFC 10013 existe, em parte, para impedir esse empréstimo de sujeito. Publicada em julho de 2026, ela é obra de Simon Frost, Thomas Fossati, Hannes Tschofenig e Henk Birkholz. O perfil do IETF registra Tschofenig em extensa atividade de segurança, e a Universidade da Bundeswehr de Munique o apresenta como professor de Secure Networks desde março de 2026. A biografia delimita a contribuição; não atribui a ele autoria exclusiva nem controle das implementações.

A amostra não carrega sua própria confiança

O componente pode ser firmware, boot loader, software em memória, arquivo, configuração ou registrador de CPU. O nome é obrigatório, a versão é opcional e a medida pode ser raw ou um digest acompanhado do algoritmo.

O formato também reserva authorities e oito bytes de flags. Esses campos aumentam a expressividade, mas não transformam medição em veredito. O digest não revela quem executou a coleta, qual foi o target exato, quando ocorreu, se houve replay ou qual referência aprovada deveria corresponder.

Uma comparação correta pode usar uma referência errada. Uma medida perfeita pode mirar o componente errado. Um valor antigo pode ser reproduzido sem alterar um bit. Por isso a RFC 9711 exige autenticidade e integridade do EAT, mas não promete uma força universal para o attester ou para a coleta de claims.

O authority ID termina no componente

Segundo a RFC 10013, a autoridade identifica o componente de modo autoritativo por assinatura digital. A assinatura pode ser validada na instalação ou na execução por boot firmware, sistema operacional ou launcher. O identificador pode apontar para certificado X.509, chave pública, thumbprint ou outro valor ligado à chave.

O texto então exclui a inferência decisiva: essa assinatura não é a assinatura do attester sobre a evidência EAT. O authority identifier não aponta, por si, para o signatário do token envolvente.

Autor de firmware, sistema de atualização, dono da frota e auditor podem aprovar o componente. Depois, o ambiente de atestação mede o target e fala com outra chave. As partes podem pertencer à mesma empresa, mas a mensagem não pressupõe isso.

A RFC 9019 aplica disciplina semelhante a updates. Autenticar quem assinou imagem ou manifest alimenta a autorização; não substitui permissões. Em infraestrutura crítica, autor e operador podem precisar assinar. A chave identifica a voz, não amplia seu mandato.

Sem profile, posição não é papel

O array pode conter várias autoridades e sua ordem pode ter significado. Um deployment coloca fabricante, fleet owner e auditor; outro organiza de outra forma. Os 64 bits de flags também são locais.

O EAT profile deve declarar se usa authorities, o que cada entrada representa e como seu tipo é interpretado. Deve fazer o mesmo com flags. O consumer que não conhece o profile e recebe esses campos precisa rejeitar o token.

Não é permitido descartar o desconhecido nem reaproveitar o dicionário de outro produto. A assinatura externa cobre os bytes, mas não cria semântica.

Essa regra materializa uma especificação inicial mínima. O padrão compartilha a estrutura indispensável e o limite onde adivinhar é perigoso; o profile local conserva decisões que apenas seu operador pode tomar. A coordenação não precisa ocupar o lugar do principal.

No rollout, producers e verifiers precisam avançar na ordem certa. Um novo profile emitido cedo gera rejeição visível. Fallback permissivo mantém disponibilidade ao preço de produzir um “pass” que ninguém consegue explicar.

O relying party ainda decide

O attester protege Evidence e normalmente vincula freshness por nonce. O verifier identifica a chave, avalia a associação ao target, consulta endorsements, reference values e uma appraisal policy. Sua saída é um Attestation Result.

A RFC 9334 deixa a relying party aplicar outra política ao recurso e à operação. Um notebook pode estar saudável e pertencer à organização errada. Um componente pode ser aprovado para telemetria e proibido para comando. Um resultado autêntico pode estar velho para uma transação sensível.

Há, portanto, quatro vozes: autoridade do componente, attester, verifier e dono do recurso. O problema de agência surge quando uma voz é tratada como representante automático da próxima. Um token comum não cria procuração comum.

Identidade estável precisa de limite de divulgação

Manter o nome do componente ao longo de releases facilita comparação e suporte. A mesma estabilidade permite tracking. A RFC alerta que nome e versão podem revelar software, configuração e informação sobre o proprietário.

Identificadores de chave reutilizados também criam correlação. O profile deve separar quem necessita da medição detalhada de quem só precisa de um resultado reduzido, limitado por operação e tempo.

Minimização não é eliminar prova interna. É preservar material suficiente para auditoria e evitar que ele se torne um identificador global distribuído a qualquer relying party.

Como montar o recibo

Guarde o EAT exato ou objeto endereçado por conteúdo, media type, encoding, profile e versão. Registre algoritmo externo, chave do attester, proveniência, nonce, instantes de coleta e recebimento e versão do verifier.

Para cada componente, retenha nome, convenção de versão, target, limite de sampling, raw/digest, algoritmo e valor. Mantenha a ordem das authorities, a definição do profile, a evidência de assinatura do componente e o resultado. Preserve flags brutos e interpretação.

Na avaliação, nomeie provider, conjunto e versão de reference values, todas as comparações, medidas ausentes, policy e versão e Attestation Result. No final, identifique relying party, recurso, ação, policy, decisão, restrição, expiração e remediação.

Esse desenho separa profile desconhecido, componente não aprovado, assinatura externa inválida, Evidence velha, digest divergente e aparelho conforme porém sem autorização. Cada falha chega ao dono certo.

Running-Code Primacy torna o comportamento do sistema a observação decisiva. Um badge sem inputs, profiles e policies não mostra esse comportamento; apenas o resume além do que a evidência permite.

Fontes