Resumo

  • No PBMAC1, o DigestAlgorithmIdentifier de MacData identifica o algoritmo e carrega KDF e MAC em parâmetros aninhados.
  • PBKDF2 com HMAC-SHA-256, keyLength explícito e bytes UTF-8 diretos para a senha formam a linha de base.
  • As RFCs definem sintaxe e validação; não comprovam suporte universal, certificação de produto ou segurança para qualquer cenário.

A fronteira de integridade do PFX é o MAC calculado sobre o conteúdo de authSafe. Quando o modo PBMAC1 é usado, os parâmetros dentro do DigestAlgorithmIdentifier de MacData informam duas escolhas separadas: a função de derivação baseada em senha e o esquema de autenticação de mensagem. Essas escolhas não devem ser inferidas dos campos antigos nem tratadas como detalhes cosméticos.

Os campos macSalt e iterations do MacData legado são ignorados no processamento PBMAC1. Ainda assim, a RFC 9879 recomenda que o produtor de arquivos codifique valores não vazios e diferentes de zero para conviver com implementações antigas que verificam primeiro o formato legado. Isso é uma concessão de compatibilidade, não uma reativação desses campos como entradas do PBMAC1. Usá-los como sal ou contagem ativa cria uma divergência de derivação.

A base obrigatória é o PBKDF2 com HMAC-SHA-256. Os parâmetros devem conter keyLength de forma explícita; a ausência não deve ser aceita e o leitor não deve inventar um valor. A senha é convertida diretamente em bytes UTF-8, sem caractere nulo final e sem BOM. Essa regra não é a representação histórica de senha do PKCS #12. Uma migração parcial pode, portanto, continuar falhando mesmo que o identificador do algoritmo tenha sido atualizado.

KDF e MAC são decisões independentes. Identificadores, parâmetros e comprimentos precisam ser verificados. HMAC-SHA-1 é desaconselhado; algoritmos de resumo com saída de 160 bits ou menos são proibidos para PBMAC1. Também é recomendável rejeitar chaves derivadas com menos de 20 octetos. Esses limites não tornam uma senha fraca forte e não fornecem confidencialidade: o assunto é integridade.

scrypt é opcional. Se for aceito, seus parâmetros e seu custo de recursos precisam ser validados antes da derivação, incluindo memória, processamento, paralelismo e tempo máximo. Não há um custo universalmente adequado definido pelas RFCs, e elas não demonstram que implementações PKCS #12 em produção ofereçam suporte ao PBMAC1.

A migração deve alinhar produtores de arquivos e leitores. O produtor gera os parâmetros aninhados do PBMAC1, keyLength explícito, UTF-8 direto e algoritmos permitidos. Pode manter campos legados não vazios para compatibilidade, mas não pode tratá-los como entradas de segurança do PBMAC1. O leitor valida a estrutura, rejeita omissões e escolhas fracas e limita o custo. A compatibilidade antiga precisa de prazo, telemetria e critério de encerramento.

Fontes