Resumo

  • A RFC 9881 define o uso das variantes puras ML-DSA-44, ML-DSA-65 e ML-DSA-87 em certificados e CRLs PKIX.
  • Os OIDs completos são 2.16.840.1.101.3.4.3.17 para ML-DSA-44, 2.16.840.1.101.3.4.3.18 para ML-DSA-65 e 2.16.840.1.101.3.4.3.19 para ML-DSA-87. Os níveis de segurança são 2, 3 e 5.
  • O componente parameters de AlgorithmIdentifier DEVE estar ausente, e não ser NULL. signatureValue contém a assinatura ML-DSA bruta sobre a estrutura assinada em DER; o contexto opcional permanece vazio.

No PKIX, identidade algorítmica significa codificação exata. O OID selecionado fica em AlgorithmIdentifier, e a assinatura bruta fica em signatureValue. A verificação deve usar a estrutura assinada codificada em DER, não uma reserialização que apenas pareça equivalente. Para esse uso, o contexto é vazio.

SubjectPublicKeyInfo carrega os bytes brutos da chave pública ML-DSA, sem um invólucro ASN.1 adicional. Os tamanhos são 1.312 octetos para ML-DSA-44, 1.952 para ML-DSA-65 e 2.592 para ML-DSA-87. Quando keyUsage estiver presente, ao menos um bit de assinatura deve estar definido; bits de criptografia e acordo de chaves NÃO DEVEM ser definidos para chaves ML-DSA.

OneAsymmetricKey pode conter seed, expandedKey ou ambos. A forma somente com seed é recomendada para economizar armazenamento. O parser deve escolher a representação pela tag ASN.1, nunca por heurística de comprimento. Se ambas estiverem presentes e a verificação de consistência encontrar divergência, o destinatário DEVE rejeitar a chave como malformada.

A RFC 9881 seleciona ML-DSA puro. OIDs HashML-DSA NÃO DEVEM ser usados nos protocolos PKIX abrangidos. A fronteira com o Dilithium de pré-padronização também é explícita: ML-DSA e Dilithium não são compatíveis. Reconhecer o nome não autoriza aceitar o formato do outro.

Fontes