Resumen

  • SCVP puede responder sobre el estado conocido de un certificado en un momento pasado, y RFC 5276 puede acompañar la ruta y la información de revocación con pruebas de conservación a largo plazo.
  • Una revocación conocida más tarde puede indicar una fecha de invalidez anterior al momento consultado; la primera respuesta sigue siendo auténtica, pero deja de ser la conclusión suficiente.

El informe decía que el certificado era válido el día de la firma. Estaba autenticado por el servidor, asociado a la ruta de certificación y acompañado por registros de evidencia que habían sobrevivido a sucesivos cambios criptográficos. Años después apareció una notificación de revocación. Su fecha de invalidez no comenzaba el día de la notificación: retrocedía hasta antes de la firma.

No hacía falta acusar al primer informe de falsificación. Había respondido con el conocimiento disponible. Tampoco bastaba con mostrar su impecable cadena de conservación. La evidencia nueva cambiaba la decisión.

RFC 5055 formula este límite para la validación histórica de SCVP, y RFC 5276 permite observarlo con precisión. El primero consulta una política de validación en un momento de interés. El segundo conserva y relaciona los certificados, rutas y datos de revocación que sostuvieron la respuesta. Juntos pueden producir un expediente duradero. No pueden garantizar que el futuro no aporte un hecho anterior desconocido.

Dos fechas, no una

Una decisión histórica tiene al menos dos ejes temporales. El primero es validationTime: el momento sobre el que se pregunta si el certificado cumplía la política. El segundo es el momento de conocimiento: cuándo entró en el expediente cada CRL, respuesta OCSP, política, ancla o aviso de revocación.

Si sólo se conserva el primer eje, una respuesta afirmativa adquiere una apariencia de eternidad. Si se conserva también el segundo, la organización puede decir algo más exacto: «con la información disponible en esta fecha, el servidor afirmó este estado para aquel momento; esta información posterior reemplazó la conclusión».

RFC 5055 exige que un servidor sin información histórica adecuada responda con error. También advierte que la respuesta histórica puede no reflejar lo más completo que se conozca después. Esa advertencia debe convertirse en una regla operativa: las decisiones antiguas necesitan una vía de supersesión, no una casilla inmutable.

El archive cutoff de OCSP ayuda a describir hasta qué punto se conserva información histórica. Es una pista sobre la capacidad de responder. No es una promesa de que jamás surgirá otra evidencia ni una autorización para ignorar avisos posteriores.

RFC 5276 conserva piezas concretas

SCVP permite que el cliente pida información adicional mediante WantBacks. RFC 5276 añade solicitudes de EvidenceRecord para el certificado final, la ruta completa, una ruta parcial y los objetos de revocación.

La relación no es decorativa. Para pedir evidencia de una ruta, el cliente debe pedir también la ruta. La respuesta debe incluir ambos elementos. En una ruta completa, el EvidenceRecord se calcula sobre el CertBundle DER devuelto. Para un certificado individual, cubre el valor exacto del certificado. Para la revocación, cada CRL o respuesta OCSP debe quedar vinculada a una prueba identificable mediante su hash en el primer sello temporal.

La variante id-swb-ers-all devuelve una colección donde cada targetWantBack nombra el tipo de respuesta cubierta. Debe existir correspondencia uno a uno. Esto permite detectar una anomalía que un informe narrativo escondería: la ruta puede estar preservada mientras uno de los datos de revocación carece de prueba, o al revés.

La prueba duradera responde «estos fueron los bytes preservados». La política responde «estos bytes bastaban para esta validación». El seguimiento temporal responde «qué se supo después». Ninguno puede sustituir a los otros dos.

Un vacío no es una revocación

Cuando el servidor no puede ofrecer el EvidenceRecord solicitado, RFC 5276 mantiene el tipo de respuesta y deja el valor vacío. En la colección agregada, omite el campo de evidencia para ese objetivo. Cuando falta el WantBack del dato que debería quedar cubierto, marca la solicitud como no satisfecha.

Esos resultados no son equivalentes a un certificado revocado. Expresan una ausencia de evidencia de conservación o una solicitud incoherente. El estado del certificado tiene su propio resultado bajo la política SCVP.

También se cumple la separación inversa. Un EvidenceRecord perfectamente válido no vuelve bueno un certificado revocado. Sólo demuestra la relación histórica e íntegra con los datos que cubre. La automatización debe conservar esta tabla de dos dimensiones, porque su pérdida convierte una carencia en condena o una prueba en absolución.

La ruta no decide quién debe confiar

RFC 5280 trata el ancla de confianza como entrada del algoritmo. Aplicaciones distintas pueden partir de anclas diferentes e imponer restricciones adicionales. La construcción de una secuencia de certificados y la aceptación de esa secuencia para un uso concreto no son el mismo acto.

SCVP hace explícitos la política, el tiempo, las anclas, los usos de clave y los parámetros de revocación. Un cliente puede aceptar valores predeterminados del servidor, pero si quiere demostrar más tarde cuál fue la política completa debe conservarla por valor o mediante una referencia estable con sus parámetros.

RFC 5276 exige además verificar la firma de la respuesta SCVP con una clave en la que confíe quien la usa. Las anclas incluidas en la respuesta pueden ayudar a verificar capas internas de ERS, pero el destinatario puede ignorarlas y emplear anclas externas. Una respuesta no firmada no convierte en fiables las anclas que transporta.

Por eso una ruta preservada puede ser rechazada con razón por otro destinatario. No existe contradicción mientras cada uno declare su política. La portabilidad consiste en trasladar evidencia verificable, no en obligar a todos a adoptar la decisión original.

La ruta parcial crea una deuda de reconstrucción

RFC 5276 permite preservar la ruta desde la autoridad emisora hasta el ancla, dejando el certificado del firmante dentro del documento archivado. Esto evita repetir el mismo tramo para muchos documentos de una época.

El ahorro de almacenamiento crea trabajo futuro. Hay que verificar que el certificado final realmente estaba cubierto con el documento, que la firma del documento corresponde a su clave, que el emisor conecta con la ruta parcial, que la información de revocación pertenece al intervalo correcto y que la política acepta el conjunto.

Una colección puede conservar todos sus ficheros y perder la capacidad de ensamblarlos. El identificador del documento, el hash, la firma, el certificado final, la ruta parcial, el EvidenceRecord, la política y la decisión de la aplicación deben formar una cadena explícita. La proximidad en una carpeta no prueba la relación.

Conservar la prueba exige renovarla

ERS usa sellos de archivo y, cuando conviene, árboles de Merkle. Antes de que el algoritmo de firma o el certificado del servicio de tiempo deje de ser aceptable, un nuevo sello cubre el anterior. Si el hash del árbol se debilita, se inicia una nueva cadena que cubre pruebas previas y datos archivados.

La conservación es, por tanto, una secuencia de decisiones. Debe conocerse qué algoritmo protegía cada tramo, cuándo se renovó y qué material permite verificarlo. Un archivo que deja vencer el último punto fuerte no puede recuperar el intervalo perdido mediante una renovación tardía sin evidencia adicional.

El campo cryptoInfos puede contener certificados, anclas, datos de revocación o evaluaciones históricas de algoritmos. RFC 4998 señala que ese campo no está protegido por el sello y necesita verificación externa. Resulta útil como contexto, no como autoridad autosuficiente.

Un expediente que admite correcciones

El registro mínimo debe conservar la consulta SCVP, su nonce cuando se use, la política y los parámetros, el instante consultado, la identidad y firma del servidor, las piezas devueltas, el EvidenceRecord exacto de cada pieza, la verificación de la firma del documento y cada información posterior que cambie el resultado.

También debe separar tres verbos: observar, decidir y ejecutar. SCVP observa y evalúa según entradas declaradas. La aplicación decide si esa evaluación basta para un propósito. Otro sistema ejecuta una aceptación, pago, publicación, retención o rechazo. Un estado histórico no demuestra por sí solo que la consecuencia ocurrió ni que estaba autorizada.

Esta separación permite corregir sin borrar. Cuando llega una revocación retroactiva, se conserva el primer informe como evidencia de lo conocido entonces y se añade una decisión supersesora. Cuando cambia una política, se conserva la compatibilidad anterior y se documenta la nueva. La historia queda legible en vez de ser reescrita.