Resumen

  • El servidor podía adjuntar una respuesta OCSP firmada al intercambio TLS. Transportar esa respuesta no le otorgaba autoridad para producirla ni sustituía la verificación del cliente.
  • La reutilización reducía consultas externas, pero exigía controlar la antigüedad de la prueba. Declarar la función en el certificado podía dar significado a su ausencia y, al mismo tiempo, convertir la disponibilidad del estado en un requisito de despliegue.

Dos problemas que suelen confundirse

Un cliente necesita información sobre el estado de un certificado. Puede obtenerla abriendo otra conexión, pero esa conexión cuesta tiempo y depende de un servicio adicional. Recibir una respuesta junto con el certificado resuelve el problema del trayecto. No demuestra, por sí solo, que la respuesta sea reciente o que quien la firmó tuviera autoridad.

Esa distinción explica OCSP stapling mejor que la imagen de un servidor que certifica su propia honradez. El servidor entrega una declaración ajena, verificable. Si cumple las condiciones del cliente, este puede prescindir de una consulta separada. El trabajo no desaparece: alguien debe conseguir, renovar y distribuir las respuestas que acompañarán al certificado.

La firma permite cambiar de mensajero

RFC 6960 exige comprobar la correspondencia con el certificado, la firma, la autoridad del firmante y la actualidad de la información. Puede responder la CA emisora, un respondedor expresamente considerado de confianza o uno designado con la autorización correspondiente. Tener la clave TLS ordinaria del sitio no concede esa capacidad.

El contenido de la declaración también está acotado. good no necesariamente demuestra que el certificado llegara a emitirse. Mucho menos equivale a declarar seguro todo el sitio. El estado no reemplaza la comprobación de la cadena ni los demás requisitos con los que el cliente decide aceptar una identidad.

Por tanto, el diseño no necesita confiar en el mensajero para todo. Necesita que el cliente reconozca una firma autorizada sobre la respuesta pertinente. Una parte interesada puede transportar evidencia sin adquirir el derecho a modificarla.

La historia empezó antes de la revisión de 2011

En junio de 2003, RFC 3546 ya permitía solicitar estado mediante status_request. El servidor podía enviar una respuesta OCSP después de su certificado. Entre las razones figuraban los recursos de redes limitadas, el coste de las listas de revocación y las idas y vueltas que podían evitarse.

RFC 6066, de enero de 2011, describió la extensión en el marco posterior de TLS. Un mensaje separado, CertificateStatus, llevaba la respuesta codificada completa. Fechar aquí el nacimiento del mecanismo borraría su antecedente de 2003.

Cuando la respuesta adjunta bastaba, el cliente no tenía que consultar a un tercero durante esa comprobación. Había una ganancia concreta de privacidad: no se producía esa consulta adicional. No era una promesa de anonimato general ni de desaparición del servicio de estado. Este seguía suministrando el material que el servidor distribuía.

La respuesta puede estar lista, pero no ser nueva

El perfil ligero de RFC 5019, publicado en septiembre de 2007, trató la producción anticipada y la caché como herramientas de escala. Una respuesta podía prepararse antes de la llegada del cliente y reutilizarse. Esa economía dependía de saber hasta cuándo podía aceptarse.

Los campos temporales separan operaciones. thisUpdate identifica cuándo se sabía correcto el estado comunicado; producedAt, cuándo se firmó la respuesta; nextUpdate, cuándo habrá información posterior como máximo. Firmar ahora una observación anterior no la convierte en una observación de ahora.

El perfil ligero requiere nextUpdate y comprobaciones basadas en una fuente de tiempo precisa. OCSP básico permite omitir ese campo; no corresponde convertir una regla del perfil en una obligación universal. Las instrucciones HTTP de caché, que no están protegidas por la firma OCSP, tampoco pueden ampliar por sí mismas la vigencia aceptable de la prueba.

Una respuesta conservada puede ofrecer margen frente a una interrupción temporal del respondedor. Cuando deja de cumplir las condiciones temporales del cliente, ese margen termina. Además, una revocación recién publicada no transforma las copias de una respuesta positiva anterior. Reutilizar información implica admitir una distancia entre conocer un estado y emplearlo.

No adjuntar no significa revocar

La extensión original era opcional. Que el cliente solicitara estado no obligaba al servidor a entregarlo en todos los casos. La ausencia podía deberse a falta de soporte o al interés de ocultar una respuesta inconveniente.

Las consideraciones de seguridad de RFC 6066 contemplaban a un atacante con una clave comprometida que fingiera no soportar la extensión. Si el cliente necesitaba validación OCSP, debía consultar directamente al respondedor o abandonar. Recibir una respuesta que no superaba la comprobación era distinto y obligaba a terminar el intercambio. Ausencia, caducidad, estado desconocido y revocación requieren interpretaciones distintas.

En octubre de 2015, RFC 7633 introdujo una expectativa autenticada mediante la extensión X.509 TLS Feature. Declarar status_request en el certificado daba a los clientes compatibles una base para detectar el incumplimiento. Es el fundamento de lo que suele llamarse Must-Staple.

No imponía una conducta idéntica a todos los clientes. El documento no exigía implementar cada función y contemplaba excepciones de validación por otros medios. Para el servidor, sin embargo, la declaración tenía consecuencias materiales: debía poder cumplirla. Activar un certificado nuevo antes de disponer de su respuesta de estado podía hacer que un certificado legítimo no satisficiera la comprobación esperada. La emisión y la puesta en servicio ya no debían tratarse como el mismo instante.

Otro contenedor, la misma separación

En 2018, RFC 8446 ubicó la información de estado de TLS 1.3 en una extensión dentro de la entrada del certificado correspondiente. Ya no viajaba como el antiguo mensaje separado. El cambio no trasladó al servidor la autoridad de firma.

La aportación histórica de stapling fue permitir que una prueba independiente viajara por una ruta más conveniente. Su límite fue igual de importante: el transporte no determina ni la verdad actual de una afirmación pasada ni la decisión del receptor. Las especificaciones describen esas reglas; no acreditan por sí solas el soporte actual de cada navegador o CA.

Fuentes

RFC 3546, RFC 6066, RFC 6960, RFC 5019, RFC 7633 y RFC 8446. La lectura sobre costes y responsabilidades es un análisis de sus requisitos, no una medición de despliegues.