Resumo

  • A chamada para adoção do RATS para draft-poirier-rats-eat-da-10 termina em 11 de setembro de 2026. Ela pergunta se o grupo deve assumir um rascunho individual; não é adoção concluída, RFC ou instrução de implantação.
  • Um Device Assignment Token pode transportar evidência sobre um dispositivo. Não escolhe restrições adicionais, não avalia a evidência, não define a política da parte confiadora nem autoriza o uso do dispositivo.

A chamada trata de um item de trabalho, não de um dispositivo aceito

O objeto público tem nome e versão: An EAT Profile for Trustworthy Device Assignment, revisão 10. O Datatracker ainda o mostra como Internet-Draft ativo e candidato a trabalho do RATS, sem endosso IETF nem posição formal no processo de padrões. Até 11 de setembro, a questão concreta é se o grupo deve trabalhar no texto. Uma disposição posterior pode alterar o estado de um item; não certifica um adaptador, GPU ou função virtual para uma carga específica.

O contexto é relevante. A atribuição permite que uma máquina virtual confiável controle um adaptador de rede, GPU ou função PCIe, embora o hipervisor ou outras máquinas possam estar fora de sua fronteira de confiança. O rascunho pede evidência sobre identidade, firmware e configuração e define o DAT como perfil EAT para representá-la.

Uma representação comum tem valor. Ela torna reivindicações, submódulos, assinaturas e envelopes mais compreensíveis entre implementações. Mas não torna uma observação automaticamente completa, recente ou suficiente para certa carga. Um formato compartilhado reduz ambiguidade no registro; não elimina o julgamento posterior ao registro.

As restrições não estão dentro do formato

O texto afirma que se baseia nas informações fornecidas por SPDM e não impõe restrições de segurança adicionais. Cabe a outras entidades descrevê-las, selecioná-las e aplicá-las conforme requisitos operacionais. Não é lacuna que se possa preencher dizendo que o formato resolveu a segurança. É o ponto em que permanece o controle local.

O proprietário ainda deve escolher âncoras de confiança, estados permitidos de firmware e configuração, idade máxima da evidência, dados de revogação, verificador, regras de encaminhamento e condições de reversão. Um locatário de nuvem, um operador que compartilha GPU e uma organização que protege uma chave sensível podem usar a mesma sintaxe e chegar legitimamente a conclusões distintas. Perdas e deveres não são intercambiáveis.

O escopo atual exige a mesma cautela: privilegia dispositivos PCIe compatíveis com SPDM, deixa dispositivos SPDM em chip para consideração futura e não cobre migração ao vivo de uma máquina virtual confiável. Não se deve anunciar como conclusão de segurança universal um formato que delimita esses casos.

O resultado do verificador não é autorização

RFC 9334 separa a avaliação da Evidência, feita pelo Verificador com valores de referência, endossos e sua política, da avaliação dos Resultados de atestação pela Parte confiadora. Esta aplica sua própria política para uma decisão específica de aplicação, inclusive autorização. As duas políticas podem ser fornecidas ou configuradas por responsáveis diferentes.

RFC 9711 acrescenta uma restrição. Um EAT pode descrever uma entidade para uma decisão de confiança, mas não estabelece regras normativas de processamento para verificadores. Um verificador pode encaminhar, modificar ou complementar reivindicações segundo sua política; a parte confiadora deve compreender esse processamento antes de interpretar o resultado. Assinatura válida e perfil bem formado descrevem um artefato, não uma ordem portátil para permitir um dispositivo.

A carta do RATS preserva a fronteira: inclui formatos e procedimentos para evidência e resultados, mas deixa formatos e protocolos de política de avaliação fora de escopo. A divisão permite interoperabilidade sem fingir que um grupo de trabalho escolhe o apetite de risco de cada organização.

Dois recibos, duas responsabilidades

O recibo público deve guardar a chamada, data, revisão exata, cobertura do perfil, a limitação sobre restrições, comentários e disposição posterior. Não pode virar “RATS aprovou este dispositivo”. Ao lado, é necessário um recibo local: dispositivo e contexto de atribuição, fonte da evidência, âncora aceita, identidade e regras do verificador, valores de referência, frescor, versão de política, escopo de autorização, dono, monitoramento e reversão.

Vale observar a disposição registrada da chamada, a primeira versão do grupo e alterações explícitas de escopo. Para afirmar uma implantação, a evidência decisiva continua na política da parte confiadora, na base de avaliação do verificador, na autorização e no resultado operacional observado. Mantê-las separadas protege o formato em vez de conceder-lhe autoridade que não possui.

Fontes

  1. Chamada RATS para adoção
  2. Registro Datatracker
  3. draft-poirier-rats-eat-da-10
  4. Carta do grupo RATS
  5. RFC 9334
  6. RFC 9711