Summary

  • Pure SLH-DSA e HashSLH-DSA recebem identidades distintas no RFC 9909; uma chave marcada em um modo não pode produzir nem verificar assinatura identificada no outro.
  • A prova de interoperabilidade guarda DER, ausência de parameters, bytes e comprimentos, keyUsage e resultados separados de assinatura, caminho de certificação e política.

Uma planilha de migração marcou três produtos como “compatíveis com SLH-DSA”. O primeiro reconhecia o OID. O segundo importava a chave. O terceiro verificava uma assinatura de laboratório. Nenhuma dessas colunas dizia se o mesmo certificado atravessaria toda a cadeia.

O cenário é ilustrativo, não um levantamento de fornecedores. Ele mostra a perda de informação contida na palavra “compatível”. No RFC 9909, um SubjectPublicKeyInfo identificado como Pure não pode ser combinado com assinatura HashSLH-DSA. E um AlgorithmIdentifier com NULL não cumpre a exigência de parameters ausente, mesmo que o parser conheça o algoritmo.

Publicado em dezembro de 2025 no Standards Track do IETF, o RFC foi produzido pelo grupo LAMPS. Ele define o uso de SLH-DSA em certificados, CRLs, chaves públicas e pacotes de chave privada X.509. O FIPS 205 do NIST padroniza o algoritmo. SPHINCS+ foi seu nome anterior, mas os dois formatos não são compatíveis; trocar a etiqueta de um ativo não converte seus bytes.

Há doze OIDs para Pure e doze para HashSLH-DSA. Eles distinguem níveis de 128, 192 e 256 bits, versões small e fast e funções internas SHA-2 ou SHAKE. No pre-hash, o identificador também informa a função usada antes da assinatura. O CSOR do NIST registra os mesmos valores.

O mesmo OID identifica chave pública, privada e algoritmo de assinatura. Essa escolha reduz liberdade propositalmente. O RFC proíbe usar uma chave Pure para gerar ou verificar assinatura Hash, e vice-versa, embora uma operação matemática possa ser construída. Interoperabilidade exige uma semântica única; tolerância local não pode reescrever o objeto público.

Também não há liberdade para “parâmetro vazio”. parameters deve estar ausente. NULL é um valor codificado. Perfis antigos criaram hábitos diferentes, e bibliotecas permissivas podem aceitar ambos. O recibo precisa registrar os bytes originais para mostrar se houve conformidade ou apenas tolerância de um componente.

A chave pública é PK.seed || PK.root, com 2*n bytes e n igual a 16, 24 ou 32. SubjectPublicKeyInfo coloca essa sequência diretamente no BIT STRING, sem outra embalagem ASN.1. A chave privada concatena SK.seed || SK.prf || PK.seed || PK.root, 4*n bytes, no OCTET STRING de OneAsymmetricKey.

OneAsymmetricKey pode incluir a chave pública para conferir o par. O RFC alerta, porém, que algumas funções de importação rejeitam a estrutura com esse campo. Verificação de consistência e alcance de importação são objetivos diferentes. A organização precisa testar geração, exportação, backup, restauração e uso no HSM, não somente um arquivo de exemplo.

Se keyUsage estiver presente, deve incluir pelo menos digitalSignature, nonRepudiation, keyCertSign ou cRLSign. keyEncipherment, dataEncipherment, keyAgreement, encipherOnly e decipherOnly são proibidos. SLH-DSA assina; não estabelece uma chave compartilhada. Depois desse controle, as regras do RFC 5280 para nome, validade, revogação e caminho continuam abertas.

A escolha Pure/Hash chega ao orçamento do HSM. Pure recebe a mensagem preparada; HashSLH-DSA usa um pre-hash definido e reduz o material enviado ao módulo. O processamento interno faz duas passagens e mantém M' em memória. CRLs grandes e certificados com muitos SANs podem ultrapassar limites de transferência ou memória em Pure.

O verificador enfrenta outra barreira: certificado ou CRL inteiro precisa permanecer disponível porque o randomizador retirado da assinatura entra no digest antes da mensagem, mas a assinatura vem depois no formato. Hash reduz M', sem provar capacidade de uma CA, HSM, sistema operacional ou navegador específico.

O RFC 9814 trata de CMS SignedData e escolhe Pure, com signed attributes capazes de diminuir o valor levado ao dispositivo. É um contrato vizinho, não um atalho para PKIX. O nome do algoritmo não elimina diferenças de aplicação.

Stateless não elimina contagem. Uma árvore não pode ultrapassar 2^64 assinaturas; quem puder chegar perto deve contar usos, destruir a chave no limite escolhido ou restringir a validade. Pares independentes, aleatoriedade, proteção da chave, falhas induzidas e canais laterais permanecem controles reais.

Na data de corte, a página de errata do RFC 9909 mostrava duas entradas, ambas Reported, não Verified. Relato, verificação, revisão do documento e mudança do código são estados diferentes. O operador não deve transformar uma sugestão em norma por conveniência.

O recibo mínimo preserva DER e hash, OIDs de chave e assinatura, presença de parameters, comprimentos, embalagem, keyUsage, contexto vazio, emissor, sujeito, âncoras, revogação, versão do validador e provedor criptográfico. Em seguida, separa conformidade de perfil, assinatura, caminho e decisão da aplicação. Fallback, se existir, ganha sua própria linha.

A primazia do código em execução de Heng Lu pede resultado observável. A especificação inicial mínima limita o núcleo compartilhado ao que precisa interoperar. As camadas de realidade impedem que registro, parsing, criptografia, confiança e autoridade virem uma única afirmação.

O RFC 9909 não entrega uma certificação genérica de prontidão pós-quântica. Ele fornece pontos de prova. OID coordena significado; DER materializa; o parser reconhece; o perfil restringe; a assinatura verifica; o caminho confia; a política age. “Compatível” só é honesto quando diz qual desses verbos foi observado.

Sources