Resumo

  • Digest, ECDSA, HMAC e HKDF com SHA3 exigem parâmetros ausentes; RSA PKCS#1 v1.5 com SHA3 exige NULL; KMAC exige ausência sem personalização e os octetos exatos quando S existe.
  • Um OID reconhecido ou uma assinatura válida não prova preservação do objeto, execução da ramificação correta, validade de certificado, autoridade do signatário ou conclusão da aplicação.

O incidente analítico começa numa migração. O acervo é lido pela biblioteca antiga e gravado pela nova. Os relatórios antes e depois exibem o mesmo algoritmo. Só uma comparação binária mostra que o NULL obrigatório do identificador RSA sumiu. A equipe migrou “metadados equivalentes”; na verdade, substituiu o artefato.

Não há aqui alegação sobre fornecedor ou incidente real. A lição é sobre evidência. O OID coordena um nome. O recibo completo precisa manter o papel CMS, o estado dos parâmetros, qualquer identificador aninhado, os bytes, a chave, o caminho de implementação, a política e o resultado da aplicação.

As regras não convergem para um padrão único

Nos quatro digest SHA3, o campo de parâmetros deve estar ausente. A regra alcança os locais de digest em SignedData, SignerInfo, DigestedData e AuthenticatedData. Inserir NULL não é uma representação alternativa autorizada.

ECDSA com SHA3, HMAC com SHA3 e HKDF com SHA3 também exigem ausência. Um serializador que completa todos os identificadores com NULL cria uma incompatibilidade escondida sob o nome certo.

RSA PKCS#1 v1.5 com SHA3 exige o inverso: NULL deve estar presente. Um normalizador que remove valores nulos porque os considera redundantes viola a regra desse campo.

KMAC acrescenta a condição. Sem S, os parâmetros de KMAC128-KDF ou KMAC256-KDF ficam ausentes. Com S, precisam conter aquela personalização em OCTET STRING. Ausência e string vazia presente devem permanecer distinguíveis.

Essa matriz demonstra por que a camada comum precisa ser exata e pequena. A política local pode autorizar ou negar algoritmos. Ela não deve reescrever silenciosamente o que a outra parte enviou.

O KDF não cabe numa etiqueta

KMAC consome K, X, L e S. A chave pode vir de uma decapsulação KEM. O contexto X, no uso com RFC 9629, contém o DER de CMSORIforKEMOtherInfo. L define a saída. S separa usos.

Um log com id-kmac128 não permite reproduzir a chave derivada. Mesmo OID e parâmetros não resolvem a falta de X e L. A divergência pode acontecer antes de qualquer comparação de MAC ou descriptografia.

KDF2 e KDF3 carregam um identificador de digest dentro dos parâmetros. Ao escolher SHA3, esse identificador interno precisa omitir parâmetros. Validar apenas a camada externa não prova a construção completa.

Evidência antes da normalização

Um parser tolerante pode aceitar duas codificações e convertê-las no mesmo objeto interno. Se os bytes originais forem descartados, desaparece a distinção entre tolerância do receptor e conformidade do emissor. Ao regravar, o sistema cria uma terceira afirmação: a sua própria forma preferida.

Preserve o hash do CMS recebido, o caminho do campo, o OID, a forma e o hash dos parâmetros, identificadores internos, versão do parser, transformação, provedor criptográfico, chave, operação e resultado. Depois mantenha recibos separados para certificado, política, autorização e resultado de negócio.

Uma assinatura válida é uma prova importante, mas não universal. Ela não decide sozinha quem tinha autoridade, se o objeto era atual, se o conteúdo significava o que a aplicação inferiu ou se a operação foi executada.

Registro e execução são camadas diferentes

As atribuições IANA tornam os nomes únicos e compartilháveis. Não testam bibliotecas, não contam implantações e não provam interoperabilidade. A execução é demonstrada por bytes capturados, vetores, versões, saídas e recibos de aplicação.

O registro não precisa se transformar em fiscal de código. O código não pode usar a existência do registro como certificado. Cada camada é mais confiável quando permanece dentro da sua função.

Fontes