Resumo

  • O RFC 9999 fornece uma estrutura autodescritiva para carregar Evidence, Attestation Results, Endorsements, Reference Values e Appraisal Policies do RATS em CBOR, JSON, JWT, CWT, X.509, HTTP, MIME e CoAP.
  • Record, Tag e Collection CMW orientam identificação, demultiplexação e composição; sozinhos, não oferecem autenticidade, integridade, confidencialidade, frescor, avaliação semântica ou autorização.
  • Quando uma Collection representa um dispositivo composto ou em camadas, os membros precisam estar criptograficamente vinculados; assinaturas isoladas não provam uma origem, uma época e uma transação comuns.

O servidor voltou da manutenção com uma GPU nova. Antes de liberar a carga de produção, a plataforma recebeu uma coleção de atestação. Havia uma entrada para a CPU, outra para a SmartNIC e uma terceira para a GPU. Cada tipo era conhecido, cada carga podia ser analisada e cada assinatura interna era válida.

A plataforma tinha três fatos verdadeiros. Ainda não tinha a prova de que eles descreviam o mesmo servidor.

Um relatório da GPU poderia ter sido guardado antes da troca. A Evidence da SmartNIC poderia vir de uma máquina reserva saudável. Apenas a CPU poderia pertencer ao host que pedia acesso. A coleção continuaria bem formada, e nenhuma chave precisaria ser falsificada. O engano surgiria da composição.

Publicado em julho de 2026 na trilha de padrões do IETF, o RFC 9999 define o Remote ATtestation procedureS Conceptual Message Wrapper, ou CMW. Ele enfrenta um problema legítimo: os papéis RATS trocam diferentes mensagens conceituais em vários formatos de claims, serializações e protocolos. Um invólucro explícito permite que o núcleo de uma aplicação encaminhe formatos novos sem ser redesenhado a cada tecnologia de atestação.

Essa interoperabilidade tem um limite deliberado. O CMW informa que objeto chegou e qual processador deve recebê-lo. Não concede ao objeto autoridade para decidir.

O invólucro preserva a separação de papéis

No RFC 9334, o Attester produz Evidence. O Verifier usa Endorsements, Reference Values e uma Appraisal Policy para avaliar essa Evidence e gerar Attestation Results. O Relying Party aplica sua própria política e decide se concede acesso, entrega uma chave, aceita um comando ou executa outra ação específica.

Esses passos respondem a perguntas diferentes. O equipamento afirmou o quê? A afirmação corresponde a qual estado técnico? Esse estado autoriza qual operação neste serviço? O CMW transporta os objetos entre as respostas; ele não funde as competências.

Um Record CMW contém type, value opaco e, quando necessário, o indicador ind. O indicador pode marcar Reference Values, Endorsements, Evidence, Attestation Results ou Appraisal Policy. Um Tag CMW deriva uma tag CBOR de um CoAP Content-Format por meio do RFC 9277. Uma Collection agrupa itens CMW rotulados e pode conter outras Collections.

O registro IANA RATS Parameters coordena os indicadores. O RFC 9711 define o Entity Attestation Token, e o RFC 9782 define tipos de mídia EAT. O resultado é uma camada de despacho mais previsível.

Um tipo registrado não é um endosso. Ele seleciona uma gramática e um handler. O bit “Evidence” descreve a função pretendida da carga, não comprova que o emissor tinha autoridade nem que os claims são verdadeiros. O registro coordena nomes; não garante suporte, política atualizada ou confiança operacional.

A segurança precisa declarar o que cobre

O RFC 9999 chama o CMW de encapsulamento, não de formato de segurança. Records, Tags e Collections não oferecem sozinhos autenticidade, integridade ou confidencialidade.

A mensagem interna pode já estar protegida. Um CMW em CBOR pode receber proteção COSE segundo o RFC 9052. Um CMW em JSON pode usar JWS, definido pelo RFC 7515. Um canal seguro protege o trânsito. Um desafio pode impedir replay.

Cada mecanismo cobre uma fronteira. A autenticação de um canal não acompanha necessariamente um objeto salvo e encaminhado. Três assinaturas individuais autenticam três cargas, não a relação entre elas. Uma assinatura sobre a Collection protege a composição, mas somente se a chave puder afirmar essa composição e o perfil assinado definir seu significado.

O RFC 9781 torna a diferença visível: UCCS é um conjunto não protegido de claims CWT. Colocá-lo em um CMW facilita o transporte, sem criar autenticidade. O RFC 9999 mostra como adicionar uma assinatura externa. A propriedade vem do controle adicional, não do nome do invólucro.

Por isso, a auditoria deve registrar os bytes protegidos, a camada, a chave, seu propósito, a âncora de confiança e o que acontece depois de armazenamento, extração e repasse. Um campo genérico “assinado” esconde justamente a fronteira que precisa ser provada.

O elo ausente permite a troca de uma peça saudável

Servidores e roteadores são compostos. CPU, SmartNIC e GPU podem ter ambientes de atestação diferentes. Um chassi e suas placas podem produzir Evidence separadamente. Em uma cadeia em camadas, um estágio mede o seguinte antes de transferir controle.

Collection CMW permite reunir formatos heterogêneos. Quando ela representa um único dispositivo composto ou em camadas, o RFC 9999 exige uma vinculação criptográfica de todas as mensagens Evidence. Sem proteção do objeto completo ou ligações internas, um atacante pode substituir a Evidence de um componente comprometido pela de um componente saudável.

Há várias formas legítimas de vincular. O Attester pode assinar a Collection inteira. Os membros podem compartilhar identificadores ou nonce. Podem assinar ou resumir uns aos outros. O protocolo hospedeiro pode definir outra construção verificável. O teste é saber se o escopo validado une cada membro ao dispositivo, à época de topologia e à transação alegados.

Nem toda Collection representa uma máquina. Ela também pode agrupar Endorsements, Reference Values, resultados ou mensagens sobre vários dispositivos. A ordem das entradas não tem significado, e os rótulos são únicos apenas no escopo local. gpu, slot-4 ou firmware dependem de um collection type ou assembly profile, além do inventário real e da geração de topologia.

O contêiner define onde o rótulo está. O perfil define o que o rótulo quer dizer. O inventário prova qual peça ocupa aquela posição agora.

Recursão exige limites próprios

Collections podem conter Collections. A recursão representa bem equipamentos em camadas, mas também aumenta o custo de análise: profundidade, membros, bytes, Base64, operações criptográficas e consultas a serviços externos.

O RFC 9999 permite que a implementação imponha profundidade máxima, deixando fora de escopo a descoberta e negociação exatas. O operador deve fixar tamanho total, número de itens, profundidade, tempo por handler, operações de chave e fan-out de consultas. Reconhecer o primeiro byte não concede orçamento ilimitado.

O desconhecido também precisa de semântica. Um repositório pode guardar um objeto opaco. Um serviço de autorização não pode ignorar um membro desconhecido e declarar que avaliou o conjunto completo. Inválido, não suportado, ausente e opcional pelo perfil são estados distintos.

Cada tipo aceito deve ser acompanhado por versão do handler, perfis permitidos, política de algoritmos, limites e comportamento de falha. Assim, a extensibilidade não se transforma em autorização por omissão.

Frescor e confiança não cabem na etiqueta

Uma Evidence assinada antes de uma atualização ou troca de hardware pode continuar criptograficamente válida e não dizer nada sobre o estado atual. O RFC 9334 trata freshness separadamente, usando tempo sincronizado, nonces ou epoch IDs.

O CMW carrega mensagens que participam desses mecanismos, mas não demonstra que todos os membros responderam ao mesmo desafio. Se a CPU cobre o nonce A, a SmartNIC o nonce B e a GPU apenas um timestamp, o assembly profile e a política do Verifier precisam decidir se há uma transação coerente.

O registro deve preservar desafio, emissor, janela, pressupostos de relógio, época e cobertura por membro. “Assinatura válida” não é sinônimo de “estado atual”.

Depois vem a separação entre avaliação e permissão. O Verifier pode concluir que o firmware atende a uma política. O Relying Party ainda pode negar leitura de dados, assinatura de release ou controle de infraestrutura. Um Attestation Result portátil não deve se tornar um passe universal fora do contexto que o produziu.

O fechamento completo verifica membros esperados, análise, proteção, vínculo, frescor, avaliação, entrega do resultado, decisão do serviço e efeito observado.

A portabilidade também amplia o público

O RFC 9999 permite CMW em certificados X.509, CSRs e CRLs. Reutilizar PKIX é conveniente, mas pode tornar duradouros dados de hardware que antes circulavam em uma troca privada.

Um solicitante pode revelar à Certification Authority o modelo e o nível de patch de um HSM sem autorizar a publicação para todos os destinatários do certificado. O RFC 5280 define o perfil geral de certificados e extensões; ele não fornece esse consentimento. O RFC 3647 fornece o quadro para certificate policy e certification practice statement. O RFC 9999 recomenda que a prática diga quando a CA pode incluir Evidence recebida de terceiros.

Minimização de claims, audiência, retenção, perfil e autorização precisam ser decididos antes da emissão. Revogação não recolhe cópias de informações já distribuídas.

A prova final está na cadeia executada

O princípio de running code de Heng Lu desloca o foco para o caminho real: parser, handler, bytes, chaves, vínculo, frescor, versão da política, decisão e efeito. A conformidade do CMW é uma evidência nessa cadeia, não o seu desfecho.

A ideia de especificação inicial mínima e decisão futura localizada sustenta a divisão: invólucro e registros comuns mantêm a interoperabilidade; limiares de saúde, autorização e responsabilidade permanecem com operadores identificáveis.

A leitura por camadas de realidade mantém separados quatro fatos: sintaxe válida, proteção criptográfica, avaliação semântica e efeito operacional. Um painel confiável não apaga essas divisões; ele as torna auditáveis.