Resumen

  • RFC 9919 distribuye respuestas OCSP preproducidas mediante cachés de cliente, proxy y servidor, pero limita los encabezados HTTP a orientación de caché porque no están protegidos criptográficamente.
  • El cliente debe casar la respuesta con el certificado, validar una firma autorizada e interpretar estado, thisUpdate y nextUpdate con un reloj local preciso.
  • good dentro de una ventana fresca es solo evidencia acotada de no revocación; no prueba emisión, validez completa, autoridad de aplicación ni resultado operativo.

La caché ahorra una pregunta, no crea una respuesta

El perfil ligero parte de una restricción económica. Firmar en tiempo real para cada consulta y cada dispositivo no escala igual que una respuesta preparada y reutilizable. RFC 9919, que sustituye a RFC 5019, admite preproducción, mensajes más pequeños, GET para solicitudes cortas y almacenamiento en clientes e intermediarios.

Así aparecen dos relojes de «frescura». HTTP decide si una representación guardada puede volver a servirse. OCSP decide si la afirmación de un respondedor autorizado aún cabe en su intervalo firmado. Expires, ETag y Cache-Control son muy útiles para la primera tarea. No están, sin embargo, dentro de la firma OCSP.

RFC 9919 señala que esos campos pueden manipularse y que solo deben orientar a la caché. La decisión final descansa en los valores de la OCSPResponse firmada. Un hit, por tanto, acredita que el transporte encontró una copia; no que el respondedor haya revisado de nuevo el estado en ese instante.

El intervalo firmado necesita un reloj externo

thisUpdate es el momento en que el respondedor conocía como correcto el estado indicado. nextUpdate marca cuándo, o antes de cuándo, habrá información más reciente. producedAt registra la firma. En una respuesta preproducida, guardar solo uno de los tres impide reconstruir qué se sabía y durante cuánto tiempo se aceptó.

RFC 9919 exige nextUpdate para este perfil. El cliente debe comprobar su presencia y situar la hora GMT actual entre ambas fronteras. Después de nextUpdate, la respuesta es stale. Puede existir una tolerancia pequeña por diferencias de reloj, pero su tamaño pertenece a la política local y depende de la precisión realmente disponible.

Un reloj adelantado rechaza demasiado pronto y convierte la sincronización en caída de disponibilidad. Uno atrasado acepta demasiado tiempo: conserva un antiguo good cuando una respuesta nueva quizá ya diga revoked. Ninguno de esos errores rompe la firma. La comparación es correcta respecto de una hora incorrecta.

El nonce enlaza solicitud y respuesta para limitar replay, pero el perfil ligero prevé el regreso a frescura temporal cuando corresponda. Por eso no basta registrar «firma válida». Hace falta conservar reloj, offset, tolerancia, nonce y ventana como partes de la misma decisión.

max-age reparte el regreso; nextUpdate pone el límite

El perfil ubica max-age después de thisUpdate y antes de nextUpdate. Los clientes comienzan a renovar antes del cierre, mientras el respondedor prepara otra copia. Esa separación evita que todos vuelvan a la vez por un certificado popular.

Es una técnica de tráfico, no una ampliación criptográfica. Un proxy puede cambiar el encabezado mientras el cuerpo firmado permanece idéntico. Aunque el HTTP parezca vigente, el cliente no debe usar la respuesta más allá de nextUpdate. Si un proxy insiste en entregar un objeto vencido, puede enviarse una nueva petición que lo evite. Buscar otra copia no rejuvenece la anterior.

El grapado en TLS mantiene la misma regla. Reduce round trips y puede evitar acceso directo al respondedor, pero el handshake no renueva la prueba. El CertID, el firmante, el estado y el intervalo siguen perteneciendo al objeto OCSP adjunto.

Una palabra positiva con alcance pequeño

successful vive en el nivel de la respuesta y significa que la infraestructura dispone de registros autoritativos para contestar. good, revoked y unknown viven en el resultado de un certificado. Mezclar los niveles convierte una respuesta bien formada en un juicio positivo sobre el certificado.

RFC 6960 limita también good: como mínimo, ningún certificado con el serial consultado y dentro de su periodo de validez está revocado. No garantiza necesariamente que el certificado se emitiera, ni que la respuesta se produjera dentro de la validez del certificado. Camino X.509, nombre, uso y autorización local siguen fuera.

Antes de aceptar, el cliente verifica que la respuesta corresponde al certificado pedido, valida la firma y acredita que el firmante puede responder por esa CA. Un recibo serio guarda CertID, hash, firmante y cadena de autorización, algoritmo, estado individual, producedAt, thisUpdate, nextUpdate, hora comparada, offset, tolerancia y nonce. La parte HTTP conserva age, max-age, Expires, ETag, revalidación y bypass como datos separados. La decisión de la aplicación y el efecto observado vienen después.

RFC 9919 también mueve los hashes de emisor de CertID a SHA-256. Los clientes antiguos que todavía usan SHA-1 por RFC 5019 deben migrar. Contarlos ayuda a gestionar compatibilidad, pero no demuestra frescura ni correcta revocación.

Fuentes