Resumo

  • ES-T fixava a existência inicial da assinatura; ES-C registrava referências de certificado e revogação; ES-X guardava ou protegia esses dados; ES-A permitia renovar o invólucro antes que a proteção anterior enfraquecesse.
  • A longevidade dependia de bytes e valores preservados e renovação tempestiva. O formato não convertia timestamp em verdade, autoridade ou validade eterna.

Os bits duravam mais que o contexto

Copiar uma assinatura digital não a desgasta. Já o ambiente de validação envelhece: o certificado expira, CRLs antigas deixam de circular, o respondente OCSP some, o certificado da TSA vence e algoritmos perdem aceitação.

Publicada como Informational em setembro de 2001, a RFC 3126 colocou essa diferença no centro. Partiu da assinatura com política da RFC 3125 e combinou CMS, ESS, X.509, revogação e timestamp confiável. Guardar apenas o valor da assinatura não bastava; era preciso preservar por que o primeiro verificador a considerou válida.

ES-T datava a existência, não a verdade

ES trazia a assinatura básica. ES-T acrescentava um timestamp sobre ela. Se o assinante não o fornecesse, o verificador deveria criá-lo no primeiro recebimento ou manter um registro seguro próximo da validação inicial.

A RFC 3161 limita a afirmação: a TSA assina um message imprint e indica que o dado existia em determinado momento. Ela não precisa ler o documento. Logo, o token não prova conteúdo verdadeiro, autoridade comercial, cumprimento integral da política ou resultado da transação.

Ainda assim, a ordem temporal era útil. Se a chave fosse comprometida depois, um selo anterior podia situar a assinatura antes do incidente. Mas a TSA também tinha chave, certificado, política e vida finita. A confiança mudou de lugar.

ES-C preservava a receita da validação

ES-C se apoiava em ES-T e acrescentava referências ao caminho de certificação e aos dados de revogação usados. Um verificador futuro poderia identificar certificados, listas e respostas que sustentaram a decisão.

O conjunto completo talvez não existisse no instante da assinatura. Podia ser necessário esperar pela publicação da revogação ou pelo fim de uma suspensão. A evidência era montada por etapas e exigia captura deliberada.

Referência não era valor. Um identificador não impedia que o repositório sumisse. X-Long incluía certificados e dados de revogação efetivos. Era a diferença entre guardar a ficha do catálogo e guardar a obra.

OCSP também respondia a uma pergunta estreita. Na RFC 2560, good, revoked e unknown descreviam estado em um tempo. Good não demonstrava todas as condições do certificado, a autoridade do assinante ou o cumprimento do negócio.

ES-X protegia a evidência da própria evidência

ES-X tratava disponibilidade e comprometimento posterior. X-Long mantinha os valores. X-Time-Stamp tipo 1 selava ES-C inteiro; tipo 2 selava referências de certificados e revogação. As formas podiam ser combinadas.

Se uma chave de CA fosse roubada anos mais tarde, apresentar uma cadeia durante a disputa não mostraria que ela existia antes do roubo. Um timestamp anterior sobre os dados de validação poderia estabelecer essa sequência, conforme a política aplicável.

Uma camada adicional não corrigia uma captura errada. Conteúdo perdido, caminho incorreto ou selo produzido depois do comprometimento continuavam defeitos, mesmo dentro de um contêiner sofisticado.

ES-A transformava arquivo em manutenção

ES-A enfrentava o envelhecimento da própria proteção. Antes que algoritmos, chaves ou certificados de timestamps antigos se tornassem fracos, dados assinados, ES-C e material ES-X deveriam receber novo timestamp, idealmente com algoritmo mais forte ou chave maior. O processo poderia repetir-se.

O selo de arquivo cobria conteúdo, atributos, assinatura, primeiro timestamp, referências, valores retidos, proteções ES-X e timestamps de arquivo anteriores. Formava uma cadeia de custódia criptográfica.

Não era imortalidade. O custodiante precisava renovar enquanto a camada anterior ainda fosse verificável. Hash quebrado, chave TSA comprometida sem limite temporal confiável ou valores perdidos não eram reparados por um token novo. A RFC 4998 depois distinguiu renovação de timestamp e renovação com novo hash em registros de evidência gerais.

O byte exato também precisava sobreviver

A RFC 3126 exigia o mesmo OCTET STRING em toda verificação. Migração de arquivo podia quebrar a prova sem mudar a aparência: normalizar quebras de linha, trocar codificação, perder conteúdo destacado ou reexportar o documento alterava a entrada criptográfica.

O objeto histórico era o pacote completo: bytes, assinatura, atributos, política, cadeia, status datado, tokens, valores e renovações. Guardar só uma visualização legível e um campo “válido” eliminava a reprodução da decisão.

A RFC 5126 substituiu a RFC 3126 e manteve CAdES-T, CAdES-C, CAdES-X e CAdES-A. A continuidade comprova a persistência do desenho, não implantação universal da versão de 2001.

Longa duração distribuía responsabilidade

O assinante controlava o ato. O verificador capturava tempo e dados. CAs e serviços de estado forneciam evidência limitada. A TSA datava o imprint. O custodiante conservava e renovava. O árbitro posterior aplicava política e instrumento jurídico ou contratual externo.

A contribuição histórica da RFC 3126 foi tornar essa operação visível: registrar o que o primeiro verificador sabia, trazer para dentro o que serviços remotos poderiam esquecer, proteger a evidência contra comprometimento futuro e renovar antes da queda das premissas. A prova só ultrapassava a chave porque permanecia em movimento.

Fontes

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