Resumo

  • Os dirigentes do SCITT abriram em 25 de setembro uma consulta formal sobre adotar um rascunho individual de recibos COSE para Merkle Mountain Ranges; as respostas devem chegar até 9 de outubro.
  • A contagem da reunião IETF 126 indicou disposição para revisar o texto, não consenso de adoção.
  • A RFC 9942 oferece uma estrutura comum para recibos, mas alerta que provas de estruturas verificáveis diferentes não são automaticamente interoperáveis.

Um fornecedor pode dizer que aceita recibos COSE e ainda não saber verificar um recibo MMR. A diferença não é terminológica. O envelope transporta identificadores e provas; a validade do resultado depende do algoritmo de árvore e do procedimento que o software executa. O chamado publicado pelos copresidentes do SCITT em 25 de setembro põe em pauta justamente um perfil específico, draft-bryce-cose-receipts-mmr-profile-03, hoje apresentado como Internet-Draft individual.

O pedido é para que participantes digam se apoiam sua adoção como base para trabalhos futuros, por quê e se estão dispostos a revisar, contribuir ou implementar. A mensagem ressalva que a adoção, caso ocorra, não concluirá o documento nem o tornará pronto para publicação. O prazo de 9 de outubro vale para manifestações, não como data certa de aprovação. O Datatracker informa que a versão atual não tem endosso formal da IETF.

A reunião de julho não resolveu antecipadamente a questão. Nas atas do IETF 126, quatro pessoas se disseram dispostas a revisar, nenhuma se opôs à revisão e três não opinaram, entre 34 presentes. A pergunta se referia a trabalho de revisão. Converter essa sondagem em decisão de adoção atribuiria à reunião um resultado que suas próprias atas não registram.

O perfil proposto descreve árvores binárias organizadas em pós-ordem, chamadas Merkle Mountain Ranges. Seus picos compõem um acumulador. Há uma prova para mostrar a inclusão de um elemento em determinado estado e outra para relacionar esse estado a um posterior. O identificador da estrutura fica em cabeçalho COSE protegido; os dados da prova seguem formato próprio. O verificador precisa reconstruir a raiz da árvore a partir da prova antes de conferir a assinatura sobre a carga separada. Um programa que apenas lê o invólucro não demonstrou realizar essa sequência.

Isso importa porque a RFC 9942, já publicada, distingue o quadro comum das regras particulares de cada estrutura de dados verificável. Ela adverte que não se deve presumir interoperabilidade entre estruturas diferentes. O SCITT já trabalha em um perfil CCF; incorporar o perfil MMR à pauta seria ampliar o conjunto de documentos, não tornar os dois métodos idênticos. A proposta MMR também deixa claro que provar inclusão não julga se a entrada era legítima e não detecta algo nunca incluído. Esses limites não são a novidade central aqui: a notícia é a decisão pendente sobre um segundo formato e a responsabilidade por sua evolução.

Para usar qualquer recibo com segurança, a organização dependente deve pedir uma declaração verificável de quais identificadores de estrutura, tipos de prova e versões seu software suporta. Exemplos conhecidos de inclusão e consistência ajudam a testar a declaração. Essa é uma orientação editorial de aquisição, não uma obrigação aprovada pelo grupo. Uma futura adoção formal resolveria quem discute o texto, mas não substituiria ensaio de implementação nem a decisão local de confiar no resultado.

Fontes