Resumo

  • A RFC 9810 reserva accepted para o resultado exatamente solicitado e usa grantedWithMods quando a autoridade entrega algo semelhante, cabendo ao solicitante descobrir as diferenças.
  • Proteção de mensagem, nonces e identificador de transação autenticam a troca, mas não provam que nomes, validade, Key Usage, EKU, restrições e política do certificado preservam a intenção autorizada.
  • Um recibo local de intenção do certificado pode ligar pedido, objeto emitido, delta de campos, competência para modificar e decisão de aceitar ou rejeitar, sem guardar chaves privadas. É uma proposta editorial de Daniel Kade, não um campo do CMP.

Em automação de certificados, “sucesso” parece uma propriedade simples. A autoridade respondeu, a proteção criptográfica foi validada e há um certificado decodificável. Mas a RFC 9810 não entrega um único sucesso. Ela separa o cumprimento exato de uma concessão acompanhada de modificações.

Essa segunda resposta não denuncia defeito. Uma autoridade certificadora pode limitar a validade, normalizar um nome, escolher o número de série, remover uma extensão não aceita ou aplicar um perfil obrigatório. A AC deve controlar o que assina. O solicitante, porém, deve controlar o que aceita para uso. grantedWithMods é o ponto em que uma responsabilidade passa à outra.

O pedido descreve uma intenção, não domina a assinatura

Publicada em julho de 2025 na trilha de padrões do IETF, a RFC 9810 define o Certificate Management Protocol para criação e gestão de certificados X.509. O protocolo organiza interações de entidades finais com Autoridades de Registro e Autoridades Certificadoras. Ele substitui a RFC 4210 e, junto com a RFC 9811, também substitui a RFC 9480.

O solicitante pode usar CertTemplate para indicar o conteúdo desejado. A estrutura se parece com a parte do certificado que será assinada e admite campos opcionais ou situacionais: chave pública, sujeito, validade e extensões. Antes do pedido, a entidade pode até consultar um modelo para saber o que a AC espera.

Ainda assim, especificar tudo não obriga a AC a copiar tudo. O texto afirma que a autoridade pode alterar campos do certificado efetivamente emitido. Por isso accepted significa que se recebeu exatamente o solicitado, enquanto grantedWithMods significa que se recebeu algo parecido e que o solicitante deve apurar as diferenças.

Quando uma plataforma converte ambos em true, ela elimina uma bifurcação prevista pelo protocolo. O software passa a decidir, por omissão, que qualquer modificação positiva é aceitável. A governança não desaparece; ela fica escondida numa condição de código.

O alcance muda dentro dos campos

A RFC 5280 mostra o peso desses campos. A parte assinada traz emissor, validade, sujeito, informação da chave pública e extensões, além de versão, série e algoritmo. Uma mudança pode ser administrativa ou pode redefinir identidade, duração e capacidade.

Key Usage distingue assinatura digital, cifragem, acordo de chaves, assinatura de certificados e assinatura de CRLs. Extended Key Usage expressa finalidades. Basic Constraints diferencia entidade final de autoridade certificadora e limita caminhos. Nomes alternativos representam serviços. Políticas de certificado oferecem contexto para quem confia.

Nem todo delta é material. Um número de série da AC é esperado. Uma validade menor pode reduzir exposição. Uma forma equivalente de nome pode estar prevista no perfil. Porém, outra chave pública, um SAN inesperado, uma EKU mais ampla, capacidade de assinar certificados, alteração de criticalidade ou extensão crítica desconhecida pode mudar o poder operacional.

A própria RFC 9810 ressalta um caso: determinadas EKUs de gestão de PKI delegam autorização que originalmente pertence ao certificado da AC. É uma ação sensível, que deve ser aprovada com cuidado para que somente entidades legítimas recebam esse uso. Nesse ponto, comparar campos é comparar autoridade.

Um hash binário só mostra que os objetos diferem. A avaliação precisa decodificar o significado: qual período mudou, qual EKU apareceu, qual identidade foi alterada, qual restrição desapareceu. Depois, a política local decide se o delta é automático, se exige responsável nomeado, se requer novo pedido ou se deve ser recusado.

Autenticação não é equivalência semântica

CMP usa proteção de mensagens, IDs de transação e nonces para formar uma conversa verificável. Pode usar segredo compartilhado ou assinatura. A prova de posse demonstra controle da chave privada. Uma AR pode validar, autorizar, proteger, encaminhar ou modificar uma solicitação conforme o perfil.

Essas garantias são pré-condições para confiar no objeto recebido. Elas não demonstram que o objeto corresponde à finalidade local. Uma encomenda assinada pode ter vindo do remetente correto e conter uma substituição legítima; o destinatário ainda precisa decidir se aceita a substituição.

Quando uma AR modifica a solicitação, a trilha precisa separar o valor da entidade final, a transformação feita pela AR, o conteúdo assinado pela AC e a regra que autorizou cada diferença material. “Validado pela AR” é amplo demais para provar essa passagem.

Confirmar o certificado é escolher o estado futuro

O certConf permite à entidade aceitar ou rejeitar certificados da resposta. A ausência de statusInfo em um certificado indicado significa aceitação. A ausência da estrutura correspondente significa rejeição; uma sequência vazia pode rejeitar todos. Também é possível enviar o hash com estado explícito de rejeição.

Esse passo não é mera cortesia de encerramento. Ele nomeia o certificado que o solicitante aceita incorporar. A decisão deve se referir ao objeto emitido, não apenas ao ID do pedido ou à presença de uma resposta protegida.

O perfil leve da RFC 9483 apresenta a máquina de estados. Depois de accepted ou grantedWithMods, ocorre certConf seguido de pkiConf, salvo quando a confirmação implícita foi pedida e concedida. Se a confirmação esperada não chega, a situação deve ser tratada como rejeição.

implicitConfirm economiza uma rodada. Ele não elimina a comparação local. Numa frota, o avaliador deve conhecer de antemão os deltas permitidos, proibidos e sujeitos a exceção. Caso contrário, uma otimização de desempenho antecipa consentimento para mudanças ainda não classificadas.

Política diz por que a mudança pode ser legítima

A RFC 3647 diferencia Certificate Policy, que estabelece requisitos, de Certification Practice Statement, que descreve como uma AC executa práticas e controles. Um status CMP não contém toda a razão institucional para cada escolha da autoridade.

Uma solicitação pode pedir dois anos e uma EKU; o perfil pode limitar a um ano e exigir outra combinação para dispositivos gerenciados. O certificado pode estar correto segundo a prática publicada e errado para o desenho local. A pergunta verificável é se o solicitante adotou aquele perfil e aquela versão para essa classe.

O mesmo registro deve evitar suspeitar de todo valor escolhido pela AC. Campos de domínio do emissor são marcados como esperados. Campos que alteram o escopo autorizado do solicitante recebem análise. O objetivo não é igualdade byte a byte, mas competência explícita.

Transparência torna visível, não autorizado

Certificate Transparency oferece um registro público e auditável de emissão. A RFC 9162 permite detectar certificados suspeitos e auditar logs, mas declara que os logs não impedem sozinhos uma emissão indevida.

Um certificado em CT não está, por isso, aceito pelo solicitante ou aprovado para produção. Em um caso de prova indireta de posse, a RFC 9810 proíbe publicar o certificado final em CT antes do certConf que contém seu hash e completa a prova. Emitido, confirmado e publicado são momentos diferentes.

Depois deles ainda há instalação e confiança. Um certificado aceito pode nunca entrar em serviço. Pode ser usado numa aplicação e rejeitado em outra. Partes confiantes aplicam políticas próprias. Observabilidade não absorve decisão operacional.

Um recibo de intenção preserva o delta

O recibo de intenção do certificado começa com identificadores canônicos do pedido protegido, do CertTemplate, do perfil e do certificado emitido. Guarda a transação e o status sem armazenar chave privada, segredo compartilhado, pacote central descriptografado ou documentação pessoal desnecessária.

Em seguida, compara chave pública, sujeito, SAN, validade, Key Usage, EKU, Basic Constraints, políticas, restrições relevantes, criticalidade e extensões exigidas pela aplicação. Cada delta material recebe uma disposição: esperado pelo perfil, aprovado por papel competente, recusado ou pendente. Versões de avaliador e política ficam registradas.

Aceitação, publicação e implantação permanecem separadas. O recibo informa confirmação explícita ou implícita, quem podia aceitar para aquela classe, prazo da exceção, alvo de reversão e eventual revogação ou reemissão. A correção acrescenta estado; não apaga a decisão original.

O registro é local e de acesso controlado. Mesmo um certificado público pode trazer, ao lado de metadados de inscrição, um mapa de nomes internos, dispositivos e exceções. CT já oferece uma camada pública delimitada. O recibo preserva a linhagem decisória dentro da organização.

O código em execução deve manter a distinção

A separação de Heng Lu entre especificação, decisão local, adoção, execução e resultado observado impede que o êxito do protocolo vire autoridade geral. A RFC define estados; a AC emite; o solicitante aceita; o proprietário implanta; partes confiantes avaliam. Nenhuma fase fala automaticamente pelas seguintes.

Primazia do código em execução não quer dizer que aquilo que foi instalado se torna legítimo. Quer dizer que a transição real precisa ser comparável à regra. Se o cliente reduz accepted e grantedWithMods ao mesmo verde, a implementação destrói informação que o protocolo oferecia.

Não é preciso proibir modificações nem colocar uma pessoa diante de todo certificado. Um perfil pode autorizar transformações previsíveis, o avaliador pode bloquear deltas incompatíveis, exceções podem ter responsável e vencimento, e implantação pode continuar separada. A automação segura decide o conteúdo real, não a cor da resposta.

Fontes