Resumo

  • O CMS declara algoritmos no conjunto de SignedData, no SignerInfo e, opcionalmente, dentro de atributos assinados. O digest do assinante deve ser o prehash fixado pelo OID composto; o OID de assinatura deve ter parâmetros ausentes.
  • O sucesso das duas componentes não encerra a validação. O destinatário precisa reconstruir os bytes DER exatos, recalcular o digest do conteúdo, comparar a proteção de algoritmo e executar política de certificado e autorização separadamente.

O verificador mostrou duas marcas verdes. A componente ML-DSA era válida. A componente tradicional também. Só depois apareceu a contradição: o envelope CMS nomeava um digest diferente daquele exigido pelo algoritmo composto.

A criptografia havia funcionado sobre uma interpretação. O objeto declarava mais de uma.

A revisão 05 de Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in Cryptographic Message Syntax (CMS) estabelece a fronteira. É um Internet-Draft ativo do grupo LAMPS, no fluxo IETF, destinado a Proposed Standard. A revisão data de 22 de maio de 2026 e expira em 23 de novembro. Datatracker registrou uma mudança de processo em 1º de outubro e agora mostra o documento na fila do RFC Editor, aguardando um segundo editor. Ainda não é RFC e não comprova suporte de biblioteca, emissão de certificados, configuração, implantação ou migração concluída.

O texto acompanha a especificação da primitiva Composite ML-DSA, que combina ML-DSA com RSA, ECDSA, Ed25519 ou Ed448 e só aceita o conjunto se todas as assinaturas componentes passarem. O perfil CMS define os bytes e as declarações externas que alimentam essa operação.

Um OID não elimina as outras autoridades

A revisão reproduz 18 OIDs compostos. O mesmo AlgorithmIdentifier identifica a chave pública e a assinatura; seus parâmetros devem estar ausentes. Isso oferece uma interface única e evita contêineres inventados por cada aplicação.

O CMS ainda possui outros campos. SignedData.digestAlgorithms lista digests. Cada SignerInfo traz digestAlgorithm e signatureAlgorithm. Atributos assinados podem conter CMSAlgorithmProtection. O certificado identifica o algoritmo da chave.

Se essas posições discordarem, a primitiva não deve escolher silenciosamente qual delas representa a intenção. O recibo precisa guardar OID composto, OID da chave, identificadores do SignerInfo, presença de parâmetros, valores protegidos e os dois verdicts. “Assinatura PQ válida” comprime demais a evidência.

O nome composto fixa o prehash

Neste perfil, Composite ML-DSA opera apenas em modo prehash. Cada nome composto fixa SHA-256, SHA-512 ou SHAKE256 para a camada CMS. SignerInfo.digestAlgorithm deve ser exatamente o digest mapeado.

Parâmetros de SHA-256 e SHA-512 são omitidos. SHAKE256 também exige parâmetros ausentes e resultado de 64 bytes. Uma componente ECDSA pode empregar SHA-384 internamente dentro de um composto cujo prehash CMS é SHA-512. Essa diferença interna é legítima e não muda o mapeamento externo.

Logs precisam indicar a camada. Misturar digests internos e externos pode criar alarmes falsos ou esconder incompatibilidade real.

O conjunto SignedData.digestAlgorithms deveria incluir o digest correspondente para facilitar verificação em uma passagem. A omissão pode impedir o sucesso desse verificador. Mas o conjunto é uma pista do contêiner; não substitui a igualdade obrigatória do SignerInfo específico.

signedAttrs muda o que foi assinado

Sem atributos assinados, a assinatura cobre o valor do OCTET STRING eContent, excluindo tag e length. Com atributos, cobre o DER completo de SignedAttrs, incluindo tag e length. A entrada usa um tag EXPLICIT SET OF, não o IMPLICIT [0] que aparece no objeto final.

No mínimo aparecem content-type e message-digest. O receptor precisa recalcular o digest do conteúdo. Uma verificação feita sobre atributos recodificados de outra forma, ou sem comparar o digest, não conclui a validação CMS, mesmo com as duas componentes matematicamente válidas.

Preserve o hash do objeto bruto, o hash do conteúdo, o hash do DER exato, o digest recebido e recalculado e os bytes entregues ao verificador. Uma visualização ASN.1 reorganizada não é o original.

A primitiva tem uma context string, mas o perfil CMS a define como vazia. Separação de uso precisa vir de content type, atributos, política de certificado ou regra de aplicação comprovada.

Proteger a declaração de algoritmo

RFC 6211 define CMSAlgorithmProtection, que insere digest e algoritmo de assinatura ou MAC nos atributos assinados. RFC 8933 reforça consistência. A revisão 05 recomenda o atributo contra substituição.

Um campo externo não assinado pode mudar sem alterar a entrada criptográfica. Dentro de SignedAttrs, a declaração integra o DER protegido. O verificador pode compará-la com SignerInfo, OID composto e chave.

Presença não basta. Estrutura, posição, OIDs, parâmetros e compatibilidade precisam ser avaliados. Como o draft usa SHOULD, ausência é uma coordenada explícita de política, não algo a esconder num sucesso genérico.

Registro e texto seguem relógios diferentes

O draft pede um identificador de módulo ASN.1. Seu texto congelado ainda contém placeholder. A captura pública da IANA em 2 de outubro já lista decimal 88 para id-mod-composite-mldsa-cms-2026, referenciando o Internet-Draft.

Os dois fatos coexistem. Há alocação pública, fonte com marcador editorial, fila do RFC Editor e nenhum número RFC. A linha do registro não comprova publicação nem implantação.

Duas componentes válidas não autorizam a ação

A primitiva exige todas as componentes e proíbe reutilizar suas chaves fora do composto. Isso fortalece a propriedade criptográfica.

Não prova caminho e status do certificado, key usage, autoridade do assinante, sentido do documento, destinatário ou resultado. Uma aprovação assinada não demonstra execução.

Mantenha recibos separados para parsing, encoding, acordo de algoritmos, digest, componentes, certificado, identidade, autorização, decisão local, entrega, persistência e efeito externo.