Resumo

  • O RFC 10002 mantém intacto o pedido assinado da entidade final e permite que uma Registration Authority acrescente testemunhos ou alterações em uma camada externa de PKIData.
  • Assinatura válida, posse da chave privada, identidade confirmada, testemunho da RA, controle processado e certificado emitido são conclusões diferentes.
  • A operação precisa guardar o pedido original, cada invólucro CMS, o escopo da RA, a ordem dos controles, a política da CA e a diferença exata entre pedido e certificado.

O sistema de inventário diz que a emissão foi bem-sucedida. A assinatura do pedido é válida. A assinatura da CA também. Mesmo assim, um campo do certificado não coincide com o pedido e uma extensão desapareceu.

O erro seria procurar apenas por adulteração do arquivo. No CMC, o pedido interno pode não ter sido tocado. Uma RA pode ter verificado uma identidade, envolvido o objeto já assinado, proposto uma mudança e repassado tudo à CA. A CA pode, por sua vez, aplicar uma política própria.

Publicado pelo IETF em julho de 2026, o RFC 10002 substitui os RFCs 5272 e 6402 e define as estruturas e os controles de Certificate Management over CMS. O RFC 10003 disciplina o transporte; o RFC 10004 distribui requisitos entre entidade final, RA e CA. O desenho não promete uma aprovação única. Ele permite uma cadeia de decisões atribuíveis.

O limite da assinatura do pedido

No RFC 2986, o PKCS #10 reúne nome do titular, chave pública, atributos opcionais e assinatura sobre essas informações. A verificação confirma a integridade dos bytes protegidos e o uso da chave privada de assinatura.

Ela não confirma o direito ao nome de uma empresa, não prova a posse de outra chave incapaz de assinar e não obriga a CA a copiar todas as extensões. Também não autoriza uma RA a mudar o pedido.

O Simple PKI Request pode carregar apenas o PKCS #10. Por isso não comporta a prova de identidade nem serviços avançados e não serve para uma chave privada sem capacidade de assinatura. No Full PKI Request, PKIData fica dentro de SignedData ou AuthenticatedData do CMS.

O RFC 5652 admite encapsulamento em camadas. Uma RA não precisa reescrever o PKCS #10 ou CRMF e invalidar a assinatura ou o POP. Ela preserva o núcleo e acrescenta um invólucro assinado. Várias RAs podem produzir vários níveis.

A assinatura interna mostra o que a entidade final protegeu. A externa mostra qual intermediário incluiu determinado controle. A autorização desse intermediário continua sendo outra verificação.

Posse de chave e identidade não se substituem

Proof of Possession pergunta se o ator controla a chave privada associada à chave pública solicitada. Uma assinatura pode resolver o caso de uma chave de assinatura. Para chaves de criptografia ou acordo de chaves, podem ser necessários desafio, resposta posterior ou confirmação. O RFC 4211 descreve essas opções no CRMF e reserva raVerified para certas provas executadas por uma RA.

A prova de identidade pergunta quem está associado à transação segundo o método de autenticação. Identity Proof Version 2 pode usar um segredo compartilhado para calcular um MAC sobre o material do pedido. O RFC 10004 exige essa versão moderna.

É possível possuir a chave sem ter direito ao nome pedido. Também é possível confirmar a pessoa no cadastro e não provar a chave de um módulo físico. Um único booleano “verified” destrói essa distinção.

RA POP Witness leva à CA a afirmação de que a RA realizou o POP. RA Identity Proof Witness transmite a afirmação de que a identidade foi verificada, inclusive fora de banda ou com um segredo que a CA não conhece. A CA recebe o testemunho, não a prova original. O registro precisa nomear a RA, o método, o alvo, o alcance do mandato e a referência à evidência.

Control Processed é uma afirmação mais ampla de tratamento local ou posterior. Quando importa saber qual prova foi feita, o testemunho específico não pode ser substituído por “processado”.

A mudança que não destrói a origem

Modify Certification Request permite que a RA solicite substituição ou exclusão de campos. O pedido assinado fica intacto; a mudança ocupa a camada externa e recebe a proteção da RA.

Há motivos legítimos: normalizar um nome, retirar uma extensão sem autorização ou converter uma identidade verificada ao formato aceito pela CA. A trilha precisa indicar body part, valor anterior, valor proposto, regra e responsável.

As camadas são processadas de dentro para fora. Vários controles no mesmo nível não têm ordem definida pelo RFC 10002. Depender da posição em um array amarra o resultado à implementação. Quando a precedência importa, deve haver uma decisão composta inequívoca ou camadas separadas.

A CA continua livre para aplicar sua política. Ela não precisa incluir todas as extensões e pode modificar valores, sem inverter o sentido de uma restrição pedida pelo cliente. O certificado é uma nova decisão assinada, não uma cópia autenticada do formulário.

Por isso, o operador compara três estados: pedido original, mudanças das RAs e certificado. Cada diferença recebe origem e justificativa. A assinatura da CA identifica o emissor final, não explica cada campo.

A transação vai além do POST

O RFC 10003 contempla arquivo, e-mail e HTTP. Pedidos HTTP usam POST; HTTPS protege o canal. Um HTTP 2XX não confirma o processamento dos controles nem a emissão final.

Uma operação pode ficar pending ou terminar parcialmente. Query Pending retoma a consulta; Confirm Certificate Acceptance mantém o estado depois da entrega. Se o servidor final não reconhecer ou não puder processar um controle obrigatório, todo o PKIData deve falhar. Ignorar o controle e responder sucesso seria fabricar semântica.

Transaction ID liga as mensagens. Sender e recipient nonces ajudam na correlação e na proteção contra replay. Ainda é necessária idempotência de negócio, mas sem esse estado uma retransmissão pode parecer novo pedido.

O RFC 10004 exige que RAs implementem Modify Certification Request, Control Processed e RA Identity Proof Witness; CAs preparadas para trabalhar com RAs precisam do lado receptor. Isso fixa capacidade mínima, não prova execução correta em um produto específico.

Depois da emissão, o RFC 5280 orienta a validação do certificado X.509 e reconhece políticas especializadas. O RFC 7030 descreve o EST, outra arquitetura de enrollment. CMC não é a única forma possível nem transfere confiança universal ao resultado.

Evidência reconstruível

O dossiê começa com bytes canônicos e hash do pedido. Separa formato, chave, atributos, resultado da assinatura, método POP, método de identidade, verificador, data e política.

Cada camada RA conserva invólucro assinado, certificado, escopo, controles adicionados, camadas removidas e próximo destinatário. Alterações têm antes e depois; testemunhos nomeiam a prova representada. Chaves privadas e segredos brutos não entram no log.

A CA registra sua decisão por campo e o diff. Transaction ID, nonces, tentativas, pending, aceitação, publicação e ativação ficam ligados.

Se uma RA for comprometida, o pedido interno pode continuar autêntico. O invasor pode assinar uma camada externa maliciosa com uma credencial reconhecida. Ausência de falsificação do pedido não significa ausência de dano.

Running-Code Primacy leva a análise ao código que valida a camada, confere o escopo e registra a decisão. Minimum Initial Specification mantém o mecanismo comum estreito, sem transformar o intermediário em soberano da política. A distinção entre realidade e símbolo impede que “assinado”, “testemunhado” ou “emitido” virem garantia total.