Resumo

  • A revisão 04 do perfil de recibos CCF leva a folha candidata e uma sequência de hashes irmãos marcados como esquerda ou direita, mas não leva o tamanho da árvore nem um índice explícito.
  • O verificador ainda consegue recalcular a raiz e conferir a assinatura COSE. A ambiguidade aparece somente quando outro sistema usa esse sucesso como evidência de ordem ou posição.

Considere o caminho de um único passo 1. Numa árvore com duas folhas, ele pertence ao índice 1. Com três folhas, pertence ao índice 2. Com cinco, ao 4; com nove, ao 8. O caminho é idêntico. O que muda é a parte da árvore que o recibo não descreve.

O exemplo ganhou relevância no Last Call do IETF para a revisão 04 de CCF Profile for COSE Receipts. O Datatracker registra um Internet-Draft do fluxo IETF, destinado a Proposed Standard, enviado ao IESG e ainda “In Last Call”. A consulta foi aberta em 24 de agosto e termina em 7 de setembro de 2026. Nada disso transforma o texto em RFC nem significa aprovação ou rejeição.

O cálculo certo pode responder à pergunta errada

A construção segue a regra usada em Certificate Transparency: para mais de uma folha, o corte ocorre na maior potência de dois menor que o total. Potências de dois geram árvores equilibradas. Os demais tamanhos deixam um ramo direito menor, e é aí que a leitura ingênua do caminho perde o quadro completo.

Na seção 3, a prova contém a folha e um vetor de hashes irmãos. Um booleano informa o lado de cada irmão. O texto diz que esses bits podem ser tratados como a decomposição binária do índice, da folha em direção à raiz. Isso coincide com o número ordinal nas árvores equilibradas, mas não em todas as árvores autorizadas pela própria regra de divisão.

Em 6 de setembro, Henri Sirkkavaara corrigiu sua análise inicial. Entre 2 e 11 folhas, todas as árvores cujo tamanho não era potência de dois apresentaram pelo menos uma folha com índice decodificado incorretamente. Em 2, 4 e 8, a leitura foi exata.

Emek Can Dogru fez uma reprodução independente e publicou um programa de onze linhas. Ao estender a busca até 1.024 folhas, só as dez potências de dois acertaram todas as posições. Os outros 1.013 tamanhos tiveram pelo menos uma divergência. O código publicado mostra que o resultado nasce da topologia, não de uma colisão ou fraude.

Ainda assim, a seção 3.2 continua operacional. O verificador parte do hash da folha candidata, combina os irmãos nos lados indicados e chega a uma raiz. Se a assinatura COSE cobre aquela raiz, a inclusão da candidata foi demonstrada. O algoritmo não precisa atribuir um número global à folha para verificar essa relação.

Há, portanto, duas perguntas. “Esta folha está sob a raiz assinada?” pode receber uma resposta positiva. “Esta folha ocupou a posição x?” exige uma coordenada que o caminho isolado não fornece em todas as formas de árvore. A falha de governança surge quando a tela ou a política apaga essa diferença.

Tamanho e índice definem o referencial

O contraste com RFC 9162 é instrutivo. A verificação de inclusão em Certificate Transparency versão 2 recebe explicitamente o tamanho da árvore e o índice da folha. RFC 9942, perfil de recibo COSE para essa árvore, codifica os dois valores e afirma que o índice é relativo ao tamanho.

Esses campos não são redundância. São o referencial em que “posição” passa a ter um significado comum. Sem tamanho, o índice fica incompleto. Sem ambos, a mesma sequência de direções pode representar vários lugares.

Uma implantação de CCF pode conhecer mais. A documentação da Microsoft descreve a obtenção do recibo a partir de um identificador de transação, e commit_evidence pode revelar um TxID inteiro. O perfil SCITT inclui ainda internal-evidence, mas permite que o verificador ignore essa string e não a transforma em gramática interoperável de posição. Contexto local resolve uma consulta local; não torna o recibo autodescritivo para terceiros.

Os participantes foram cuidadosos. Chamaram a questão de não bloqueante e mantiveram apoio à publicação. Não alegaram assinatura forjada, hash quebrado, raiz incorreta, falha de implementação ou incidente em produção. No seguimento sobre a solução, Sirkkavaara concluiu que o comprimento do caminho também requer o tamanho e preferiu um índice explícito.

A interpretação é o verdadeiro ponto de controle

Recibos alimentam políticas de release, trilhas de auditoria, painéis de transparência e automação. Se a consequência depende só da inclusão, a prova atual pode bastar. Se depende de precedência, ordem ou número de sequência, a organização precisa guardar e verificar os dados que sustentam essa afirmação adicional.

A Especificação Inicial Mínima de Heng Lu favorece um núcleo comum estreito: padronizar a afirmação necessária, deixar garantias mais fortes para adoção explícita. As camadas de realidade separam o fato matemático da narrativa institucional sobre ordem. A Primazia do Código em Execução pede os valores realmente usados pelo verificador, não o significado atribuído depois por um selo verde.

O perfil não perde utilidade ao reconhecer o limite. Inclusão assinada deve produzir um recibo de inclusão. Posição com efeito decisório deve vir acompanhada do tamanho da árvore ou de um índice explicitamente vinculado.

Fontes

  1. Registro do documento no IETF Datatracker
  2. Eventos no Datatracker
  3. CCF Profile for COSE Receipts, revisão 04
  4. Anúncio do Last Call
  5. Correção de Henri Sirkkavaara
  6. Reprodução de Emek Can Dogru
  7. Seguimento sobre a solução
  8. Código da reprodução
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. Documentação de verificação CCF
  13. Heng Lu: Especificação Inicial Mínima
  14. Heng Lu: camadas de realidade
  15. Heng Lu: Primazia do Código em Execução