Resumen

  • ES-T fijaba la existencia temprana de la firma; ES-C registraba las referencias de certificados y revocación; ES-X conservaba o protegía esos datos; ES-A permitía renovar el envoltorio antes de que la protección anterior se debilitara.
  • La longevidad dependía de conservar bytes y valores exactos y de renovar a tiempo. Ninguna etiqueta de formato convertía el sello temporal en verdad, autoridad o validez eterna.

La firma duraba; su entorno probatorio no

Los bits de una firma pueden copiarse sin desgaste. El entorno que permite interpretarlos envejece: caduca el certificado, desaparecen listas de revocación, cambia el servicio de estado, vence la credencial de la autoridad temporal o deja de ser aceptable el algoritmo.

RFC 3126, publicada como Informational en septiembre de 2001, hizo de esa diferencia su problema central. Partía de la firma con política de RFC 3125 y usaba CMS, ESS, certificados X.509, datos de revocación y sellos temporales. No bastaba guardar la firma; había que preservar los elementos que explicaban por qué un verificador la había aceptado.

ES-T fechaba una huella, no el significado

La forma básica ES contenía la firma y sus datos iniciales. ES-T añadía un sello temporal. Si el firmante no lo entregaba, el verificador debía crearlo al recibir la firma o mantener un registro seguro cercano a la primera validación.

RFC 3161 define el alcance: una autoridad temporal firma el message imprint y acredita que el dato representado existía en un momento. No necesita leer el documento. Por eso no prueba que el contenido sea verdadero, que el firmante tuviera poder, que la política se cumpliera completa ni que la operación terminara bien.

La afirmación estrecha servía frente a una clave comprometida después. Un sello anterior podía colocar la firma antes del incidente. Pero el propio sello tenía clave, certificado, política y vida útil. La confianza se desplazaba hacia una nueva evidencia; no se evaporaba.

ES-C congelaba la receta de validación

ES-C se apoyaba en ES-T y añadía referencias al camino de certificación y a la información de revocación utilizada. Así, otro verificador podía saber qué certificados, listas o respuestas sostuvieron la decisión original.

La información completa no siempre estaba disponible al firmar. Podía necesitarse un periodo de gracia para que apareciera el estado de revocación o terminara una suspensión temporal. La evidencia se ensamblaba después de la firma y exigía una responsabilidad de captura.

Una referencia no conservaba el valor. Un repositorio podía desaparecer. X-Long respondía incluyendo los certificados y datos de revocación completos. La diferencia era esencial: un índice permite localizar; un archivo permite verificar cuando ya no existe la fuente remota.

OCSP tampoco emitía un juicio total. RFC 2560 distinguía good, revoked y unknown con tiempos específicos. Guardar una respuesta preservaba un dato de estado, no la autoridad comercial del firmante ni todas las condiciones de la política.

ES-X protegía la historia de las pruebas

ES-X cubría disponibilidad y compromiso posterior. X-Long retenía los valores completos. X-Time-Stamp tipo 1 sellaba ES-C entero; tipo 2 sellaba las referencias de certificados y revocación. Las variantes podían combinarse.

La secuencia temporal tenía consecuencias. Si una clave de certificación era robada años después, presentar hoy una ruta no mostraba por sí solo que esa ruta existiera antes del robo. Una huella temporal sobre la evidencia podía establecer anterioridad, siempre bajo la política de la TSA y la regla de validación aplicable.

Una capa nueva no corregía una captura defectuosa. Si se perdió el contenido, se eligió una ruta equivocada o el sellado llegó después del compromiso, el formato extendido solo preservaba una historia incompleta con mayor detalle.

ES-A convirtió el archivo en mantenimiento

ES-A se ocupaba del envejecimiento de la protección. Antes de que algoritmos, claves o certificados de sellos anteriores fueran débiles, los datos firmados, ES-C y el material ES-X debían sellarse otra vez, si era posible con algoritmos más fuertes o claves más largas. El proceso podía repetirse.

El sello de archivo abarcaba contenido, atributos, firma, primer sello, referencias, valores retenidos, protecciones ES-X y sellos de archivo anteriores. Era una cadena de custodia criptográfica.

No era inmortalidad. El custodio tenía que renovar mientras la capa anterior aún pudiera defenderse. Un hash roto, una clave temporal comprometida sin límite fiable o valores perdidos no se reparaban añadiendo una fecha nueva. RFC 4998 desarrolló después esta lógica para registros de evidencia y distinguió la renovación simple del sellado de la renovación que vuelve a calcular hashes.

También había que conservar los bytes exactos

RFC 3126 advertía que el OCTET STRING firmado debía permanecer igual en cada validación. Una migración podía romper la prueba sin cambiar la apariencia: normalizar saltos de línea, cambiar codificación, perder contenido separado o exportar de nuevo el documento alteraba la entrada criptográfica.

El objeto histórico real era el paquete completo: bytes, firma, atributos, política, ruta, estados fechados, tokens y renovaciones. Guardar solo una vista legible y un campo “válido” eliminaba la posibilidad de reproducir la decisión.

RFC 5126 sustituyó RFC 3126 y conservó la familia como CAdES-T, CAdES-C, CAdES-X y CAdES-A. Esa continuidad demuestra persistencia del diseño, no despliegue universal de su versión de 2001.

La duración repartía el control

El firmante creaba el acto. El verificador capturaba tiempo y datos. Las autoridades de certificación y estado aportaban pruebas limitadas. La TSA fechaba una huella. El custodio conservaba y renovaba. Un árbitro aplicaba después la política y el instrumento contractual o legal externo.

La contribución histórica de RFC 3126 fue hacer visible esa operación. Para que una firma viviera más que su clave había que guardar lo que el primer verificador sabía, incorporar lo que los servicios remotos podían olvidar y renovar antes de que fallaran los supuestos anteriores. La prueba duradera era una cadena en movimiento.

Fuentes

  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