Resumo

  • A Prova de Posse da RFC 10002 confirma que uma entidade final possui e consegue usar a chave privada correspondente à chave pública. Ela não confirma, sozinha, identidade, direito sobre um nome ou autorização de emissão.
  • CMC trata identidade e posse em provas separadas e exige vinculá-las à mesma entidade. Autoridades de Registro acrescentam controles fora da solicitação assinada; a Autoridade Certificadora ainda aplica sua política e decide se emite, altera, deixa pendente ou rejeita.
  • Um comprovante de inscrição precisa preservar a solicitação original, os dois tipos de prova, o vínculo contra substituição, cada camada de intermediação, a decisão da CA, a resposta, o certificado exato e os estados posteriores de entrega, instalação, validação e revogação.

Considere dois arquivos perfeitamente válidos: uma solicitação assinada e um documento que identifica uma empresa. Eles ainda não formam, por proximidade, uma solicitação autorizada em nome daquela empresa. Falta demonstrar que a mesma parte apresentou a identidade e controla a chave. Falta saber se ela pode pedir os nomes e usos inseridos. Falta uma decisão da autoridade que assinará o certificado.

Essa decomposição orienta Certificate Management over CMS. A RFC 10002 organiza as mensagens; a RFC 10003 define transportes por HTTP, arquivo, correio e TCP; a RFC 10004 estabelece requisitos para classes de agentes CMC. Publicadas em julho de 2026, as três têm Joseph Mandel e Sean Turner como editores. O conjunto reúne trabalho anterior sobre CMS, PKCS #10, CRMF e X.509, portanto não deve ser atribuído a Turner como criação individual.

O perfil público do IETF registrava, em 1º de setembro de 2026, participação de Turner desde o IETF 34, autoria ou coautoria de mais de 50 RFCs, atuação como Security Area Director de 2007 a 2014 e diversas funções de coordenação. A trajetória contextualiza o trabalho de padronização. Não lhe dá poder sobre uma Autoridade de Registro, uma Autoridade Certificadora ou uma solicitação específica.

A assinatura fixa o pedido, não sua aprovação

PKCS #10 coloca chave pública, sujeito e atributos em uma estrutura assinada. Verificar a assinatura mostra que o conteúdo permaneceu íntegro e que alguém capaz de usar a chave privada correspondente assinou. A verificação dificulta que um terceiro troque a chave pública dentro do objeto e conserve uma solicitação válida.

Entretanto, a RFC 2986 descreve outras tarefas da Autoridade Certificadora: autenticar a entidade solicitante, verificar a assinatura e, se o pedido for válido, construir o certificado. A validade envolve regras da autoridade. A assinatura não decide titularidade de domínio, vínculo organizacional, finalidade da chave, duração ou modelo de certificado.

Na RFC 10002, Proof-of-Possession, POP, é a categoria de provas de que a entidade final detém e usa a chave privada. Há formas por assinatura, desafio direto, prova indireta, publicação e atestação. Nem toda troca emprega todas elas, e nenhuma expande automaticamente o objeto da prova.

Uma chave roubada pode assinar. Um equipamento legítimo pode estar associado ao ativo errado. Uma pessoa que administra chaves pode não ter delegação para solicitar o nome de um serviço. Assim, POP verificada pode ser verdadeira quando identidade verificada ou emissão autorizada é falsa.

O vínculo entre identidade e chave impede a montagem indevida

CMC define Proof-of-Identity em separado. Uma Simple PKI Request não deve ser usada quando a prova de identidade precisa acompanhar o pedido. A Full PKI Request admite uma testemunha derivada de segredo compartilhado, ligação a certificado existente ou outro método bilateral.

A separação torna os fatos legíveis, mas permite um ataque de substituição: combinar a identidade correta de uma parte com a chave correta de outra. A RFC 10002 exige garantir que a mesma entidade forneceu a identidade e a POP. Testemunhas, correspondência entre segredo e nome de sujeito e certificados anteriores são mecanismos para esse vínculo.

O vínculo deve virar um evento auditável. O registro precisa dizer quais identificadores foram unidos, quais bytes foram cobertos, quem verificou, qual teste contra substituição foi aplicado e qual foi o resultado. Duas marcações verdes sem uma referência comum não resolvem o problema.

O segredo compartilhado também tem uma origem fora do protocolo. A RFC não especifica sua distribuição fora de banda. Se foi entregue ao dispositivo errado, copiado entre ativos ou reutilizado em tentativas, uma testemunha correta só demonstra conhecimento daquele segredo. A qualidade do enrolamento original continua sendo parte da evidência.

A RA acrescenta sua decisão sem alterar a assinatura original

CMC distingue Entidade Final, Autoridade de Registro (RA) e Autoridade Certificadora (CA). A RA pode conferir identidade, gerar ou arquivar chaves, agrupar e encaminhar pedidos ou processar extensões. Diante da entidade final ela pode ser servidor; diante da CA, cliente. A direção da comunicação não transforma intermediação em poder de emissão.

Modificar o corpo assinado de PKCS #10 ou CRMF invalidaria assinatura e POP. Quando uma RA pede mudança de campo ou inclusão de extensão, registra essa ação em um controle externo. Várias RAs podem criar camadas aninhadas. Cada camada mantém visível quem pediu o quê.

Essa separação evita que a vontade do intermediário seja atribuída ao solicitante. Também explica por que as extensões requeridas não aparecem necessariamente iguais no certificado. O servidor deve processar as extensões previstas, mas não é obrigado a emitir todas. Pode ajustar uma solicitação sem inverter sua intenção, sob a política aplicável.

Guardar apenas o certificado apaga o pedido. Guardar apenas o pedido apaga a transformação autorizada. O histórico defensável reúne solicitação assinada, controles externos, signatários, justificativas, modelo avaliado pela CA, decisão e certificado devolvido.

O sucesso do HTTP termina antes da decisão de certificação

No transporte HTTP da RFC 10003, o cliente envia POST com tipos de mídia definidos. HTTPS pode proteger o canal, mas a especificação não obriga todos os clientes CMC a implementar autenticação HTTP. Canal protegido, autenticação HTTP, identidade CMC e POP são verificações independentes.

Um código 2xx informa que a operação HTTP foi tratada. A resposta CMC contida pode ficar pendente ou indicar badIdentity, popRequired, popFailed e extensões incompatíveis. A entrega do envelope não aprova seu conteúdo.

Quando há sucesso CMC, ainda se compara o objeto devolvido: chave pública, sujeito, nomes alternativos, usos, políticas e validade. Também se prova a entrega à entidade prevista. Um rótulo de conclusão sem os bytes do certificado não fecha a emissão.

Conformidade com a RFC 10004 responde a outra pergunta: se a implementação oferece os recursos exigidos para uma classe de agente. Não comprova implantação correta, adoção comercial, volume nem decisão sobre uma transação.

O uso do certificado começa depois da emissão

RFC 5280 trata de caminho de certificação, âncoras de confiança, restrições de nome, políticas, validade e revogação. Depois vêm instalação, correspondência com a chave privada e autorização do serviço. Cada estágio pode divergir.

Um certificado correto pode não chegar ao equipamento. Um certificado instalado pode encontrar a chave errada. Um caminho válido pode terminar em uma âncora não aceita pela aplicação. A identidade autenticada pode não ter permissão para a ação pedida. Uma revogação muda o resultado ao longo do tempo.

A primazia do código em funcionamento defendida por Heng Lu sugere manter material reproduzível para cada afirmação. Na inscrição: bytes do pedido, POP, identidade, vínculo, camadas das RAs, política da CA e resposta. Na operação: certificado, chave correspondente, destino, resultado do caminho, fonte de status e autorização local.

O recibo mínimo separa solicitante e hora; chave e campos requeridos; método e resultado de POP; método e limite de identidade; vínculo; alterações das RAs e signatários; CA e versão de política; status CMC; certificado exato; entrega e instalação; revogação, substituição e correção.

A contribuição coletiva editada por Turner é valiosa por conservar essas fronteiras. Ela não transforma o primeiro fato criptográfico em poder administrativo; mostra onde cada poder precisa deixar prova própria.

Fontes