Resumo

  • A revisão 03 classifica cada referência tipada como Malformed, Unresolved, Failed ou Verified. Sintaxe aceita e cobertura por assinatura não comprovam a ligação com o artefato citado.
  • Verified depende de um único contexto de digest autorizado, da obtenção do artefato, da execução da construção prescrita e da igualdade na representação definida.
  • Validade da assinatura, autenticação do emissor, receipt SCITT, avaliação do objeto e autorização para agir continuam sendo resultados independentes.

O borrador e a alegação que ele não faz

Steven Mih e Anton Sokolov publicaram em 5 de setembro de 2026 a revisão 03 de Canonical Payload Binding: A Signed Statement Construction Profile. No Datatracker, o texto é um Internet-Draft individual ativo. Os autores indicam SCITT como grupo pretendido, mas não há stream do IETF, área responsável, AD, adoção ou consenso registrado. O documento pode mudar, ser substituído ou expirar.

Esse enquadramento não reduz a relevância técnica. Ele evita anunciar uma norma onde existe uma proposta. A seção de mudanças desde -02 mostra uma reestruturação substantiva: o mecanismo neutro de CPB se separa dos formatos específicos de payload; a referência tipada passa a ser um modelo de informação de quatro membros; perfis podem definir seus próprios carriers; e cpb-refs permanece como carrier opcional no cabeçalho protegido COSE.

O texto também remove um registro universal de tipos de artefato de dentro do CPB. O perfil consumidor precisa nomear, por referência normativa estável, quais tipos e contextos de digest admite. A revisão distingue o modo Full-Payload da RFC 9943 do Hash Envelope da RFC 9995, proíbe o uso conjunto de dois carriers de referência e define quatro resultados que uma interface não deveria reduzir a “passou” ou “falhou”.

A distância entre Malformed e Verified

Malformed é um problema de admissão. Pode faltar um membro obrigatório, aparecer o tipo CBOR errado, uma quantidade ou tamanho exceder o limite, uma chave ser duplicada, o mesmo quadrupleto ocorrer mais de uma vez ou uma chave desconhecida surgir no mapa fechado. Para cpb-refs, apenas as chaves 1 a 4 são admitidas. Uma entrada malformada contamina a validade estrutural do conjunto; o verificador não declara outra entrada do mesmo cabeçalho Verified por sucesso parcial. O resultado da assinatura, porém, ainda pode ser registrado separadamente.

Unresolved começa depois da sintaxe. Talvez o verificador não consiga escolher exatamente um contexto permitido pelo perfil. Talvez escolha, mas o artefato não possa ser obtido. Talvez contexto e artefato estejam disponíveis, porém a construção não esteja implementada. Não existe evidência de divergência nesses casos, mas também não existe uma ligação comprovada.

Failed pressupõe que o processo avançou. Um contexto único foi identificado, mas o algoritmo ou a representação não combina com ele; um identificador está definitivamente sem atribuição ou é proibido; ou o digest calculado sobre o artefato obtido difere do valor declarado. Misturar Failed e Unresolved torna invisível a diferença entre uma perda de retenção, uma incapacidade do verificador, uma ambiguidade de governança e uma incompatibilidade material.

Verified fecha todas as etapas relevantes: contexto autorizado, artefato adquirido, seleção e exclusão de campos, canonicalização, separação de domínio quando exigida, codificação do preimage, digest, representação de saída e comparação igual. Mesmo assim, o resultado afirma apenas que aquele artefato corresponde àquela referência sob aquele contexto.

O algoritmo é apenas um dos parâmetros

“SHA-256” não identifica sozinho um digest context. O contexto reúne o conjunto de campos incluídos e excluídos, o algoritmo de canonicalização, eventual separação de domínio, a codificação do preimage e a representação do resultado. Duas sequências hexadecimais visualmente iguais só formam uma junção probatória quando foram produzidas sob construções compatíveis.

O mecanismo seleciona o contexto por type e, quando necessário, purpose. Se houver um único contexto permitido para o tipo, purpose pode ser omitido; se vier presente, precisa corresponder. Se vários contextos forem permitidos, cada um tem purpose distinto e não vazio, e a referência precisa escolher. Nenhuma correspondência ou mais de uma correspondência leva a Unresolved.

Não é permitido resolver a ambiguidade pelo primeiro item de uma lista, pelo comprimento do digest, pela aparência do payload, por uma convenção do fornecedor ou por um snapshot de registro não citado pelo perfil. A biblioteca pode conhecer a JCS da RFC 8785 e ainda desconhecer que campos a organização decidiu excluir e qual versão normativa governa a mensagem.

O identificador derivado que possa vir dentro do payload também é apenas indicativo. O verificador precisa recomputá-lo após aplicar o conjunto de exclusão normativo e as transformações obrigatórias. Persistir a cópia do produtor em um campo chamado “verificado” é guardar a mesma afirmação duas vezes, não produzir corroboração.

Carrier único significa autoridade única de entrada

Um perfil escolhe cpb-refs no envelope protegido ou um carrier definido dentro do payload. Os dois não podem coexistir, mesmo quando apontam para artefatos diferentes. Ao encontrar ambos, um verificador ciente do perfil declara não conformidade; não deve uni-los ou escolher aquele que seu parser leu primeiro.

Sem essa fronteira, uma referência do payload poderia aparentar corrigir uma referência protegida, duplicatas poderiam virar votos e duas implementações poderiam montar grafos diferentes. O carrier único limita a superfície de admissão e torna o receipt auditável.

Na forma de envelope, cpb-refs só aparece no cabeçalho protegido. O array leva de uma a 64 referências. Cada mapa fechado associa chaves inteiras a type, purpose opcional, digest_alg e digest, sob limites explícitos. Duplicatas precisam ser detectadas antes de converter CBOR para um modelo que as descarte. First-wins, last-wins, sucesso parcial e ponderação por repetição não são alternativas compatíveis.

O CDDL restringe o modelo de dados, não fixa uma única codificação CBOR. Vetores podem congelar bytes para produzir testes reproduzíveis. Um verificador conforme não rejeita outra serialização CBOR válida só porque ela não coincide com o fixture. O ponto aqui complementa a análise anterior sobre as muitas codificações CBOR: nesta revisão, a questão central é quando uma referência estruturalmente admitida se torna uma ligação externa demonstrada.

Representação não é detalhe de interface

Trinta e dois bytes crus, 64 caracteres hexadecimais em minúsculas e uma forma prefixada são representações diferentes. Converter silenciosamente entre elas altera o protocolo. A conversão só é defensável quando a especificação ou o perfil define a operação e a representação em que a comparação acontece.

A aquisição do artefato também produz um evento próprio. Com um contexto único e um objeto inacessível, o estado é Unresolved. Falha de rede, acesso negado, lacuna de retenção ou método de recuperação desconhecido não demonstram digest incorreto. Uma nova tentativa pode resolver a referência mais tarde sem mudar o Signed Statement; a trilha precisa preservar as duas observações.

Quando a implementação reconhece o contexto mas não sabe executá-lo, pode encaminhar a um verificador capaz, adiar, instalar uma capacidade aprovada ou recusar conforme a política. O que não pode é importar apenas o verde de outro serviço, omitindo entradas, versão, contexto e recibo.

Cinco controles que uma tela costuma condensar

Como cpb-refs está no cabeçalho protegido, uma assinatura COSE válida protege sua integridade. Isso não prova que a chave tinha permissão para falar pelo emissor alegado. Por esse motivo, a revisão distingue Signature-Valid de Issuer-Authenticated; o último depende da política local de chaves.

Uma assinatura válida pode acompanhar uma referência Unresolved ou Failed. Da mesma forma, um digest igual não conserta uma assinatura inválida e não autentica o autor. APIs, logs e consoles deveriam transportar o resultado da assinatura e o resultado de cada referência em campos distintos.

O receipt SCITT ocupa outra camada. A RFC 9943 permite que um Transparency Service registre um statement e produza um receipt regido por uma verifiable data structure. Confiar nele exige validar a chave do serviço e interpretar o identificador VDS em seu cabeçalho protegido. O registro não busca o artefato referenciado e não promove Unresolved a Verified.

E a verificação do CPB ainda não prova a autoridade do emissor, a validade, o escopo, a atualidade ou a revogação do artefato, sua aceitação semântica, a conformidade com política ou a autorização da ação. O perfil do artefato define o significado; a organização que assume o efeito define a decisão.

Cabeçalho protegido continua público

“Protegido” em COSE significa coberto pela integridade da assinatura, não cifrado. cpb-refs expõe tipo, purpose, algoritmo, digest e topologia do grafo de citações. Valores estáveis tornam statements correlacionáveis. Artefatos de baixa entropia podem admitir ataques de dicionário.

Se isso for sensível, o projeto recomenda omitir cpb-refs ou usar um carrier confidencial definido pelo perfil dentro do payload. A decisão precisa ocorrer antes da distribuição. Um controle de acesso acrescentado depois não recolhe um grafo que já circulou.

Pedido de registro não é registro concedido

A revisão 03 pede a criação de um Canonicalization Algorithm Registry e o registro do parâmetro COSE cpb-refs. São pedidos do Internet-Draft, não comprovação de ação da IANA. Experimentos devem fixar revisão, valores provisórios e estratégia de migração.

A noção de Heng Lu sobre a especificação inicial mínima oferece uma boa medida. A camada compartilhada precisa transportar somente um fato reproduzível: um contexto declarado foi aplicado a um artefato obtido e gerou determinado resultado de comparação. Significado, atualidade e ação podem ficar nos perfis futuros e nas autoridades locais. Running code é primário quando conserva as entradas e decisões necessárias para repetir o resultado.

Limites e incertezas

Esta leitura não afirma adoção pelo IETF, consenso do SCITT, ação da IANA, suporte comercial ou implantação. Exemplos de instância no apêndice não demonstram interoperabilidade geral. Nenhum serviço, produto, biblioteca, registro, incidente, exploit, benchmark ou taxa de uso foi testado.

Canonicalização também não torna o payload verdadeiro ou seguro. Os quatro estados são uma prova delimitada. Assinatura, identidade, receipt, ligação, avaliação, decisão e efeito observado permanecem separados porque têm proprietários e consequências diferentes.

Fontes