Resumen

  • RFC 9919 obliga a incluir nextUpdate: si falta, el cliente rechaza; si su hora actual ya lo superó, rechaza la respuesta como obsoleta.
  • La firma acredita el origen autorizado y la integridad del contenido OCSP, no los encabezados HTTP ni una extensión indefinida del estado good.
  • La prueba operativa necesita conservar la respuesta, el reloj y su tolerancia, el recorrido por cachés, la política del validador y la decisión final de la aplicación.

La caducidad que no rompe la firma

Hay un momento incómodo en toda comprobación de revocación: una respuesta puede ser genuina, estar intacta y haber perdido su valor para decidir. No hace falta que alguien la falsifique. Basta con que el tiempo firmado se agote.

RFC 9919 diseña un perfil OCSP para entornos con volúmenes muy altos o con recursos limitados. Admite respuestas producidas con antelación, mensajes pequeños, caché en el cliente, caché en la red y entrega junto a otro protocolo. Ese diseño reduce tráfico y evita que el respondedor tenga que fabricar una respuesta para cada conexión.

La escalabilidad no descansa en una confianza difusa en la caché. Descansa en tres momentos expresos. thisUpdate indica cuándo el respondedor sabía que el estado era correcto. producedAt registra cuándo firmó la respuesta. nextUpdate fija cuándo habrá información más reciente. En este perfil, nextUpdate no es opcional. Sin él no hay aceptación; después de él, la respuesta es obsoleta.

Por eso la firma y la vigencia pertenecen a controles distintos. La firma puede seguir verificándose cuando el certificado ya ha sido revocado y existe una respuesta nueva. Convertir “firma correcta” en “estado actual” elimina precisamente la frontera que permite compartir el objeto sin convertirlo en una autorización perpetua.

good no significa «certificado autorizado»

El protocolo base, RFC 6960, define good, revoked y unknown. La interpretación mínima de good es estrecha: el respondedor no conoce como revocado un certificado con ese número de serie que esté dentro de su periodo de validez. La respuesta no tiene por qué demostrar que el certificado fue emitido. Tampoco sustituye la comprobación de fechas del certificado, la ruta de confianza, la identidad esperada ni la autorización de la aplicación.

Un cliente que acepta una respuesta firmada debe comprobar que se refiere al certificado consultado, que la firma es correcta, que el firmante está autorizado para responder por esa CA y que la información es suficientemente reciente. Solo después puede integrar ese resultado en el resto de la validación.

Decir “pasó OCSP” oculta demasiadas decisiones. No distingue una respuesta de error de un estado definitivo, un firmante legítimo de otro que solo posee una clave válida, una respuesta reciente de una antigua, ni una comprobación de revocación de una autorización de negocio. En un incidente, esa abreviatura impide saber qué control falló.

El cliente aporta una parte de la verdad: su hora

Las respuestas producidas con antelación no encajan bien con un nonce diferente para cada solicitud. RFC 9919 recomienda no incluir normalmente extensiones de solicitud. Incluso si el cliente envía un nonce y la respuesta no lo trae, no debería rechazarla solo por esa ausencia salvo que sepa que el respondedor admite nonces; debe volver a la evaluación temporal.

Eso convierte al reloj local en una entrada de seguridad. El cliente debe determinar que su hora cae entre thisUpdate y nextUpdate. Puede admitir una tolerancia pequeña para diferencias de reloj, elegida según la precisión real de su entorno. No existe una cifra universal inocua.

Un reloj adelantado produce denegaciones antes de tiempo. Uno atrasado puede aceptar un good vencido después de que el certificado haya sido revocado. La telemetría útil debe registrar la hora que usó el proceso, su fuente, su incertidumbre y cualquier salto cercano, no solo que el servicio de sincronización estaba activo.

Esta dependencia también cambia la respuesta ante fallos. Si el estado no puede actualizarse pero la copia firmada sigue dentro de plazo, la decisión es diferente de la que corresponde a un reloj no confiable. En el segundo caso ni siquiera se conoce con seguridad la posición dentro del intervalo.

La envoltura HTTP no firma el contenido temporal

RFC 9919 usa HTTP de manera consciente. Las solicitudes pequeñas deben enviarse con GET para facilitar la caché. La respuesta incluye campos como Date, Last-Modified, Expires, ETag y Cache-Control. max-age puede distribuir las renovaciones para evitar que una multitud de clientes golpee al respondedor al mismo instante. must-revalidate limita la entrega intencionada de contenido viejo.

Pero esos campos no están protegidos por la firma OCSP. Orientan el funcionamiento de la caché. La decisión criptográfica debe basarse finalmente en los valores internos firmados, y una copia nunca debe aceptarse más allá de nextUpdate.

Conviven así dos conceptos de frescura. La frescura HTTP pregunta si una representación puede reutilizarse sin contactar al origen. La frescura OCSP pregunta si la afirmación de estado conserva autoridad. Una caché puede cumplir su cálculo y aun así un validador defectuoso puede olvidar el plazo firmado. También puede ocurrir que un intermediario entregue bytes vencidos; en ese caso el cliente puede intentar una petición que evite la caché, pero la nueva respuesta seguirá necesitando todos los controles.

El grapado en TLS tampoco cambia el autor. El servidor TLS lleva la respuesta hasta el cliente y evita otra conexión. No firma por ello el estado ni amplía su duración. El cliente conserva la decisión final.

Cambiar SHA-1 no borra las demás dependencias

RFC 9919 sustituye al perfil de 2007 y exige SHA-256 a los clientes conformes para los hashes del nombre y de la clave del emisor en CertID. Mantener SHA-1 por compatibilidad prolonga complejidad y superficie de ataque, por lo que la migración importa.

Sin embargo, el algoritmo de identificación no concede actualidad. Una respuesta identificada con SHA-256 puede estar vencida. Una firma moderna puede proceder de un firmante no autorizado para esa CA. Un cliente con reloj erróneo puede tomar una decisión equivocada con datos perfectos. Conviene retirar excepciones antiguas, pero sin convertir la modernización criptográfica en una certificación de toda la cadena.

Un recibo que permita repetir la decisión

El expediente debe guardar la huella y el número de serie del certificado, los hashes de nombre y clave del emisor y sus algoritmos, los bytes completos de OCSP y su huella, el identificador del respondedor, la validación de su cadena y autorización, los campos producedAt, thisUpdate, nextUpdate, el estado y los datos de revocación.

A eso se suma el contexto local: hora usada, fuente e incertidumbre, tolerancia, tratamiento del nonce, versión y política del validador, motivo final de aceptar o rechazar y acción de la aplicación. Los encabezados HTTP, el nodo de caché, la edad declarada, el ETag, el intento de evasión y el resultado de la nueva consulta deben conservarse como prueba de entrega, no de estatus.

La separación es sencilla: HTTP cuenta cómo llegaron los bytes; OCSP firmado cuenta qué afirmó un respondedor autorizado y hasta cuándo; el registro local cuenta por qué se tomó una decisión; la aplicación cuenta qué efecto tuvo. Si el sistema solo guarda “éxito”, pierde las cuatro cosas.

Sources