Resumen

  • CTT de RFC 9921 entrega al TSA los bytes codificados del campo de firma; TTC entrega primero el hash de los bytes de la carga útil y firma el token después con COSE.
  • La protección posterior de un token TTC impide alterarlo sin romper COSE, pero no demuestra que la firma ya existía en la fecha del TSA.

La excepción de auditoría tenía una frase demasiado cómoda: «el documento estaba sellado antes de la revocación». Nadie había falsificado un certificado. Nadie había alterado el token. El error estaba en el sustantivo de la frase. Lo sellado antes de la revocación era el contenido; lo firmado podía ser posterior.

El recorrido es sencillo. Una parte obtiene de un TSA un sello de tiempo para el hash de un archivo. Más tarde, incluso tras la revocación de su certificado de firma, incorpora ese token a una cabecera protegida y firma el conjunto COSE. El receptor ve un token anterior y una firma que lo protege. Si trata ambos datos como una sola fecha, convierte la existencia previa de un archivo en existencia previa de la firma.

RFC 9921 se publicó para impedir precisamente esa abreviatura. El estándar del IETF integra tokens de RFC 3161 en COSE_Sign y COSE_Sign1, pero no define un atributo genérico de «documento fechado». Define dos órdenes de construcción con dos algoritmos de verificación y dos consecuencias distintas.

CTT fecha el acto criptográfico; TTC conserva un antecedente

COSE, Then Timestamp (CTT) empieza con la firma. Tras crear el objeto COSE, el solicitante calcula para el TSA el hash del campo signature codificado en CBOR, o del campo signatures si hay varias firmas. El token recibido se incorpora como 3161-ctt, una cabecera no protegida.

La entrada del TSA contiene aquí los bytes de la firma, no una descripción de su contenido. Por eso CTT puede sostener una conclusión histórica sobre la firma: una vez verificadas la firma COSE, el token, el TSA y la política pertinente, hay evidencia de que esos bytes de firma ya existían a la hora emitida por el TSA. RFC 9921 lo usa para firmas de larga duración y para examinar firmas cuando el certificado ya venció o fue revocado después.

Timestamp, Then COSE (TTC) resuelve otro problema. El solicitante presenta al TSA el hash de los bytes de la carga útil, sin el envoltorio CBOR y sin una firma que aún no existe. Inserta el token como 3161-ttc en la cabecera protegida y sólo entonces firma COSE la cabecera y la carga útil.

El resultado TTC es muy apropiado cuando se quiere mantener junta una declaración y la evidencia de que sus datos existían antes. En el caso de notarización de RFC 9921, esa combinación permite registrar las partes firmadas de una declaración en un registro append-only sin perder el token en el camino. Pero el token acreditó una huella de carga útil. La firma posterior acredita que el firmante posterior cubrió esa combinación. Un registro de transparencia añade aún otras pruebas: inclusión, consistencia, identidad del emisor y cronología de revocación.

El estándar ordena no interpretar un timestamp de carga útil en cabecera protegida como prueba del momento de creación de la firma. No es un consejo de estilo. Es la barrera contra aceptar una firma generada después de que la clave dejó de ser aceptable.

La cabecera no cuenta toda la historia

La palabra «protegida» suele inclinar una decisión humana antes de que el validador haya terminado. En TTC esa protección significa algo exacto: la firma COSE posterior cubre el token y la carga útil. No afirma que el token cubrió la firma anterior, porque no hubo tal firma cuando el TSA recibió la huella.

CTT parece inverso: su token está en una cabecera no protegida. Ello responde al orden real de los hechos. El TSA sólo puede devolver el token después de recibir la huella de la firma ya producida; aquella firma no puede proteger retroactivamente el token. RFC 9921 advierte por tanto que un atacante puede quitar o sustituir la cabecera CTT. La asociación necesita protección de integridad durante el transporte y en reposo.

Un diseño responsable no oculta esa dependencia. Conserva el objeto completo y su hash, el mecanismo de custodia, el modo, los bytes exactos usados para el MessageImprint, el certificado y la política del TSA, y la evidencia de validación de estado. Si el token CTT desaparece de un archivo, el sistema ha perdido la prueba temporal; no ha conservado un resultado verde con menos información.

Validar alcance antes de autorizar una consecuencia

RFC 3161 tampoco concede una confianza automática a un reloj ajeno. El cliente debe comprobar el estado de la respuesta, la identidad y el certificado del TSA, la huella, el OID del algoritmo, la puntualidad mediante tiempo local confiable o nonce, el estado del certificado del TSA y la aceptabilidad de la política. El genTime es el momento de emisión por el TSA; la exactitud declarada, la resolución y la latencia delimitan la lectura que puede hacerse.

Sobre ello, RFC 9921 exige recalcular la huella embebida con los bytes que corresponden al modo. Para CTT, el campo de firma. Para TTC, los bytes de carga útil. Una comprobación de CMS sin esa comparación no establece el enlace requerido. Una comparación correcta sin política de revocación tampoco autoriza una decisión empresarial.

La pregunta operativa debe escribir el sujeto de cada frase: ¿qué existía?, ¿quién lo firmó?, ¿cuándo quedó cubierto por el TSA?, ¿bajo qué política era fiable ese TSA?, ¿qué regla de revocación se ejecutó?, ¿quién decidió aceptar el artefacto y qué efecto se observó? La lectura de Heng Lu sobre código en ejecución y capas de realidad evita que una etiqueta de producto salte esas etapas. Un formato válido, una prueba criptográfica y una aceptación con efecto son registros diferentes.

Sources