Resumo

  • A RFC 9882 define ML-DSA-44, ML-DSA-65 e ML-DSA-87 em modo puro para CMS SignedData, mas não define HashML-DSA.
  • A presença de signedAttrs separa a assinatura do valor de eContent da assinatura do DER completo de SignedAttrs.

Os OIDs completos são 2.16.840.1.101.3.4.3.17, 2.16.840.1.101.3.4.3.18 e 2.16.840.1.101.3.4.3.19. Os parâmetros do AlgorithmIdentifier ML-DSA devem ser omitidos; o contexto ML-DSA é vazio.

Com atributos assinados, o resumo deve oferecer os lambda bits de segurança do conjunto ML-DSA contra ataques de segunda pré-imagem e colisão, e produzir no mínimo 2*lambda bits. A força total é limitada pelo menor nível. A Tabela 1 completa é: ML-DSA-44—SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256; ML-DSA-65—SHA-384, SHA-512, SHA3-384, SHA3-512, SHAKE256; ML-DSA-87—SHA-512, SHA3-512, SHAKE256. SHA-512 é obrigatório e SHAKE256 recomendado; ambos os identificadores omitem parâmetros.

Fixture de duas rotas. A rota A existe sem signedAttrs. Ela assina somente os octetos de valor do OCTET STRING eContent, excluindo tag e comprimento. Para interoperabilidade, o signatário codifica SHA-512 em digestAlgorithm; nessa rota o campo não tem significado criptográfico e o verificador ignora seu conteúdo. A rota A não contém content-type nem message-digest e não exige recálculo de message-digest ou do hash do conteúdo. A rota B existe com signedAttrs. Ela assina o DER completo de SignedAttrs, incluindo tag e comprimento, com a tag explícita SET OF, nunca a [0] implícita final. Inclui pelo menos content-type e message-digest; somente a rota B exige que o destinatário recalcule o hash do conteúdo e o compare com message-digest.

CMSAlgorithmProtection é recomendável incluir nos atributos assinados para resistir à substituição de algoritmos. Trata-se de uma recomendação normativa, não de uma alegação de implantação. Conteúdo grande pode ficar fora da fronteira de assinatura do HSM. O cálculo externo do representante mu em modo puro é permitido e descrito no Apêndice D da RFC 9881 e na Seção 6.2 da FIPS 204. Controles de interface HSM e sequência de implantação são análise de Theo March. Assinaturas hedged e determinísticas usam o mesmo verificador; não é recomendável usar a assinatura determinística quando houver preocupação com ataques de canal lateral ou de falha.

Leitura operacional

As regras normativas vêm de RFC 9882, RFC 5652, RFC 6211, RFC 9881 e FIPS 204. A análise de Theo March recomenda registrar rota, tamanhos e impressões digitais, OID, parâmetros ausentes, tags, atributos, identificador do resumo, comparação de hash em B, fronteira HSM e resultado. Ativação gradual, verificação em sombra e rollback testado são recomendações, não requisitos RFC nem evidência de adoção. RFC 9881 trata de PKIX; RFC 9879 tem outro escopo.

Fontes