Resumo

  • Sem atributos assinados, o RFC 9814 aplica Pure SLH-DSA ao conteúdo; com atributos, aplica Pure SLH-DSA a DER(SignedAttributes) e liga o conteúdo por message-digest.
  • O caminho compacto pode manter gigabytes fora do HSM, mas transfere poder ao componente que lê o objeto, calcula o digest, define content-type e constrói DER.
  • HashSLH-DSA é um modo diferente. Descrever atributos CMS como “pré-hash SLH-DSA” pode selecionar o OID errado e apagar do registro justamente os bytes assinados.

O erro começa no diagrama

Em apresentações de arquitetura, “pré-hash” frequentemente significa apenas que o equipamento de chave recebeu poucos bytes. Essa abreviação é perigosa. Dois sistemas podem ter caixas e setas visualmente idênticas e produzir assinaturas incompatíveis: um executa um modo prehash definido no padrão do algoritmo; o outro usa CMS para representar o conteúdo dentro de atributos e então executa o modo Pure sobre esses atributos.

O RFC 9814, publicado em julho de 2025, especifica o uso de Pure SLH-DSA com contexto vazio em CMS SignedData. Ele não especifica HashSLH-DSA para essa aplicação. O mecanismo de atributos do CMS continua podendo reduzir a entrada final de assinatura, mas não muda o modo SLH-DSA.

Antes de aprovar um produto, é preciso pedir uma resposta em bytes: qual é a entrada exata da função Pure SLH-DSA? Há duas respostas válidas, condicionadas à presença de SignerInfo.signedAttrs.

Sem atributos: assinatura sobre o conteúdo

Quando signedAttrs não existe, o conteúdo é o mensagem da assinatura. O contexto é vazio, conforme o perfil. O campo SignerInfo.digestAlgorithm não serve para transformar o conteúdo em um digest antes de Pure SLH-DSA. O RFC diz que esse campo não tem relevância para o cálculo da assinatura nesse caminho.

Isso impede um atalho comum em APIs remotas. Se o serviço aceita somente um digest arbitrário e o chama de mensagem, ele não implementou automaticamente a operação do RFC 9814. A presença de sha256 na estrutura CMS tampouco prova o uso de HashSLH-DSA.

Para cargas grandes, o custo aparece no caminho dos dados. O assinador precisa receber a mensagem segundo a implementação Pure. O verificador que guardou apenas um digest durante uma transmissão não pode presumir que esse valor basta para uma verificação posterior. Retenção, releitura ou uma interface apropriada tornam-se parte do projeto.

Com atributos: assinatura sobre uma declaração canônica

Quando signedAttrs existe, o CMS calcula o digest do conteúdo e o coloca no atributo obrigatório message-digest. Outro atributo obrigatório, content-type, identifica o tipo CMS do conteúdo. O conjunto completo é codificado em DER. É essa codificação, e não o arquivo grande, que Pure SLH-DSA assina.

O resultado é uma cadeia de afirmações:

  1. Esta versão imutável forneceu estes bytes e este comprimento.
  2. Este algoritmo produziu este digest.
  3. Este digest e este tipo foram colocados neste conjunto completo de atributos.
  4. Este conjunto produziu estes bytes DER.
  5. Esta chave assinou esses bytes com este identificador Pure SLH-DSA.
  6. Esta cadeia de certificado e esta política autorizaram o resultado.

Um recibo do HSM geralmente cobre parte do quinto item. Ele não prova qual versão o aplicativo leu, se houve reinício parcial do stream ou se o tipo mostrado ao aprovador corresponde ao valor assinado.

Na validação, o digest deve ser recalculado sobre o conteúdo recebido e comparado com message-digest. content-type também precisa coincidir com o tipo do conteúdo encapsulado. Essa verificação protege semântica: tipos podem selecionar parsers, permissões, retenção e automações distintas.

DER é entrada criptográfica

Uma planilha de atributos não preserva necessariamente a mensagem assinada. DER determina tags, comprimentos, tipos e ordenação canônica. Atributos desconhecidos ou valores reconstruídos com outro tipo podem mudar os bytes mesmo quando a tela parece igual.

O objeto CMS original deve ser preservado. Para decisões de alto impacto, registre também os bytes DER enviados ao assinador, um hash de auditoria desses bytes, a versão do construtor e uma reprodução feita por implementação independente. Se somente o fornecedor consegue explicar como os atributos viraram bytes, existe dependência no nível da prova.

O construtor de atributos é uma autoridade. Guardar a chave em hardware não impede um middleware de selecionar o objeto errado, omitir content-type, mudar um atributo depois da aprovação ou calcular o digest sobre uma versão temporária. A certificação do módulo não se estende automaticamente ao código que prepara sua entrada.

Uma história coerente de algoritmos

Com atributos assinados, digestAlgorithm identifica o hash de message-digest, e SignedData.digestAlgorithms precisa representar os algoritmos usados pelos assinadores. O RFC 9814 exige saída de digest adequada à resistência a colisões do conjunto SLH-DSA escolhido. A política deve validar a combinação, não apenas cada nome isolado.

Há doze identificadores de assinatura para conjuntos Pure SLH-DSA, com parâmetros ausentes. O verificador confere compatibilidade entre algoritmo de assinatura e chave pública. O RFC 9909 cobre o contexto X.509 relacionado, mas uma cadeia válida não demonstra que o aplicativo hasheou o conteúdo certo.

O atributo assinado CMSAlgorithmProtection, do RFC 6211, deve ser incluído para proteger as escolhas de digest e assinatura contra substituição. Como a norma usa SHOULD, sistemas legados podem não trazê-lo. A ausência precisa de uma decisão explícita, uma métrica e um plano; aceitação silenciosa transforma exceção em padrão real.

A diferença para HashSLH-DSA

FIPS 205 define variantes Pure e prehash. No caminho do RFC 9814 com atributos, o digest de conteúdo é uma afirmação dentro do CMS; a entrada de Pure SLH-DSA é o DER que também contém tipo e outros atributos. HashSLH-DSA é uma operação distinta, com identificadores próprios.

O inventário técnico deveria escrever “Pure SLH-DSA sobre SignedAttributes; conteúdo vinculado por digest”. Essa frase impede que um migrador tente verificar a assinatura sobre o digest isolado. Também obriga o contrato de auditoria a preservar o DER, e não somente o valor do hash.

Streaming muda o dono do risco

Com atributos, o receptor pode calcular o digest enquanto recebe o conteúdo, liberar blocos e depois verificar a pequena estrutura. O assinador pode evitar enviar gigabytes ao HSM. O benefício operacional é plausível, embora o RFC não prometa desempenho de produto.

O risco migra para o leitor e o hasheador. Testes devem interromper e retomar streams, trocar a versão sob o mesmo nome, misturar fragmentos, alterar comprimento e variar a origem do content-type. Cada situação precisa produzir rejeição clara ou um recibo que demonstre continuidade.

O pacote de evidência mínimo inclui ID e versão imutáveis, tamanho, algoritmo e digest, tipo CMS, atributos completos, DER exato, conjunto SLH-DSA, chave, certificado, assinatura, política e resultados separados para leitura, digest, tipo, atributos, proteção algorítmica, assinatura e caminho de confiança.

Mude um elemento por vez nos testes: um byte do conteúdo, digest, tipo, atributo, DER, OID, chave e certificado. Um erro genérico de “assinatura inválida” não basta; a etapa responsável deve ser observável.

O RFC 9814 não certifica adoção, throughput, fornecedor ou segurança pós-quântica de todo o CMS. Criptografia de conteúdo, cadeia de certificados, aleatoriedade, falhas, canais laterais e custódia continuam separados. O limite de menos de 2^64 assinaturas por chave SLH-DSA também demanda contagem e rotação.

A ideia de especificação inicial mínima de Heng Lu ajuda a cortar a retórica: publique a menor interface capaz de ser testada por partes independentes. A camada de realidade é a reprodução do caminho conteúdo–digest–DER–assinatura–política. “Compatível com RFC 9814” só ganha significado quando esse caminho pode ser refeito.

Fontes