Resumo

  • O grupo COSE apresentou em 24 de setembro de 2026 a revisão 21 do rascunho C509. A revisão 20 havia sido aprovada pelo IESG em julho; o documento ainda não foi publicado como RFC.
  • O texto novo especifica a sequência CBOR sujeita à assinatura, mantém o número de série como cadeia de bytes e só permite abreviar o emissor quando ele é idêntico ao titular byte por byte.
  • O tipo 3 conserva a assinatura de um X.509 em DER recodificado de forma reversível; o tipo 2 assina CBOR diretamente. Ambos ainda exigem validação do caminho de certificação.

O ganho de tamanho que aparece em uma tabela de laboratório é fácil de repetir em uma apresentação. Mais difícil é demonstrar que o equipamento que recebe o certificado compacto verifica o mesmo objeto que a autoridade emissora assinou. Entre uma codificação e outra, uma diferença pequena de representação pode mudar o dado entregue à verificação. A revisão 21 do C509 interessa por explicitar esse ponto de passagem, não por anunciar uma proteção inédita.

Há duas operações que recebem o mesmo nome geral de C509. No tipo 3, um certificado X.509 já assinado em DER é convertido para CBOR de maneira reversível; a assinatura é preservada e a forma original pode ser reconstruída para conferência. No tipo 2, a assinatura incide sobre a representação CBOR. Isso permite evitar processamento ASN.1 em ecossistemas que aceitem a forma nativa, mas não obriga um verificador limitado a DER a reconhecê-la. Ter semântica X.509 não é o mesmo que estar integrado a todos os verificadores existentes.

O delta editorial da versão de setembro inclui uma descrição mais rigorosa da parte assinada: os elementos do array C509Certificate formam uma sequência CBOR, e o grupo TBSCertificate sem o valor final da assinatura é a subsequência relevante. O número de série precisa ser escrito como bytes mesmo quando seu valor caberia em um inteiro CBOR comum. Na volta para o DER, o tipo 3 recupera o zero inicial se o bit mais alto do primeiro byte o exigir. O emissor só vira null quando sua representação coincide exatamente, em octetos, com a do titular. Nome visualmente semelhante não atende à condição.

O histórico impede uma leitura apressada de status. O IESG aprovou a revisão 20 em 20 de julho, que seguiu para a fila do editor de RFCs. A revisão 21, entregue em 24 de setembro, é uma nova versão dentro desse trabalho; não é um novo voto de aprovação nem um RFC concluído. No momento desta verificação, o Datatracker ainda registra resposta dos autores exigida pelo editor e ação IANA aguardando os autores. Nada disso informa quantos dispositivos usam C509 nem demonstra erro em produtos anteriores.

Também não se deve promover o conversor a autoridade de confiança. O próprio rascunho exige validação do caminho conforme o RFC 5280 antes de confiar em C509. Cabeçalhos COSE que carregam certificados são entrada não confiável até a aplicação de um mecanismo de verificação, e um código registrado pela IANA não equivale a recomendar o algoritmo. Uma avaliação local faria bem em guardar o tipo, a versão do conversor, o vetor exato de bytes assinados, a reconstrução e os resultados por classe de verificador. Essa proposta de registro é nossa análise, não uma obrigação criada pelo grupo COSE.

Fontes