Resumo

  • A RFC 9883 permite que uma chave de assinatura certificada sustente uma declaração sobre a posse de outra chave privada, sem executar prova técnica com a chave de estabelecimento.
  • A CA precisa validar caminho, assinatura e identidade e aplicar uma política que autorize explicitamente essa substituição.
  • Se a chave de assinatura for comprometida, os certificados de estabelecimento emitidos com base em suas declarações formam um conjunto dependente de revogação.

O dossiê parece conclusivo: há uma chave pública nova, um atributo de posse e uma assinatura correta. O detalhe decisivo é que a assinatura veio da chave privada do certificado anterior. A chave privada correspondente à nova chave pública não foi usada no ato verificável.

A sequência preserva dois papéis

Primeiro, o titular gera um par de assinatura, assina um pedido comum e recebe um certificado com uso de assinatura. Depois gera o par de estabelecimento. O segundo pedido PKCS#10 inclui a nova chave pública e o atributo privateKeyPossessionStatement, identifica o certificado anterior e é assinado com a chave privada de assinatura.

A RFC 9883 diz sem ambiguidade que o titular declara, sem oferecer prova, possuir a chave privada de estabelecimento. A CA pode aceitar a declaração somente quando sua política de certificados permitir. A RFC 6955 fornece mecanismos técnicos para certos casos de DH e ECDH, mas eles não servem para PKCS#10 nem abrangem KEMs como ML-KEM. O novo atributo pode ser transportado em PKCS#10 e CRMF.

Logo, a assinatura válida comprova controle da chave de assinatura naquele pedido. Ela vincula uma credencial anterior a uma afirmação sobre outra chave. Não informa onde a chave de estabelecimento foi criada, se pode ser exportada, se ainda existe ou se ficou dentro de um módulo específico.

A decisão pertence à CA

A CA deve validar o caminho do certificado de assinatura conforme a RFC 5280 e verificar a assinatura do pedido; falha implica rejeição. O nome do titular deveria coincidir. Quando nomes de titular ou nomes alternativos diferem, a política precisa definir como demonstrar que identificam a mesma entidade. Sem essa conclusão, o pedido deve ser rejeitado.

O atributo aponta para o certificado de assinatura por emissor e número de série e pode carregar uma cópia. Se o emissor dos dois certificados for o mesmo, a cópia pode ser omitida, mas o solicitante passa a supor que a CA consegue recuperar todos os certificados válidos que emitiu. Isso é uma propriedade operacional do repositório. Um localizador não é o certificado recuperado, o caminho validado ou o estado histórico de revogação.

No CRMF, a escolha de assinatura em ProofOfPossession, poposkInput, o remetente e uma cópia da chave pública mantêm a ligação; a declaração entra em regInfo. A estrutura muda, mas a chave de estabelecimento continua sem produzir prova.

A própria RFC proíbe usar o atributo para obter certificado de assinatura. Uma chave capaz de assinar pode demonstrar diretamente sua posse assinando o próprio pedido. A exceção é estreita e voltada às chaves de estabelecimento.

A revogação segue a dependência

Quem controlar a chave de assinatura comprometida poderá criar novas declarações. A proteção indicada é revogar rapidamente o certificado correspondente. A CA também deveria revogar todos os certificados de estabelecimento obtidos com declarações assinadas por ele.

Isso exige um índice reverso criado no momento da emissão: certificado assinante, bytes do pedido, versão da política, decisão de identidade e certificados resultantes. A chave de assinatura deveria ser pelo menos tão forte quanto a chave de estabelecimento; caso contrário, a ponte de confiança será o elo mais fraco.

Fontes