Resumo

  • RFC 9783 perfila um Entity Attestation Token para PSA Initial Attestation e limita as alegações de nonce, client ID, instance ID, implementation ID, ciclo de vida e componentes de software.
  • Um token protegido pode sustentar a apreciação de um Verifier, mas não determina a política de um Relying Party sobre inscrição, acesso, retenção ou ato posterior.

O ponto de partida correto é a divisão de papéis descrita em RFC 9334. O Attester produz Evidence. O Verifier aprecia essa evidência. O Relying Party usa o Attestation Result para uma finalidade própria. RFC 9783 trabalha a representação PSA da evidência, dentro do contexto de Entity Attestation Token. Não transforma uma mensagem assinada em decisão pré-aprovada para todos os sistemas que venham a recebê-la.

O nonce é a prova mais intuitiva do limite. O perfil exige um único valor, com 32, 48 ou 64 bytes. Ele associa o relatório a um desafio e permite verificar se a evidência é recente em relação àquela solicitação. Isso é essencial contra replay. Mas a conclusão termina aí: frescor não prova que o solicitante possui o serviço, que o administrador autorizou o equipamento, que a frota foi aprovada ou que o acesso deve durar. A evidência pode ser nova e ainda assim ser insuficiente para a decisão pretendida.

O client ID também protege uma afirmação estreita. Ele representa o domínio de segurança que chamou o serviço Initial Attestation. O RFC exige que o Verifier o confira, impedindo que um endpoint se apresente como outro domínio. A checagem correta separa chamadas que não devem ser confundidas. Ela não identifica automaticamente o titular de uma conta, não cria vínculo operacional e não distribui privilégios. Saber de qual domínio veio uma solicitação não é o mesmo que decidir o que aquele domínio pode fazer.

A distinção entre instance ID e implementation ID reforça o argumento. O primeiro identifica uma chave de atestação e uma instância específicas. O segundo identifica uma montagem imutável de hardware PSA Root of Trust, e não uma instância individual; ele pode orientar o Verifier na busca de material do Endorser, como dados de fabricante ou situação de certificação. São respostas a perguntas diferentes: qual instância emitiu e qual implementação é declarada. São informações que podem ser necessárias para uma avaliação rigorosa, mas nenhuma delas resolve a responsabilidade de admitir, recusar, limitar ou revisar um uso.

Lifecycle e software components não mudam essa distribuição. O estado de ciclo de vida tem valores maior e menor, e o perfil indica estados em que o relatório não deve merecer confiança. Os componentes descrevem código, configuração e outros elementos carregados dentro do escopo medido do PSA Root of Trust. Um Verifier pode usar tudo isso para rejeitar uma evidência, exigir outro perfil ou produzir um resultado condicionado. Ainda não há prova de finalidade atual da carga, aprovação do cliente, mandato de operador, autorização de exceção ou efeito produzido após uma execução.

É por isso que um resultado técnico favorável pode coexistir com uma recusa correta. O Verifier pode aceitar nonce, domínio, implementação e ciclo de vida de acordo com sua política. O Relying Party pode negar a inscrição porque o equipamento não integra a frota aprovada, oferecer acesso provisório porque faltam elementos de Endorser, ou exigir autorização distinta antes de uma ação irreversível. Essa separação revela o responsável por um erro. Sem ela, o token passa a carregar decisões que ninguém decidiu possuir.

O princípio de Heng Lu sobre especificação inicial mínima favorece essa modéstia técnica: padronizar o suficiente para testar alegações comuns, sem capturar decisões futuras e locais. O fato de o código funcionar e o relatório validar mostra que um mecanismo produziu e verificou evidência. Não substitui quem deve controlar um serviço, suportar uma perda ou explicar uma autorização.