Resumo

  • PrivateKeyInfo, da RFC 5208, e OneAsymmetricKey, da RFC 5958, definem uma representação para material privado. A forma sem criptografia não comprova sigilo, controle de acesso, HSM ou eliminação de cópias.
  • Descriptografar, validar, conferir a chave pública, importar, autorizar, operar e obter aceitação da aplicação são recibos distintos. Um parser não pode aprovar todos eles.

Um formato comum, uma promessa pequena

O PKCS #8 permite colocar chaves de algoritmos diferentes em um envelope previsível. A RFC 5208 define versão, identificador do algoritmo, uma OCTET STRING com a chave privada e atributos opcionais. O registro de cada algoritmo explica a estrutura interna.

Esse acordo resolve interoperabilidade, não custódia. Os bytes podem ter surgido em memória, passado por diretório temporário, chamado de suporte, clipboard ou backup sem alterar um único campo. O parse confirma gramática; não revela quem exerceu controle.

A RFC 5958 substitui a RFC 5208, chama o objeto de OneAsymmetricKey, admite chave pública opcional e cria um pacote de chaves. O texto diz que esse conteúdo leva chaves assimétricas em texto claro e não é protegido. Tipos CMS podem protegê-lo. A segurança começa numa camada adicional, não no nome PKCS #8.

O rótulo mostra a diferença que o painel apagou

A RFC 7468 usa PRIVATE KEY para o objeto não criptografado e ENCRYPTED PRIVATE KEY para EncryptedPrivateKeyInfo. A segunda estrutura guarda o algoritmo de criptografia e os dados cifrados. Primeiro ocorre a codificação; depois, a criptografia.

São eventos separados. O sistema precisa registrar a leitura do envelope, os parâmetros de KDF e cifra, sal e custo, a credencial apresentada, integridade, resultado da descriptografia e destino do texto claro. A palavra importado não informa em que instante a proteção acabou.

A RFC 8018 lembra que senhas costumam vir de espaços pequenos. Logo, o OID de uma função não atesta resistência. A evidência inclui parâmetros, política, limites de tentativa e implementação real. Um algoritmo forte com senha fraca não herda força do nome.

Custódia muda sem mudar a sintaxe

O mesmo arquivo pode ir de uma biblioteca a um cofre de software, KMS e HSM. Em cada salto mudam operador, jurisdição, cópias e possibilidade de exportação, embora a representação continue idêntica.

Extensão .p8, tipo application/pkcs8 e PEM correto não provam residência em hardware. Um identificador de objeto no HSM também não elimina a hipótese de cópia anterior, backup exportável ou política permissiva.

O recibo de custódia deve ligar hash de origem, canal, importador, slot, objeto, exportabilidade, réplicas, autorização, auditoria e exclusão de temporários. São fatos de operação. ASN.1 não os contém.

Parse correto, identidade errada

A RFC 5958 pode transportar a chave pública; formatos internos como EC também podem incluí-la. Mesmo assim é preciso derivar ou validar o público e compará-lo com certificado, conta ou registro independente. Estar no mesmo pacote não transforma a associação em autoridade externa.

A RFC 8479 permite salvar parâmetros que viabilizam a validação posterior de certas gerações RSA ou DSA. Salvar entradas não é executar a validação, e executar não é necessariamente aprovar. Sistemas honestos mantêm esses estados separados.

Depois vêm política e efeito. A chave pode ser válida e ter uso negado. Pode gerar assinatura rejeitada por mensagem, contexto, tempo, cadeia ou política. O último sistema consumidor decide o resultado da aplicação.

Compatibilidade não é migração

A RFC 5208 foi publicada como Informational em 2008. A RFC 5958, Standards Track de 2010, a tornou obsoleta, acrescentou campo público, versões e conteúdo CMS. A compatibilidade preserva a forma antiga.

Portanto, declarar RFC 5958 no inventário não prova atualização de exportador, importador, backup e recuperação. É necessário observar bytes, testar versões e campos, registrar falhas e restaurar de verdade. A especificação descreve possibilidade; o código em execução demonstra adoção.

O encadeamento que resiste a auditoria

Separar: bytes e origem; decodificação; ASN.1; claro ou protegido; KDF/cifra; descriptografia/integridade; validade matemática; correspondência pública; destino/exportabilidade; autorização; operação; verificação; aceitação; revogação e limpeza.

PRIVATE KEY é representação. Descriptografia é acesso ao claro. Correspondência pública liga pares. Log HSM registra operação numa fronteira. Verificação confirma uma saída para uma mensagem. Cada recibo pode existir sem o seguinte.

A liderança deve manter pequeno o padrão comum, explicitar decisões locais de custódia e usar resultados verificáveis do sistema em execução como prova principal. Proveniência permite explicar o caminho sem fingir que o caminho já entregou o efeito.

Fontes

  1. Informações da RFC 5208
  2. RFC 5208 HTML
  3. RFC 5208 texto
  4. IETF Datatracker: RFC 5208
  5. Histórico da RFC 5208
  6. Referências da RFC 5208
  7. Errata da RFC 5208
  8. Informações da RFC 5958
  9. RFC 5958 HTML
  10. RFC 5958 texto
  11. IETF Datatracker: RFC 5958
  12. Histórico da RFC 5958
  13. Referências da RFC 5958
  14. Errata da RFC 5958
  15. RFC 8018 — criptografia baseada em senha
  16. RFC 8351 — tipo de mídia EncryptedPrivateKeyInfo
  17. RFC 7468 — codificações textuais
  18. RFC 8479 — parâmetros de validação no PKCS #8
  19. RFC 5915 — estrutura de chave privada EC
  20. Heng Lu — camadas de realidade e poder simbólico
  21. Heng Lu — especificação inicial mínima
  22. Heng Lu — primazia do código em execução