Resumo

  • Na revisão 03, o sucessor assinava o hash de um contexto anterior que podia ser criado antes de qualquer assinatura; o coordenador conseguia coletar as assinaturas de trás para frente.
  • A revisão 04 resume o signoff anterior completo, assinatura real incluída, e rejeita cadeias antigas, mistas ou sem o perfil exato no modo forte.
  • O novo elo prova dependência entre artefatos completos. Não prova relógio confiável, leitura, compreensão, autorização final, execução ou efeito.

Uma fila de assinaturas válidas pode mentir sobre a ordem. Foi esse o defeito reconhecido em draft-schrock-ep-quorum-04, apresentado em 6 de setembro como submissão individual de caráter informativo.

A revisão 03 colocava prev_context_hash no contexto assinado por cada aprovador posterior. Como o valor resumia o contexto do predecessor, o texto dizia que a assinatura seguinte provava ter ocorrido depois da aprovação anterior.

Mas o contexto podia existir antes da prova. O orquestrador preparava a cadeia inteira, pedia primeiro a assinatura final, seguia na ordem inversa e depois apresentava tudo na sequência esperada. Nenhuma assinatura precisava ser falsa. O erro estava no significado atribuído ao encadeamento.

A dependência passa a incluir a assinatura

O perfil EP-QUORUM-SIGNOFF-CHAIN-v1 usa o objeto JSON completo do signoff anterior, inclusive a assinatura efetivamente carregada. Acrescenta um separador de domínio e um octeto zero à representação UTF-8 canonicalizada por JCS, calcula SHA-256 e inclui o resultado como prev_signoff_hash no contexto assinado do sucessor.

O primeiro membro deve omitir o campo. Predecessor nulo, perfil ausente ou desconhecido, prev_context_hash legado, mistura de elos, digest incorreto ou substituição da prova anterior fazem o modo forte falhar. Outra assinatura válida sobre o mesmo contexto também altera o elo e exige uma nova assinatura do sucessor.

Isso estabelece uma propriedade específica: sob as hipóteses criptográficas declaradas, a prova seguinte depende de uma prova anterior já concluída. Não estabelece hora confiável. issued_at continua sendo metadado afirmado. Não mostra se a pessoa viu a decisão anterior, recebeu a mesma tela, compreendeu a ação, consentiu livremente ou apenas carimbou a solicitação.

O pacote não nomeia a própria autoridade

O gate examina formato da política, assinaturas, ação exata, papéis, identificadores humanos distintos, chaves distintas, limiar, ordem, cadeia forte e janela. Uma pessoa real e cadastrada, mas fora do papel autorizado, não conta. Uma chave registrada sob dois nomes não vira duas pessoas. Uma trilha parcial não produz autoridade parcial.

A política esperada e o Approver Directory, porém, devem vir de fontes autenticadas fora do quorum apresentado. Deixar o pacote escolher esses dados seria permitir que a evidência definisse o próprio tribunal. O rascunho-base também separa identidade: a criptografia prova que uma chave cadastrada assinou; a ligação com uma pessoa natural depende do cadastro e da prova de identidade.

A admissão incremental só antecipa recusas. O executor recalcula o gate inteiro porque não confia no orquestrador. Mesmo satisfeito, o quorum é evidência de aprovação, não a decisão organizacional completa. Ainda faltam autorização local, execução, verificação do efeito e consumo atômico que impeça reutilização.

Consistência comum não é validação independente

Os verificadores JavaScript, Python e Go usam o mesmo repositório e o mesmo corpus. A concordância em casos como cadeias antigas assinadas ao contrário e troca da assinatura predecessora é um recibo útil de consistência. Não é implementação independente, prova formal, teste de interoperabilidade ou operação em produção.

O documento não pede ação IANA e sua presença no Datatracker não significa consenso do IETF. O mérito da revisão é menor e mais sólido: definir uma dependência que os bytes realmente sustentam, sem transformar esse resultado em soberania sobre procedimento humano ou realidade operacional.

Fontes

  1. Registro do IETF Datatracker
  2. EP-QUORUM, revisão 04
  3. EP-QUORUM, revisão 03
  4. EP Authorization Receipts, revisão 12
  5. RFC 8785: JSON Canonicalization Scheme
  6. Web Authentication, nível 2
  7. RFC 2119: palavras normativas
  8. RFC 8174: maiúsculas e minúsculas normativas
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy