Resumo

  • A RFC 9883 permite que uma chave de assinatura certificada carregue uma declaração para outra solicitação de estabelecimento de chaves.
  • A declaração afirma posse, mas não fornece prova técnica da nova chave privada.
  • A AC deve validar o caminho do certificado signatário e a assinatura da solicitação; divergências de identidade dependem da política de equivalência.

A armadilha operacional está em tratar uma assinatura válida como resposta para duas perguntas. Ela mostra quem assinou a solicitação; não mostra quem controla a chave privada diferente que será certificada. O atributo privateKeyPossessionStatement transfere garantia da primeira chave para a segunda, mas somente por meio de uma afirmação assinada.

O OID do atributo é 1.3.6.1.4.1.22112.2.1. A estrutura completa é PrivateKeyPossessionStatement ::= SEQUENCE { signer IssuerAndSerialNumber, cert Certificate OPTIONAL }: signer identifica o certificado de assinatura por emissor e número de série, enquanto o campo opcional cert contém esse certificado. O cert só pode ser omitido quando a AC também é a emissora do certificado de assinatura e consegue recuperar todos os certificados válidos emitidos por ela. É uma exceção restrita de recuperação, não autorização para presumir a identidade.

A AC deve validar o caminho de certificação do certificado de assinatura e rejeitar a solicitação se o caminho for inválido. Também deve validar a assinatura da solicitação com a chave pública desse certificado e rejeitar falhas. O nome do sujeito e os SANs deveriam corresponder aos do certificado de assinatura. Se forem diferentes, a política de certificados deve explicar a equivalência; sem essa comprovação, a AC deve rejeitar. O atributo não pode ser usado para obter um certificado de assinatura.

No PKCS#10, subjectPublicKeyInfo contém a chave pública de estabelecimento, os atributos contêm a declaração e a assinatura da solicitação é validada com o certificado de assinatura. No CRMF, a solicitação carrega sujeito e chave pública de estabelecimento; o proof-of-possession do formato usa a escolha de assinatura e a identidade do remetente, enquanto regInfo carrega a declaração. A intenção pode ser semelhante, mas as estruturas de codificação não são iguais.

A RFC 5280 fornece a base para caminho de certificação e uso de chaves. A RFC 6955 é um contraste importante: apresenta mecanismos de prova técnica de posse para chaves Diffie-Hellman. A RFC 9883 não transforma seu atributo em prova criptográfica da segunda chave privada. Seu foco também não se confunde com os identificadores ML-DSA em PKIX da RFC 9881 nem com os bytes assinados em CMS da RFC 9882.

Análise de Theo March: o certificado de assinatura pode ser tratado operacionalmente como uma raiz de garantia delegada para a outra chave. Isso é análise, não obrigação da RFC. A AC deveria correlacionar cada certificado de estabelecimento emitido ao certificado autorizador, guardar a decisão de equivalência e monitorar volume por signatário, mudanças de sujeito, repetições e falhas. Sem correlação, a transferência desaparece dentro do fluxo de emissão.

A mesma dependência produz propagação de revogação. A RFC 9883 identifica a revogação tempestiva como a única proteção especificada quando o certificado de assinatura é comprometido e diz que a AC deveria revogar certificados de estabelecimento obtidos por declarações assinadas por ele. Inventário, alertas e propagação automatizada são análise operacional, não um fluxo obrigatório. A chave de assinatura deveria oferecer força de segurança pelo menos igual à da chave de estabelecimento. Na análise operacional, convém testar paridade, algoritmos e equivalência durante a migração.

Casos de teste: caminho e assinatura válidos; caminho inválido; assinatura alterada; certificado embutido ausente quando a AC não é emissora; omissão com recuperação bem-sucedida pela emissora; sujeitos e SANs divergentes com equivalência documentada e sem ela; tentativa de obter certificado de assinatura; chave signatária mais fraca; e mensagens PKCS#10 e CRMF verificadas em seus campos próprios. Correlacione emissor, série, impressões digitais, decisão e certificado emitido.

No incidente, interrompa a emissão a partir do certificado suspeito e preserve as evidências. Confirme o comprometimento, revogue rapidamente o certificado de assinatura, localize todos os certificados derivados pelas declarações e avalie ou revogue-os conforme a política da AC. Depois, substitua as chaves necessárias, reveja decisões de equivalência e força e monitore replay e novas declarações. Esse caminho é análise de resposta, não um procedimento completo imposto pela RFC.

Fontes