Resumo

  • Em 24 de agosto, o IESG abriu a Última Chamada de draft-ietf-rats-endorsements-09, com prazo até 7 de setembro para comentários sobre a publicação como RFC Informational. Não há decisão final.
  • Anton Sokolov distinguiu, em comentário público que deve permanecer atribuído, a invariância do conteúdo de uma claim da continuidade da situação do Endorser e perguntou se essa situação deve ser avaliada no tempo da Evidence ou no tempo da avaliação.
  • Os autores responderam que o CoRIM já separa janelas de validade de conteúdo e assinatura. O comentarista considerou a questão resolvida, e os editores decidiram guardar a distinção no texto.
  • A pull request 76 foi incorporada em 28 de agosto. A cópia latest agora descreve rim-validity, signature-validity, revogação e trust anchors, mas os parágrafos não estão na revisão numerada 09.
  • Um comprovante de disposição deve ligar comentário, resposta, diff revisado, merge, próxima revisão, escolha de política, resultado da avaliação e ação final do IESG. Assim, melhoria editorial não se disfarça de aprovação do IETF.

A etapa formal ainda examina outro conjunto de bytes

O aviso do IESG de 24 de agosto abriu a revisão comunitária de RATS Endorsements. O grupo Remote ATtestation ProcedureS pediu publicação como RFC Informational. Comentários substantivos são aceitos até 7 de setembro.

No corte desta reportagem, o Datatracker ainda registrava revision 09, “In Last Call”, sem data de telechat e sem decisão do IESG. O avanço do repositório não apaga esse estado. Ele cria uma nova camada que precisa ser conectada à anterior.

O próprio RATS distribui responsabilidades. O Attester produz Evidence sobre o estado de um sistema. O Verifier avalia essa Evidence usando Reference Values, Endorsements e uma Appraisal Policy for Evidence. O Verifier Owner controla a política de avaliação; o Relying Party Owner decide como usar o Attestation Result. O Endorser acrescenta afirmações, mas a assinatura não lhe transfere a decisão de confiança.

A seção 5 da revisão 09 deixa a cargo das especificações de protocolo a forma de fornecer a atualidade do Endorsement, citando a duração de um certificado. Em seguida, diz que claims estáticas, por representarem propriedades invariantes do Environment, não exigem passos adicionais de atualidade para o conteúdo.

Uma frase não contradiz a outra. Ainda assim, a segunda podia soar como se encerrasse toda a questão temporal.

Um fato estático não mantém o emissor parado no tempo

Anton Sokolov apresentou a distinção em seu comentário de Última Chamada. Uma propriedade física de um chip pode permanecer igual enquanto o certificado do fabricante expira, a chave é revogada ou o Verifier retira o trust anchor correspondente. O conteúdo não mudar e o autor continuar aceito são propriedades independentes.

A pergunta T1/T2 mostrou a consequência. Se a Evidence foi produzida em T1 e avaliada em T2, em qual momento a situação do Endorser deve valer? O comentário apoiava a publicação e não relatava ataque, exploração ou dispositivo comprometido. Pedia que a escolha fosse nomeada.

Essa percepção é do comentarista e não deve ser reapresentada como descoberta de Daniel Kade. A contribuição própria do artigo é propor um rastro institucional que mostre como a observação foi tratada, qual texto mudou e em que momento cada mudança adquiriu autoridade processual.

Thomas Fossati primeiro confirmou a formulação: verificação da situação do Endorser é logicamente separada da atualidade do conteúdo, e T1 ou T2 é uma decisão do protocolo ou da política de avaliação. Sokolov concordou e sugeriu que o Attestation Result tornasse o ponto de referência visível.

Depois, Fossati localizou a resposta em tecnologia existente. Um processador CoRIM mantém janelas independentes para conteúdo e assinatura. Nesse exemplo, validade da assinatura, revogação e trust anchor são examinados no momento da avaliação. Identificar o Verifier no resultado ajuda a explicar por que T2 foi aplicado. Sokolov deu a preocupação por encerrada ao reconhecer que não era preciso inventar mecanismo novo.

Mesmo assim, os editores não deixaram a solução apenas na caixa de correio.

A mudança incorporada separa o veredicto da situação do autor

A pull request 76 abriu em 25 de agosto, recebeu ajustes e as aprovações de Dave Thaler e Henk Birkholz. Foi incorporada em 28 de agosto pelo commit bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

Na cópia editorial atual, a mesma medição H de firmware pode receber um Endorsement de confiança antes de uma vulnerabilidade conhecida e outro de desconfiança depois. Os dois podem ser assinados por um Endorser que continua em situação válida. A janela rim-validity limita o conteúdo para definir qual mensagem temporalmente escopada se aplica.

Separadamente, a chave, o certificado ou o trust anchor do Endorser podem mudar de estado. signature-validity limita a assinatura; o processador CoRIM citado verifica essa janela, revogação e trust anchor no tempo da avaliação. O texto mantém a escolha do ponto de referência com o protocolo ou a Appraisal Policy e usa T2 como exemplo, não como ordem universal.

Há, portanto, três movimentos: o valor do Environment, a avaliação do Endorser sobre esse valor e a situação do Endorser. Um único resultado “válido” pode ocultar qual deles mudou.

O merge não herda a autoridade de publicação

O diff, os revisores e o merge são verificáveis. A página gerada se chama draft-ietf-rats-endorsements-latest; não é revision 10 nem RFC. A revisão 09 no Datatracker continua sem os novos parágrafos.

Essa diferença faz parte do trabalho com Internet-Drafts. Editores precisam incorporar comentários antes de apresentar uma nova revisão numerada. O desvio de governança surge quando a descrição perde a etiqueta: “os editores incorporaram”, “o grupo submeteu” e “o IESG aprovou” não são três maneiras de dizer a mesma coisa. Hoje, as duas primeiras ações são comprovadas e apontam para textos diferentes. A terceira não ocorreu.

O teste de lavagem de mandato de Heng Lu esclarece a fronteira. O GitHub prova quais bytes foram aceitos pelos editores; não cria autoridade do IESG. Em sentido contrário, o estatuto oficial da revisão 09 não transforma o trabalho posterior em inexistente. O registro correto preserva as camadas e a passagem entre elas.

Um comprovante para o caminho do comentário

Mail Archive, GitHub, a cópia editorial e o Datatracker já publicam as peças. Um comprovante compacto pode juntá-las sem instituir um novo veto.

Ele registra URL, data, autor, revisão e seção do comentário, além de uma disposição explícita: aceito, parcialmente aceito, respondido por mecanismo existente, adiado ou rejeitado. Depois aponta para a resposta responsável, issue ou pull request, commits de head e merge, revisores, horário e um resumo limitado do que mudou e do que permaneceu.

O trecho formal identifica a primeira revisão numerada que contém o texto, o estado posterior no IESG e o RFC, se houver. Para os dois relógios, guarda a janela de conteúdo, a janela de standing, T1, T2, o dono da política que escolheu e a identidade do Verifier ou da versão de política necessária para interpretar a saída.

O comprovante também declara suas não conclusões. Um comentário bem tratado não representa consenso geral. Um merge não aprova publicação. Uma assinatura correta autentica bytes sob um caminho de confiança, mas não prova sozinha a verdade da claim, a competência institucional do Endorser ou a confiabilidade do dispositivo.

Não é preciso revelar deliberação privada. Links estáveis, hashes, papéis, tempos e estados públicos bastam. O comprovante não substitui a lista, os editores, o Working Group ou o IESG; impede que uma camada use o nome da seguinte.

Fontes