Summary

  • O RFC 10003 padroniza HTTP, arquivo, correio eletrônico e TCP como meios de transporte CMC. O êxito do meio informa a movimentação do envelope, não o resultado da operação de certificação.
  • Código 2XX, mensagem aceita, arquivo presente ou gravação TCP concluída não comprova aprovação da CA/RA, emissão do certificado pretendido nem sua ativação no sistema.
  • Daniel Kade propõe um recibo CMC de transporte à decisão que liga provas limitadas do canal à resposta validada, ao estado pendente, à impressão digital emitida e à observação de implantação, sem guardar segredos.

Quando o caminho termina antes do processo

Em muitos painéis, a solicitação de certificado parece uma chamada comum de API: enviar, receber 200, marcar como concluída. A simplicidade visual esconde uma divisão institucional. Uma infraestrutura transporta a mensagem; uma autoridade de registro ou certificação avalia o pedido; outro sistema instala o resultado.

O RFC 10003 define a primeira função. Ele especifica como mensagens Certificate Management over CMS transitam por HTTP, arquivos, e-mail e TCP. O RFC 10004 exige implementação de HTTP por todas as entidades CMC e deixa os demais mecanismos como opcionais. Isso produz formatos e comportamentos interoperáveis.

O resultado do processo está no RFC 10002. Uma Full PKI Response pode significar sucesso, falha, pendência, resultado parcial, falta de suporte, necessidade de confirmação ou outra ação. Emissão diferida pode exigir mais de uma ida e volta. Assim, o fechamento da conexão ou a recepção de bytes não fecha necessariamente a transação de certificação.

O limite semântico do 2XX

No transporte HTTP, o RFC 10003 determina o uso de POST e de códigos 2XX para respostas bem-sucedidas. Também fixa o corpo binário e o tipo de mídia. Uma Full PKI Request usa application/pkcs7-mime; smime-type=CMC-Request; a resposta completa usa smime-type=CMC-Response. Mensagens simples têm identificadores próprios.

Esses dados sustentam um ótimo recibo de canal: URI, método, instante, status, Content-Type, referência da política TLS e hashes dos objetos. A operação pode demonstrar que um endpoint específico recebeu uma solicitação e devolveu uma resposta com a forma prevista.

O recibo não interpreta a decisão. Uma resposta HTTP 2XX pode carregar um estado CMC failed, pending ou partial. A camada HTTP teve êxito em entregar a resposta, enquanto a camada PKI recusou, adiou ou resolveu apenas parte do pedido.

Também não convém chamar todo não-2XX de rejeição da CA. Proxy, rota, autenticação HTTP ou tratamento do conteúdo podem falhar antes que a lógica CMC examine o caso. Nessa situação, a afirmação correta é “nenhuma decisão CMC observada”.

Pendência cria uma obrigação verificável

O estado pending não é uma promessa genérica de sucesso. PendInfo fornece um token e um horário sugerido para nova consulta, e o solicitante deve voltar. partial mantém abertas as parcelas ainda não atendidas. Quando empregado, o identificador da transação permanece até uma Full PKI Response conclusiva.

O registro inicial precisa, portanto, preservar “entregue e pendente”. A consulta seguinte deve referenciar a mesma transação, o token protegido e uma nova troca de transporte. Se a automação perder o token, não consultar ou receber somente parte de um lote, o sistema não pode usar o decurso do tempo para inventar conclusão.

Reenvios complicam a contagem. POST não é idempotente; por isso o RFC 10003 proíbe 0-RTT nas implementações CMC que suportam TLS 1.3 ou QUIC. Se a resposta se perde, um reenvio pode criar uma segunda entrega. Hash, nonce e identificador de transação ajudam a distinguir repetição operacional, replay e novo pedido autorizado.

Um atalho enganoso para cada transporte

No modo por arquivo, cada objeto deve conter uma única solicitação ou resposta binária e seguir extensões recomendadas. A existência do arquivo prova uma gravação. Mesmo um arquivo de resposta não prova que a assinatura foi validada ou que o conteúdo concede o pedido.

No e-mail, o padrão define encapsulamento MIME, nomes, tipos e exemplos em base64. Um Message-Id, uma aceitação SMTP ou uma entrega na caixa postal pertence à cadeia de correio. O estado CMC continua no corpo. O RFC 10003 ainda alerta que TLS até o primeiro agente de submissão não garante autenticação ou criptografia nos saltos posteriores. REQUIRETLS pode pedir proteção nos relés compatíveis, com risco de não entrega se algum deles não oferecer a extensão.

No TCP, as mensagens seguem em binário sem outro invólucro. O serviço pkix-cmc tem a porta 5318, e o cliente deve aguardar a resposta inteira antes de fazer outro pedido na mesma conexão. Conectar e escrever todos os bytes continua sendo menos do que validar a resposta.

Os canais geram provas diferentes. A regra compartilhada é não permitir que a telemetria do canal declare o resultado institucional.

Proteção de mensagem e proteção de caminho

Estruturas CMS podem preservar integridade, autenticidade e confidencialidade do objeto. HTTPS protege uma conexão; IPsec ou os tipos EnvelopedData e AuthEnvelopedData oferecem outras formas de proteção. Nenhuma delas elimina a necessidade de manter o escopo de cada afirmação.

TLS válido não demonstra que o solicitante tinha autoridade sobre os nomes, que a RA verificou a identidade ou que a CA aceitou o perfil. Um objeto CMS autêntico não mostra sozinho qual endpoint o recebeu, qual tentativa gerou a resposta ou o que ocorreu em cada intermediário.

Além disso, clientes CMC não são obrigados a suportar autenticação HTTP nem cookies; o servidor não pode presumir esses recursos. O início da confiança e a política de emissão permanecem decisões arquitetônicas separadas.

Por isso, “entrega segura” é uma frase insuficiente. É preciso dizer: canal TLS validado, mensagem CMS autenticada, autoridade confirmada, decisão CMC obtida, certificado emitido, impressão digital instalada. Cada verbo pertence a uma evidência.

O recibo CMC de transporte à decisão

Proponho um recibo CMC de transporte à decisão. É uma recomendação de governança de Daniel Kade, não uma exigência do RFC 10003 ou do IETF.

O primeiro bloco registra o meio. Para HTTP: identidade do endpoint, POST, horário, código, tipo de conteúdo, referência da política TLS e hashes limitados. Para e-mail: identificador enviado, destino, estado de repasse observado e eventual escopo de REQUIRETLS. Para arquivo e TCP: canal controlado, direção, tempo e hash. Corpos, credenciais e topologia sensível ficam de fora.

O segundo bloco registra a interpretação da aplicação: solicitação e resposta simples ou completa, identificador de transação, partes às quais o status se aplica e resultado da verificação de proteção. Bytes recebidos, mas não decodificados, deixam a prova na etapa de transporte.

O terceiro preserva cada estado. pending mantém referência protegida ao token, horário de consulta e sondagem que o resolveu. partial separa itens concluídos e abertos. Falhas guardam informação operacional limitada, não o material completo de identidade.

O quarto bloco existe apenas se houve emissão. Ele liga impressão digital, emissor, série, chave pública, nomes e validade ao pedido e à decisão. Não presume a ordem dos certificados da resposta nem confia automaticamente em um certificado autoassinado incluído.

O quinto bloco pertence à implantação. Instalação, ativação e aceitação por uma parte dependente são fatos próprios. Um certificado pode ser emitido corretamente e nunca entrar em serviço, ou o sistema pode continuar apresentando o anterior.

Operar pelo último fato comprovado

Um painel honesto não resume tudo a “matrícula concluída”. Ele mostra “POST aceito”, “resposta CMC validada”, “pedido pendente”, “certificado emitido”, “impressão digital instalada” e “credencial observada em uso”. Cada etapa tem proprietário e prazo.

Os melhores alertas procuram junções quebradas: 2XX com corpo inválido, falha CMC contada como sucesso, token sem consulta, corpo duplicado em transações distintas, certificado incompatível com chave ou nomes esperados, emissão sem implantação e serviço que ainda apresenta a credencial antiga.

A métrica correta usa todas as transações iniciadas como denominador e pergunta qual é o último estágio comprovável de cada uma. Contar somente requisições HTTP verdes recompensa a camada mais rápida e apaga as demais.

O RFC 10003 padroniza as estradas de CMC. Governá-las exige não confundir chegada com aprovação.

Fontes

  1. Lu Heng — Soberania de dados: realidades técnicas e práticas
  2. Lu Heng — Por que a BTW Media existe
  3. Lu Heng — Primazia do código em execução
  4. RFC 10003 — Protocolos de transporte CMC
  5. RFC 10002 — Certificate Management over CMS
  6. RFC 10004 — Requisitos de conformidade CMC
  7. RFC 5273 — Especificação anterior de transporte CMC
  8. RFC 5967 — Tipo de mídia application/pkcs10
  9. RFC 8551 — Especificação S/MIME 4.0
  10. RFC 9110 — Semântica HTTP
  11. RFC 9205 — Construção de protocolos com HTTP
  12. RFC 9325 — Uso seguro de TLS e DTLS
  13. RFC 8446 — TLS 1.3
  14. RFC 9000 — QUIC
  15. RFC 8689 — Opção SMTP REQUIRETLS
  16. RFC 3207 — SMTP seguro sobre TLS