Resumo

  • A revisão 01 dos casos de uso do SEAT separa vínculo ao canal, frescor da evidência, autenticação composta, atestação em runtime e deriva de estado em conexões longas ou retomadas.
  • TLS pode permanecer criptograficamente íntegro depois que o ambiente aceito muda. O handshake prova uma observação limitada no tempo, não uma autorização permanente.

Às 9h, um servidor conclui TLS com evidência recente ligada à conexão. O Verifier aceita firmware, sistema, workload e controles; o Relying Party entrega um segredo. Às 14h, os registros TLS continuam válidos, mas o workload migrou, o agente de IA ganhou uma ferramenta ou uma proteção foi desligada.

O transporte não falhou. A condição que justificou o acesso pode ter falhado.

Esse é o limite temporal de draft-ietf-seat-use-cases-01, atualizado em 15 de setembro de 2026 e válido até 19 de março de 2027. É um Internet-Draft do grupo SEAT em I-D Exists. A capa diz Informational; Datatracker deixa Intended RFC status vazio e não registra shepherd, area director responsável ou telechat. Não há ações IANA. O documento define objetivos e casos para orientar uma solução futura, não o mecanismo, a política de appraisal, uma implementação ou resultado medido.

Canal e máquina comprovam coisas diferentes

TLS e DTLS autenticam um peer por chave e identidade de rede. Remote attestation acrescenta Evidence sobre Target Environment: hardware, firmware, software e configuração. Assim é possível separar quem mantém o canal de qual ambiente o executa e se esse estado é aceitável.

Um certificado válido não comprova que a chave continue não exportável ou que secure boot permaneça ativo. Evidência verdadeira de outra plataforma também não prova que ela controla a conexão atual. Por isso a revisão 01 exige binding criptográfico entre Evidence ou Attestation Result e a conexão específica, bloqueando relay de um contexto alheio.

Compound authentication, machine identifier, peer authentication e attestation credential freshness aparecem como objetivos distintos. Um único “pass” não responde a todos.

Evidência fresca começa a envelhecer imediatamente

Frescor combate replay de um estado antigo. Binding impede transplante para outro canal. Juntos demonstram uma afirmação suficientemente recente, sob uma regra, pertencente a um contexto. Não congelam o endpoint.

O draft identifica state drift em conexões long-lived e resumed, inclui runtime attestation e distingue periodic de on-demand. A evidência pode ser autêntica e se tornar obsoleta sem que TLS rejeite um byte.

Um AI agent pode manter o mesmo binário enquanto muda modelo, prompt, ferramentas e permissões. Workload pode migrar, reference value ser revogado e proteção de chave cair. O record layer não mede esses eventos.

A frase correta é limitada: um ambiente foi avaliado em certo instante, com regra de frescor e geração de política, e o resultado foi ligado à conexão. Continuidade criptográfica não é continuidade automática da aceitabilidade.

Resumption e KeyUpdate renovam outras coisas

TLS resumption estabelece nova conexão a partir de estado anterior. Pode preservar continuidade criptográfica, mas não decide se a evidência ainda é jovem, se o Target Environment é o mesmo, se Verifier e política mudaram ou se maior privilégio pede nova medição.

O texto exige que a solução trate isso, sem escolher prazo universal. Uma leitura e uma entrega de segredo aceitam riscos diferentes. O valor pode ser local; o recibo não deve ser invisível.

KeyUpdate renova traffic keys sem repetir toda a negociação. Não mede firmware nem tool set. Frescor de chave de transporte, de Evidence e de autorização são três relógios.

Passport e Background Check deslocam o custo

No modelo Passport de RATS, o Attester obtém resultado e o apresenta. No Background Check, o Relying Party consulta um Verifier. A revisão 01 associa Background Check a máximo frescor e Passport a escala, desempenho ou indisponibilidade do Verifier.

Passport precisa de validade e anti-replay. Background Check precisa de disponibilidade, latência e regra de timeout. Prazo curto reduz janela obsoleta e aumenta carga e DoS; prazo longo melhora continuidade e prolonga aprovação herdada.

Mais frequência também amplia privacidade: Evidence pode revelar composição, configuração e identidade de workload. O documento considera perda de privacidade após comprometimento de ephemeral key ou traffic secret. Não basta dizer “ateste mais”. É preciso limitar público e retenção.

Comprometer cada chave produz um problema diferente

Se a TLS authentication key for roubada, pode ser re-hospedada. Atestação ajuda apenas se chave, ambiente e conexão estiverem ligados para expor a substituição. Se a attestation key for comprometida, o atacante pode fabricar Evidence aparentemente válido; um binding perfeito não torna honesto o Attester.

Key attestation na emissão do certificado também prova apenas aquele momento. Ela pode mostrar módulo de geração e armazenamento, não seu estado no início de uma conexão futura nem ao longo de horas.

O resultado alimenta uma autorização local

Evidence e Attestation Result não são ordens universais. A política local combina resultado, operação e risco. O draft deixa appraisal policy fora de escopo. Nova medição pode ser válida e falhar uma política nova; o mesmo estado pode permitir leitura e negar secret provisioning.

A doutrina de especificação inicial mínima de Heng Lu sustenta um contrato pequeno para binding, frescor e semântica. A primazia do código pede recibos de que o sistema realmente solicitou refresh, invalidou aprovação antiga e retirou autorização.

Operadores deveriam registrar transcript binding, IDs de Evidence e Result, base de frescor, Verifier e geração de política, Target Environment, linhagem de resumption e última aceitação. Gatilhos incluem migração, retomada, privilégio, ferramenta, rotação, alerta, revogação e idade máxima. São recomendações editoriais, não requisitos da revisão 01.

Binding fecha a substituição. Reatestação e retirada fecham o tempo. Um canal íntegro não transforma uma observação antiga em estado atual.

Fontes