Resumo

  • O draft-sato-soos-pt-03, anunciado em 5 de setembro de 2026, é um Internet-Draft individual ativo, sem endosso ou posição formal na IETF, fluxo RFC, Area Director responsável ou data de telechat.
  • A revisão 02 colocava ProgressiveTrustSummary no contexto HEM, mas não determinava a composição da assinatura. A 03 exige que o resumo seja um campo dentro de toda HEM Escalation Request antes de o GEC assiná-la.
  • O novo texto proíbe a interface do principal humano de tratar como autorizado um resumo entregue fora do envelope assinado de sua solicitação.
  • pt_summary_hash continua sendo um SHA-256 do JSON canônico, útil para conferir o resumo depois da extração. A autenticidade na hora da decisão vem de kernel_signature, a assinatura da solicitação que o contém.
  • Um recibo conjunto deveria preservar hem_id, preimagem assinada, signatário e chave, resultado da verificação, caminho do resumo, hash extraído e transformações dos intermediários. Essa é uma recomendação de Daniel Kade, não uma regra da IETF.

O risco está no encaixe, não só no número

O aviso de 5 de setembro apresenta Progressive Trust como um modo de converter o comportamento de um agente ao longo de sessões em recomendações estruturadas sobre autoridade. O Datatracker classifica a revisão 03 de Tom Sato como Internet-Draft individual ativo e esclarece que ela não tem endosso nem posição formal na IETF. Não há fluxo RFC, Area Director responsável ou telechat. Standards Track, no cabeçalho, é a intenção do autor.

PT observa cinco eixos: calibração da autoavaliação, critério para chamar uma pessoa, eficácia, precisão e adaptação depois de uma negativa. O ProgressiveTrustSummary reúne as notas, tendências, número de sessões, visão composta, recomendações pendentes e pt_summary_hash.

O resumo pode estar perfeito e ser o resumo errado para aquela tela. Um serviço analítico pode devolver uma versão em cache. Um gateway pode extrair os campos para localização. Uma resposta atrasada pode chegar quando outro hem_id já ocupa a interface. A consistência interna dos dados não denuncia que o vínculo com o gatilho, a ação e o destinatário foi rompido.

A contribuição nova do PT-03 é definir a unidade de autenticação. A pergunta deixa de ser “o hash deste resumo bate?” e passa a ser “o signatário incluiu este resumo nesta solicitação antes de assiná-la?”.

A revisão anterior deixava a montagem em aberto

A revisão 02 congelada mandava o GEC incluir o resumo em cada HEMContext enviado no escalonamento. Também exigia o cálculo no momento da invocação e mantinha o hash. A redação, porém, permitia ler “contexto” como um painel preenchido por uma segunda consulta depois de a solicitação principal já estar assinada.

A comparação oficial mostra o reparo. Na revisão 03, ProgressiveTrustSummary passa a ser um campo dentro de toda HEM Escalation Request e precisa ser composto antes da assinatura prevista na Seção 18.8 de HEM. A interface receptora não deve reconhecer como autorizado um resumo que chegue fora do envelope assinado da solicitação.

O próprio texto diz que a correção responde ao principal achado de uma WIMSE Security Review. A pesquisa comum em fontes públicas não localizou um artefato separado dessa revisão. Portanto, esta matéria atribui a afirmação ao rascunho e não presume conteúdo que não pôde ser examinado. A alteração entre as duas versões, por outro lado, é diretamente verificável.

O detalhe temporal é decisivo. “Mostrar no contexto” descreve o resultado visual. “Compor antes de assinar” define uma operação verificável. No segundo caso, alterar o resumo, o identificador ou o gatilho invalida a relação criptográfica do objeto inteiro.

Hash e assinatura resolvem problemas diferentes

O campo pt_summary_hash é descrito como SHA-256 do JSON canônico. O PT-03 o chama de conveniência para revalidação independente após a extração, inclusive em auditoria. Isso é útil: quem separa o resumo da solicitação pode demonstrar que manteve a mesma representação. Mas o hash não autentica o resumo para a pessoa que decide.

O RFC 8785 explica por que operações criptográficas sobre JSON precisam de uma representação canônica e repetível. Essa disciplina evita que diferenças triviais de serialização produzam resultados incompatíveis. Ela não diz quem escolheu os dados, a qual solicitação pertencem ou quem os recebeu. Quem consegue substituir um objeto não autenticado também pode calcular o hash do substituto.

A revisão 07 de HEM fornece o envelope. O GEC assina a HEM Escalation Request completa com Ed25519, e kernel_signature cobre a serialização canônica dos demais campos. HEM-07 também descreve progressive_trust_summary como campo obrigatório da solicitação. Assim, o verificador avalia uma afirmação conjunta: este GEC associou este resumo a este escalonamento.

Uma assinatura válida não torna a pontuação verdadeira. Eventos podem estar incompletos, a fórmula pode estar errada, a chave pode ter sido comprometida e a pessoa pode decidir mal. O que a assinatura oferece, segundo as premissas do rascunho, é integridade e procedência. Ela torna uma troca ou um novo pareamento detectável; não resolve a qualidade do mundo representado.

A autoridade visual deve esperar a verificação

A ordem correta começa fora. A aplicação verifica a solicitação completa, sua chave e kernel_signature. Só depois extrai o resumo, recalcula o hash se precisar de prova de auditoria e renderiza notas ou explicações. Uma interface que exibe primeiro o cartão verde e verifica depois converte tempo de processamento em confiança provisória.

Intermediários também não podem confundir transporte com mandato. HEM-07 afirma que um intermediário capaz de verificar não deve encaminhar uma solicitação cuja assinatura falhe. Ele pode transportar, transformar a apresentação ou produzir uma visualização. Se alterar a serialização, deve conservar a preimagem assinada ou um registro reproduzível, em vez de sugerir que o objeto remontado é o objeto original.

A pessoa continua soberana sobre a decisão prevista. PT diz que o resumo é informativo: um principal pode aprovar com nota baixa ou encerrar com nota alta. Incluir os dados no envelope não automatiza a escolha. Apenas torna atribuível a evidência que apareceu quando o poder humano foi exercido.

Um recibo para o vínculo

A memória operacional mínima deveria ser um recibo conjunto, não dois arquivos independentes. Ele identificaria hem_id, versão da solicitação, bytes assinados ou preimagem canônica, kernel_signature, signatário, chave, horário e resultado da verificação. Também registraria o caminho do resumo dentro do objeto, o momento do cálculo, o hash recalculado após extração e qualquer transformação feita na entrega. Essa estrutura é minha recomendação editorial, não texto normativo de PT ou HEM.

Os melhores testes são de desacoplamento. Um resumo correto ao lado de outro hem_id deve falhar. Uma pontuação alterada com o hash antigo deve falhar. Um resumo e seu novo hash, ambos coerentes, mas sem uma assinatura externa válida, devem falhar. Se a interface trocar a explicação em linguagem natural depois da verificação, precisa marcar o texto como local ou provar equivalência de apresentação. Uma chave desconhecida deve produzir estado pendente, não uma nota verde herdada.

A Running-Code Primacy de Heng Lu oferece o critério editorial: publicar uma especificação não demonstra seu comportamento; operadores precisam validar a regra localmente. A Minimum Initial Specification favorece um núcleo fino. Aqui, basta uma solicitação, uma assinatura envolvente e um caminho de verificação preservado. As notas não são evidência de implantação do PT.

A correção existe; o resultado operacional ainda não

Os registros de PT e HEM não comprovam implementação independente, teste de interoperabilidade, produção, ataque, relay comprometido, incidente resolvido ou adoção pela IETF. Ambos são rascunhos individuais sujeitos a revisão e expiração.

A notícia defensável é específica: PT-03 nomeia o objeto assinado que deve carregar o resumo apresentado ao principal humano e devolve o hash à função de auditoria pós-extração. A próxima evidência relevante virá de duas implementações que rejeitem os mesmos pareamentos errados e guardem um recibo que terceiros consigam reproduzir.

Fontes

  1. Anúncio IETF de draft-sato-soos-pt-03
  2. Datatracker — Progressive Trust
  3. Arquivo IETF — PT-03
  4. Arquivo IETF — PT-02
  5. Comparação oficial PT-02/PT-03
  6. Arquivo IETF — HEM-07
  7. Datatracker — Human Escalation Mechanism
  8. RFC 8785 — JSON Canonicalization Scheme
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — especificação inicial mínima
  11. Heng Lu — realidade, não defesa de causa