Resumo

  • A RFC 3125 exigia um OID de política e um hash da especificação definitiva ligados ao processo de assinatura, para que o verificador soubesse quais bytes e regras aplicar.
  • Assinatura e hash corretos não encerravam a decisão: período, compromisso, certificados, revogação, tempo, atributos, algoritmos, reconhecimento institucional e resultado continuavam separados.

A transação era maior que a conta criptográfica

Uma assinatura pode mostrar que certos bytes verificam sob uma chave e um algoritmo. Um contrato ou pedido pergunta mais: o certificado era aceitável para esse uso? A assinatura ocorreu no período permitido? Expressava aprovação ou recebimento? Quais provas de revogação, tempo e função eram obrigatórias?

Publicada como Experimental em setembro de 2001, a RFC 3125 chamou esse conjunto de signature policy. A política definia regras de criação e validação sob as quais a validade podia ser decidida. Um contexto jurídico ou contratual poderia reconhecê-la. O RFC não produzia esse reconhecimento sozinho.

Policy Issuer, Signer, Verifier, Arbitrator e prestadores de confiança mantinham papéis distintos. O emissor definia requisitos; o assinante se comprometia com a política referenciada; o verificador a aplicava; o árbitro podia repetir a análise. Usar o mesmo artefato não unificava suas autoridades.

O OID apontava para a regra, sem virar a regra

A política precisava ser identificável por Object Identifier, ter uma especificação e possuir uma forma definitiva com codificação binária única. O assinante fornecia o hash dessa forma e o verificador o conferia.

O OID escolhia a identidade; o hash fixava os bytes. A estrutura ASN.1 opcional e DER tornavam a versão processável determinística. Assim, um nome informal não podia esconder silenciosamente edições diferentes.

Mesmo assim, OID não era selo de aprovação. A igualdade do hash mostrava que os lados usavam o mesmo livro de regras. Não mostrava competência do emissor, execução de procedimento externo nem reconhecimento por parceiro ou tribunal. Por isso a política também precisava ser legível por pessoas.

Validade ganhou parâmetros explícitos

A política continha signing period, common rules e commitment rules. Fora do período, uma assinatura matematicamente correta podia falhar à regra de criação.

Regras comuns cobriam deveres, confiança de certificados, timestamps e atributos, algoritmos e extensões. Regras de compromisso adaptavam condições a aprovação, recebimento ou compromisso implícito na mensagem. Primeiro era necessário selecionar a edição e o compromisso; só depois avaliar o caminho.

Uma cadeia aceitável em um campo podia ser rejeitada em outro. A mesma chave podia cumprir antes de um limite algorítmico e deixar de cumprir depois. “Válida” sem esses parâmetros apagava justamente a decisão que a política tornava explícita.

Serviços de confiança entregavam peças

Autoridades de certificação e registro, repositórios, autoridades de tempo, responders de status e autoridades de atributos podiam apoiar a política. Ela escolhia trust points, caminhos, revogação, timestamps e funções.

Certificado ligava chave e alegação. Status descrevia o certificado em certo tempo. Timestamp atestava existência anterior. Atributo apoiava um papel. Nenhuma peça decidia o compromisso comercial sozinha.

Uma decisão reproduzível precisava guardar respostas, horários, software e regra que consumiu cada evidência. Um simples resultado verde não permitiria ao árbitro reconstruir a validação.

O hash não observava todo procedimento

Alguns requisitos eram testáveis em CMS: atributos, referências e certificados. Outros viviam em guarda de chave, aprovação interna e prática humana. O hash dizia qual regra foi invocada; não demonstrava que cada procedimento ocorreu.

Assim, “válida sob OID X” não significava automaticamente “tinha autoridade”, “a outra parte aceitou”, “houve pagamento” ou “o contrato foi cumprido”. Cada afirmação tinha outra fonte e outro responsável.

Algoritmos colocavam história dentro da política

O documento enfatizou proteção da chave privada e queda da força de algoritmos, recomendando implementações modulares. A política podia limitar algoritmos e tamanhos de chave.

Uma revisão tardia precisava preservar edição, período, timestamps e regra de migração. A retirada posterior de um algoritmo não explicava sozinha o tratamento da assinatura antiga.

A RFC 3126 tratou de formatos de longa duração e a RFC 3161 de timestamp. As RFCs 2630, 2634, 2459 e 2560 formavam o contexto de CMS, S/MIME, PKIX e status; 5280 e 5652 vieram depois. Elas explicam componentes, não provam implantação de RFC 3125.

Experimental não era comprovante de uso

A conformidade exigia processamento segundo a política identificada. Era uma obrigação de participantes conformes, não uma contagem de participantes.

O legado documentado foi uma cadeia verificável: OID, forma definitiva, codificação única, hash, compromisso e confiança. Adoção, interoperabilidade e efeito jurídico exigem outras fontes.

O recibo completo preservaria objeto, assinatura, certificado, OID, política, hash, período, compromisso, caminhos, revogação, tempo, atributos, algoritmos e saída do verificador, seguido do acordo que reconhecia a política. A criptografia fechava a conta; a política dizia qual conta importava.

Fontes

  1. https://www.rfc-editor.org/rfc/rfc3125.txt
  2. https://www.rfc-editor.org/info/rfc3125
  3. https://datatracker.ietf.org/doc/rfc3125/
  4. https://www.rfc-editor.org/rfc/rfc3126.txt
  5. https://www.rfc-editor.org/rfc/rfc2630.txt
  6. https://www.rfc-editor.org/rfc/rfc2634.txt
  7. https://www.rfc-editor.org/rfc/rfc2459.txt
  8. https://www.rfc-editor.org/rfc/rfc2560.txt
  9. https://www.rfc-editor.org/rfc/rfc3161.txt
  10. https://www.rfc-editor.org/rfc/rfc2119.txt
  11. https://www.rfc-editor.org/rfc/rfc5280.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt