Resumo

  • O rascunho ativo do grupo CBOR define serialização geral, preferred-plus e determinística. A última acrescenta ao preferred-plus a ordenação lexicográfica, byte a byte, das codificações determinísticas das chaves de mapa; isso estabiliza a saída sem transformar mapas em sequências com ordem de negócio.
  • Determinismo é necessário quando partes independentes remontam os bytes de uma assinatura, hash, endereço de conteúdo, chave de cache ou teste de igualdade. Em geral não é necessário quando os bytes protegidos viajam intactos, e nunca comprova completude, atualidade, autorização ou efeito operacional.

O primeiro alerta dizia apenas que a assinatura era inválida. Nos registros, os objetos decodificados pareciam idênticos. A diferença surgiu no hexadecimal: uma biblioteca usava uma forma legal mais longa para um argumento e preservava a ordem de inserção; a outra escolhia formas mínimas e classificava as chaves. Ambas produziam CBOR válido. A criptografia, porém, recebeu sequências distintas.

Esse é o espaço de coordenação tratado por draft-ietf-cbor-serialization-08. Datado de 29 de julho de 2026, o texto continua sendo um Internet-Draft ativo do grupo de trabalho CBOR, em Working Group Last Call, com estado IESG I-D Exists. Não é RFC final nem evidência de conformidade de um produto. Sua utilidade é dar nome a três contratos para que um protocolo declare quanta liberdade de representação existe em cada fronteira.

Em CBOR, modelo de dados e representação binária são camadas diferentes. O mesmo valor pode ter mais de uma codificação permitida. Isso atende streaming, dispositivos limitados e produtores diversos. A flexibilidade vira falha quando outro componente usa os bytes como identidade, entrada criptográfica ou endereço, mas ninguém definiu como escolhê-los.

Três contratos, três compromissos

A serialização geral é o padrão teórico quando um protocolo baseado em CBOR não diz o contrário. Para cada tipo suportado, o decodificador deve aceitar todas as codificações permitidas, inclusive comprimentos definidos e indefinidos. O rascunho observa que essa amplitude não é comum nas implementações. Portanto, “suporta CBOR” não descreve o que um binário em produção realmente aceita.

Preferred-plus reduz a liberdade do emissor. Argumentos usam a forma mais curta, números de ponto flutuante usam a menor representação que preserva exatamente o valor, comprimentos são definidos, NaN segue o tratamento indicado e inteiros e bignums são normalizados. É uma escolha prática para muitos protocolos sem impor ordenação de mapas.

A serialização determinística parte de preferred-plus e adiciona uma regra central: itens de mapa são classificados pela ordem lexicográfica byte a byte das codificações determinísticas de suas chaves. Com o modelo e as demais regras definidos, codificadores independentes podem convergir para os mesmos bytes.

Esses conjuntos não são uma escala moral. A serialização geral mantém recursos necessários em alguns projetos: construção incremental com comprimento indefinido, distinção semântica entre inteiro e bignum ou NaNs não triviais. O determinismo remove essas escolhas para obter repetibilidade. Deve ser adotado por causa de uma exigência, não como selo genérico de qualidade.

Produção e aceitação também são diferentes. A decodificação determinística não acrescenta obrigações além de preferred-plus. Um sistema pode emitir uma forma estreita e aceitar formas mais amplas. Rejeitar tudo que não seja determinístico é outra política, que requer texto explícito, testes de compatibilidade e uma justificativa de ponta a ponta.

A fronteira está no percurso dos bytes

Se o remetente assina uma carga CBOR e envia exatamente esses bytes com a assinatura, o destinatário verifica o que recebeu. Não precisa decodificar e recriar a serialização. O rascunho usa cargas COSE para ilustrar esse caso. Assinaturas e hashes precisam de uma cadeia comum, não de determinismo universal.

Quando cada lado constrói a cadeia, o cenário muda. A Sig_structure de COSE é montada pelo assinante e novamente pelo verificador. Larguras, representação de flutuantes ou ordem de chaves podem divergir apesar do mesmo modelo. O risco também aparece em endereços de conteúdo, chaves de cache, deduplicação, manifestos reproduzíveis e igualdade binária.

A exigência deve ser local. Tornar a Sig_structure determinística não torna automaticamente a carga interna, o envelope externo nem todos os objetos futuros determinísticos. Expandir uma regra pequena para toda a plataforma pode eliminar streaming ou quebrar dados antigos sem benefício.

Um desenho simples ajuda: quais bytes atravessam a conexão sem mudança? Quais objetos são decodificados e recodificados antes de uma operação sensível? Um proxy que reserializa uma carga assinada não é transparente na camada que importa, mesmo que preserve todos os valores visíveis.

Ordenar chaves não cria precedência

Mapas CBOR são desordenados no modelo genérico. A classificação determinística seleciona uma disposição binária repetível; não define prioridade, ordem de execução ou apresentação.

Ferramentas de depuração sempre mostram uma lista, o que favorece a confusão. Uma linguagem preserva inserção, outra biblioteca devolve a ordem recebida e uma tabela hash pode percorrer de modo diferente. Todas podem representar o mesmo mapa. Se a aplicação precisa de sequência, deve usar array, campo de prioridade ou regra explícita.

A ordenação também não resolve chaves duplicadas, tags permitidas, campos desconhecidos, evolução de esquema ou equivalência. Preferred-plus pode resultar em bytes determinísticos quando não há mapas, mas isso não decide se uma tag é autorizada ou se a ausência de um campo muda a decisão.

Igualdade de bytes pode ser mais rígida que igualdade semântica. Valores considerados equivalentes pelo negócio podem produzir hashes diferentes. Ao mesmo tempo, bytes idênticos podem carregar dados vencidos, maliciosos ou incompletos. Normalização textual, domínio numérico, valores padrão e interpretação de tags pertencem ao protocolo de ponta a ponta.

“CBOR canônico” também é ambíguo. O perfil separado em draft-mcnally-deterministic-cbor-17 restringe CBOR ainda mais. Suas regras não podem ser atribuídas silenciosamente ao rascunho do grupo. Auditoria precisa de nome e revisão do perfil.

A assinatura é um recibo de bytes

Quando a reconstrução determinística coincide e a assinatura é válida, há uma evidência forte: um algoritmo e uma chave específicos protegeram aquela sequência. Isso não comprova que a sequência contenha todos os fatos relevantes.

Não demonstra que o esquema era suficiente, que uma tag era admitida no contexto, que o horário estava vigente, que o assinante ainda tinha competência, que nenhum campo importante foi omitido ou que a política autorizava a ação. Tampouco observa se a operação ocorreu.

Modelo de informação, modelo CBOR, bytes serializados, verificação criptográfica, validação semântica, política, autorização, tentativa e efeito precisam de recibos separados. Um indicador verde em uma camada não herda a autoridade da próxima.

CDDL descreve formatos de dados CBOR. O controle de serialização discutido no rascunho pode associar uma exigência de codificação ao formato. Ainda assim, esquema não é código em execução, autorização ou recibo de efeito. Uma correspondência CDDL não identifica a versão do parser, política de duplicatas, âncora de confiança nem transação confirmada.

COSE e CWT mostram a divisão de responsabilidades. Um framework suporta muitos protocolos e não conhece todas as necessidades de reconstrução e streaming. Quando ele não impõe um conjunto, o rascunho recomenda preferred-plus e deixa o protocolo incorporador declarar o requisito real. O padrão de uma biblioteca não substitui esse contrato.

Medir o decodificador real

A distância entre o conjunto geral teórico e implementações práticas é uma dívida operacional. Um componente pode rejeitar strings de comprimento indefinido, outro pode aceitar larguras alternativas nunca testadas e um terceiro pode transformar bignums, embora todos anunciem CBOR.

A evidência deve registrar biblioteca, versão, build, opções, modo do codificador, conjunto aceito pelo decodificador, esquema, valor de entrada, bytes emitidos, variantes aceitas e resultado posterior. Vetores dourados precisam atravessar implementações independentes.

Testes negativos desenham o limite: uma codificação geral legal para um receptor que promete general; uma forma não mínima para um portão preferred-plus; ordens de inserção diferentes; fronteiras de inteiro e bignum; comprimentos definidos e indefinidos; larguras de flutuante e NaN. Além de “parseou”, registrar o valor obtido e o caminho de política.

Teste de codificador não prova amplitude do decodificador. Teste de aceitação não prova saída determinística. Ida e volta na mesma biblioteca mascara falhas porque repete os próprios pressupostos. A interoperabilidade começa quando caminhos independentes trocam artefatos exatos.

Valores especiais expõem escolhas escondidas

Preferred-plus escolhe a representação flutuante exata mais curta e o NaN quieto trivial especificado. Algumas áreas preservam bits de carga de NaN ou lhes atribuem significado. Se esses bits fazem parte do modelo, é necessário outro contrato de serialização.

O mesmo vale quando bignum e inteiro comum são conceitos distintos ou quando o produtor precisa começar a transmitir antes de conhecer o tamanho final. General ou um perfil especial pode ser a escolha correta. O risco está em deixar a exceção escondida numa opção do codificador, em vez de torná-la acordo de ponta a ponta.

A especificação inicial mínima coordena apenas a superfície necessária: determinismo onde bytes são reconstruídos, preferred-plus em trocas comuns compatíveis com suas restrições e um perfil geral ou especial onde a aplicação realmente precisa. Não se deve congelar todo o ecossistema para estabilizar uma entrada de assinatura.

Reduzir um canal oculto

Representações alternativas podem carregar informação que desaparece após a decodificação. Um componente comprometido pode variar larguras, segmentar itens indefinidos ou escolher outras formas legais. Preferred-plus e determinismo reduzem esse alfabeto e tornam divergências mais visíveis.

Não eliminam toda exfiltração. Um atacante pode escolher valores permitidos, timestamps, tags, padding em outra camada, tamanho ou ritmo do tráfego. A conclusão correta de um teste é que este build produziu os bytes esperados para um corpus congelado, não que não existem canais ocultos.

Em fronteiras sensíveis, pode-se guardar o digest dos bytes e o modelo normalizado, com controles de privacidade e retenção. Se um produtor supostamente determinístico muda o digest, investigar entrada, versão, opções e ambiente. A diferença é um sinal, não veredito automático de comprometimento.

Um recibo que sobrevive a atualizações

O registro útil liga protocolo e revisão, conjunto exigido em cada fronteira, perfil do modelo CBOR, tags e tipos de chave, política de duplicatas, bibliotecas e opções, esquema, entrada, bytes ou digest recuperável, entrada criptográfica, procedência da chave, verificação, semântica, política, autorização, tentativa e efeito.

Também marca onde bytes viajam e onde são refeitos. Essa cartografia costuma revelar o defeito: gateway recodificando carga assinada, cache calculando hash de objeto analisado ou serviços aplicando padrões diferentes.

As responsabilidades continuam distribuídas. O autor do protocolo define a fronteira; engenharia comprova emissão e aceitação; segurança responde por parser e criptografia; a aplicação define significado; a política concede autoridade; operações confirma efeito. Um identificador limitado une os recibos sem fundi-los.

A primazia do código em execução de Lu Heng pergunta qual versão e opção realmente rodaram. As camadas de realidade impedem que bytes determinísticos tomem emprestada a autoridade do esquema e que a assinatura tome emprestado o poder da decisão. CBOR determinístico resolve um problema exato: codificadores independentes podem chegar à mesma sequência. Nada além disso deve entrar nessa conclusão.

Fontes