Resumen

  • Un staple OCSP es una afirmación firmada sobre un CertID y unos tiempos concretos. La firma acredita la autoridad del respondedor, no que conociera todo evento posterior ni que produjera la respuesta para esta conexión.
  • producedAt, thisUpdate y nextUpdate no son sinónimos. A ellos se suman la recogida, la edad HTTP, la instalación, el reloj del cliente y su edad máxima aceptable.
  • TLS transporta la evidencia; el cliente decide. Para justificar la aceptación hay que conservar identidad, delegación, estado, tiempos, linaje de caché, posición en la cadena, Must-Staple y la política de fallo.

La respuesta que cruzó el momento de revocación

El respondedor firmó good a las 09:55 y el servidor lo almacenó a las 09:57. La revocación llegó diez minutos después. El cliente recibió los mismos bytes a las 10:11.

La firma, thisUpdate y nextUpdate superaban sus controles. Ninguno podía incorporar retrospectivamente un evento posterior. Llamarlo fraude confundiría autenticidad con actualidad; llamarlo “revocación comprobada” atribuiría a una sola luz verde la autoridad separada del emisor, respondedor, caché, TLS y cliente.

CertID y firma limitan lo que se afirma

CertID reúne los hashes del nombre y la clave del emisor, el número de serie y el algoritmo. Una respuesta impecable para otro serial responde a otra pregunta. Un staple de la hoja tampoco cubre por sí solo un intermediario.

RFC 6960 da a good un significado mínimo: no consta revocado un certificado vigente con ese serial. No demuestra necesariamente que se emitiera ni que el respondedor ya haya ingerido cambios posteriores a thisUpdate.

La respuesta definitiva debe firmarla el emisor o un respondedor expresamente autorizado para OCSP. Una firma matemáticamente correcta de una clave sin delegación carece de autoridad. Una firma autorizada puede representar una vista anterior. Por eso deben guardarse CertID, posición de cadena, certificado del respondedor, delegación, resultado criptográfico y hash de los bytes.

Los relojes y la caché son parte del control

producedAt fecha la firma; thisUpdate, el último momento en que el estado se conocía correcto; nextUpdate, el límite anunciado para información más nueva. RFC 6960 permite respuestas preproducidas y RFC 9919 diseña su perfil alrededor de caché y nextUpdate.

La operación añade la hora de revocación, ingestión, Date/Age HTTP, obtención, revalidación, instalación, handshake y reloj cliente. La tolerancia de desfase no es frescura gratuita. Un thisUpdate demasiado futuro, un nextUpdate vencido o una edad local excesiva son fallos distintos.

El caché reduce latencia, protege privacidad y evita poner al respondedor en cada handshake. Date, Expires, ETag y Cache-Control gobiernan reutilización; su vida debe terminar antes que la frontera OCSP. El servidor debe registrar origen, cabeceras, hash, adquisición, revalidación, instalación y plazo de renovación.

Un staple válido cargado al arrancar deja de ser un control si el proceso de renovación se detiene.

Nonce, TLS y Must-Staple no dicen lo mismo

El nonce OCSP enlaza petición y respuesta. Un staple compartido entre miles de clientes normalmente no puede contener el nonce nuevo de cada uno. Su vigencia depende del intervalo firmado, una edad máxima y la renovación, no de haber sido creado para este handshake.

En TLS 1.2 y anteriores, el cliente ofrece status_request y el servidor puede responder con CertificateStatus; TLS 1.3 asocia estado a entradas de certificado. La asignación IANA identifica el mecanismo, no prueba negociación ni aceptación.

La presencia tampoco prueba validez. BoringSSL entrega bytes no garantizados como bien formados; OpenSSL separa petición, instalación y lectura. La ausencia puede significar falta de solicitud, sesión reanudada sin certificados, rechazo del servidor o fallo suave.

Must-Staple impide omitir silenciosamente un estado exigido: el cliente puede rechazar si no llega. No todos los clientes lo aplican igual y una respuesta presente aún puede fallar por CertID, delegación, firma, tiempo, unknown o revoked.

Cadena, reanudación y código en ejecución

TLS anterior a 1.3 suele portar una respuesta para la hoja; TLS 1.3 puede asociar varias a la cadena. La posibilidad no demuestra cobertura completa: hay que conservar cantidad y posición. En una reanudación sin intercambio de certificados, OpenSSL no invoca el callback de estado; no debe contarse como nueva observación.

OpenSSL separa búsqueda del CertID, extracción de estado, comprobación temporal con desfase/edad máxima y verificación del firmante. GnuTLS integra OCSP y Must-Staple, pero obliga a renovar y a veces a sustituir credenciales activas. BoringSSL aconseja obtener y refrescar antes del handshake, no bloquearlo con red.

Las pruebas negativas deben usar serial incorrecto, firmante no autorizado, thisUpdate futuro, nextUpdate vencido, respuesta antigua sin límite, bytes dañados, staple obligatorio ausente, cadena parcial y sesión reanudada mal contabilizada. Al detener la renovación, la alerta debe preceder al rechazo. Al caer el respondedor, un caché aún aceptable debe sostener el servicio hasta que la política explícita decida lo contrario.

Fuentes