Resumen

  • RFC 9246 exige que un token generado para redirección CDNI conserve los valores exp y nbf presentes. Tampoco permite añadirlos si el token recibido no los contenía.
  • El emisor, la fecha de emisión y el contexto de ruta pueden cambiar. Una firma nueva no convierte la antigüedad del objeto firmado en un nuevo período de autorización.
  • La renovación de tokens de segmentos se activa expresamente y calcula el próximo vencimiento desde el momento de verificación y el intervalo previsto, no desde una redirección cualquiera.
  • El vencimiento es opcional en un token individual del perfil. Los requisitos de admisión, la confianza en claves y la ejecución real de controles siguen siendo esenciales.
  • Los ejemplos temporales son analíticos: no describen un fallo reproducido de una CDN, una tasa de incidentes ni un respaldo universal de implementaciones.

Dos tiempos que un panel puede confundir

Un panel muestra un token emitido hace apenas un instante. La firma es válida y el destinatario reconoce al emisor. Todo parece indicar que el acceso acaba de comenzar. Pero la fecha de creación de ese objeto y el plazo del permiso que transporta pueden ser distintos.

En una interconexión de redes de entrega, la solicitud cambia de destino porque otra CDN puede atenderla mejor. El nuevo destinatario quizá necesita una firma que se corresponda con su relación de confianza, y una URI que apunte al recurso adecuado. Es razonable producir un nuevo token. No es razonable deducir, solo de esa producción, que se ha concedido otra ventana completa de acceso.

La diferencia es relevante incluso cuando no hay falsificación. Un participante autorizado para firmar puede aplicar una transformación que amplía indebidamente el plazo. La criptografía autentica lo que escribió; no sustituye la regla que limita lo que estaba autorizado a cambiar.

Para la redirección ordinaria, el perfil CDNI define esa regla con claridad: el vencimiento ya presente mantiene su valor. El tiempo consumido recorriendo la ruta no se devuelve al usuario en cada salto.

El alcance concreto de RFC 9246

RFC 9246, publicado en junio de 2022, es un documento IETF de la vía de normalización y tiene el estado Proposed Standard. Describe la firma de URI mediante un perfil de JWT para controlar solicitudes de contenido entre redes cooperantes. También permite escenarios con una única CDN.

No es una certificación de todas las funciones de todos los proveedores. El texto define cómo expresar y verificar determinadas condiciones; el apoyo real y la configuración de cada despliegue deben comprobarse por separado. Tampoco es protección del contenido una vez entregado, ni un sistema para recuperar bytes que ya recibió alguien.

Su conjunto de declaraciones distingue entre obligación de implementar y obligación de incluir en cada token. El contenedor de URI es obligatorio. exp, que expresa vencimiento, y nbf, que establece desde cuándo se acepta el token, son opcionales en un objeto individual.

Esto no permite ignorar exp cuando aparece. Obliga a soportar y ejecutar el control aplicable. Pero tampoco garantiza que toda autorización original traiga un límite temporal. Un servicio que lo necesita debe explicitar esa condición de admisión.

La distinción impide atribuir a la conformidad una garantía que depende de la política. Si falta un campo que el servicio exige al recibir una autorización original, la operación apropiada es rechazarla u obtener una concesión nueva de quien puede darla. Una redirección no debería reparar silenciosamente el acuerdo creando condiciones que el objeto recibido no tenía.

Conservar el valor cambia la interpretación de «nuevo»

La sección 2.1.4 exige que un JWT producido para redirección CDNI mantenga exp si estaba presente, con el mismo valor. Si no estaba presente, la redirección no puede añadirlo. El verificador debe rechazar la solicitud cuando su momento es igual o posterior al vencimiento, o cuando no soporta la comprobación de un exp recibido.

Para nbf existe una regla paralela de conservación. Un valor presente se mantiene; uno ausente no se incorpora durante redirección. La solicitud anterior a nbf se rechaza. La igualdad satisface esa condición de inicio, mientras que la igualdad con exp ya queda fuera de la ventana.

Que no pueda añadirse un vencimiento breve a un objeto sin exp puede parecer poco intuitivo. Sin embargo, la regla acota una transformación concreta. Cambiar la ruta no equivale a convertirse en autor de un acuerdo temporal nuevo, aunque el nuevo límite parezca más restrictivo.

El contrato local puede exigir un exp original antes de aceptar tráfico. La obligación se aplica en esa frontera de admisión, no inventando otro campo al reenviar. Una autorización nueva obtenida por separado puede tener su propio plazo, pero debe identificarse como otra concesión, no como la simple continuación de la anterior.

Así, «nuevo token» describe un objeto firmado nuevo. No dice por sí mismo si se trasladó un permiso, se renovó una continuidad delegada o se concedió una autorización original independiente.

Qué puede cambiar durante el relevo

El perfil permite cambios de contexto que hacen útil la redirección. Si iss estaba presente, se conserva como declaración, pero su valor identifica a la CDN que firma el nuevo objeto. Si estaba ausente, puede incorporarse. El siguiente verificador necesita una correspondencia confiable entre emisor aceptado y clave, y debe comprobar que coincide con la firma.

Si iat estaba presente, su valor se actualiza al momento de generación del nuevo JWT; también puede añadirse cuando faltaba. aud puede adaptarse a una identidad configurada de la cadena que vaya a procesar la solicitud. El contenedor de URI puede ajustarse a la dirección redirigida.

Estas posibilidades no convierten todas las declaraciones en parámetros libremente modificables. Un iat reciente y un exp antiguo pueden formar un token de redirección perfectamente correcto. El primero describe la emisión del nuevo envoltorio; el segundo conserva la condición temporal del acceso.

JWS proporciona mecanismos de integridad. Las buenas prácticas de JWT añaden controles de algoritmo, emisor, audiencia y contexto. La revisión debe aplicarlos, pero también identificar la operación que justificó los cambios. Una firma válida no prueba una facultad ilimitada de prolongación.

La distribución de claves y el establecimiento de confianza no quedan completamente resueltos por el perfil. Una clave pública permite verificar sin firmar. Una clave simétrica compartida da a su poseedor capacidad para generar tokens. El perfil conserva esta posibilidad por compatibilidad, pero no la recomienda. Incluso con claves asimétricas, el alcance de una autoridad de firma confiable exige una decisión explícita.

Una ruta de tres momentos

Consideremos una cronología hipotética. La autorización original vence en el tiempo sesenta. Una CDN redirige en diez y otra lo hace en veinte. Cambian emisores, fechas de emisión y direcciones pertinentes, pero los tokens de redirección conservan exp igual a sesenta.

En sesenta y cinco, esa condición de acceso ya no se cumple. Si el segundo nodo sumara sesenta a su fecha veinte y fijara ochenta, habría ampliado el permiso. El resultado podría tener una firma válida y una URI correcta; el error estaría en el significado de la transformación.

Este ejemplo no procede de un experimento sobre un proveedor. Hace visible una diferencia que el texto normativo ya permite comprobar: preservar un instante absoluto no es volver a otorgar una duración desde cada relevo.

También importa la interpretación del verificador. JWT, en general, permite cierta tolerancia por desajustes de reloj para exp y nbf. El perfil CDNI la prohíbe. Un valor copiado correctamente puede aceptarse de manera demasiado amplia si una biblioteca aplica sin distinguir sus valores predeterminados para otra aplicación.

Los sistemas deben sincronizar el tiempo y el perfil recomienda NTP. Elegir una ventana original suficientemente realista para intercambios HTTP y dificultades de red es legítimo. Añadir tolerancia oculta durante la verificación es otra decisión. Coordinar relojes no reembolsa la demora del recorrido.

Por qué existe una renovación separada

La entrega segmentada plantea un problema diferente. Un reproductor puede cambiar de representación o buscar otra posición; no siempre se sabe qué segmento pedirá después. Firmar de antemano todas las URI con una validez que cubra toda la reproducción puede abrir una ventana innecesariamente larga.

Signed Token Renewal permite que, después de verificar correctamente una solicitud y entregar un segmento, la CDN proporcione un token para acceso posterior a recursos relacionados. La regla utiliza cdniets, un intervalo que se suma al momento de verificación para determinar el próximo exp. Requiere también cdnistt, que especifica el transporte.

Una verificación en cincuenta y cinco con intervalo treinta puede producir vencimiento ochenta y cinco. Esa aritmética ilustra una renovación expresamente activada. No explica ni autoriza que la redirección ordinaria de un token con exp sesenta lo cambie a ochenta y cinco.

El transporte puede estar desactivado, utilizar cookie o emplear la consulta. El valor cero significa que no está activado; cuando no se quiere renovar, el perfil recomienda omitir el par de declaraciones de renovación. No debe deducirse una facultad de continuidad solo porque el componente puede emitir una firma.

Una ventana móvil entre segmentos tampoco define automáticamente el límite absoluto de un programa o de una elegibilidad. Si el servicio necesita ambos, debe acordar dónde se ejecuta la condición adicional. Es una decisión de política y delegación, no una nueva declaración registrada que esta investigación invente.

La autonomía de la CDN sigue siendo útil. Puede verificar y renovar localmente dentro del acuerdo sin consultar cada segmento al proveedor. Lo que no puede hacer es llamar renovación a cualquier objeto recién firmado para justificar una ampliación no prevista.

Asociar el transporte no amplía los recursos

La profundidad cdnistd relaciona un token posterior con un subconjunto de rutas para su transporte. La ausencia equivale a cero; cero puede hacer que el cliente lo envíe para cualquier ruta. Esto no elimina las restricciones del contenedor de URI.

Las limitaciones de cookies entre dominios pueden exigir transporte mediante consulta. El proceso descrito de renovación supone manifiesto y segmentos en el mismo dominio, con redirección entre dominios al recuperar el manifiesto. La comodidad de una cookie no establece autorización para destinos ajenos.

Para verificar el contenedor se utiliza la URI solicitada sin el paquete de firma y en forma codificada por porcentaje. Cambiar la dirección para llegar al recurso autorizado no es ensanchar un patrón para incluir recursos adicionales. Un contenedor comodín con pocas condiciones puede convertirse en una credencial excesivamente amplia; el perfil desaconseja ese caso.

La revisión tiene que distinguir estas capas. Dónde se presenta un token, qué recurso abarca, quién puede verificarlo y cuándo termina su condición temporal no son la misma pregunta.

Una firma visible no demuestra el control

Las interfaces CDNI permiten trasladar requisitos de distribución y seleccionar un destino capaz de aplicarlos. La configuración de URI Signing incluye enforce, verdadero por defecto. Cuando es falso, el destino no verifica el token aunque la URI lleve una firma.

Por eso, observar una dirección firmada no acredita que las comprobaciones se ejecutaron. Puede existir una configuración deliberada que no las active, o una discrepancia con el acuerdo esperado. No se ha investigado aquí ningún despliegue para afirmar uno u otro caso.

Una lista de emisores vacía tampoco significa aceptar a cualquier emisor de Internet. Permite los del almacén de claves confiables. La selección geográfica y el anuncio de capacidad del destino no sustituyen la prueba del tratamiento de una solicitud concreta.

jti añade otra dependencia. Si aparece, la redirección conserva su valor y no lo introduce si faltaba. El perfil exige soporte de almacenamiento y rechazo del uso repetido para el mismo contenido. El identificador solo no evita repetición: la retención, el ámbito del contenido y la limpieza cuentan.

Sin exp, una memoria limitada de uso reciente puede permitir finalmente la reutilización de valores. Un identificador compartido no crea automáticamente una memoria coordinada entre todas las CDN. La firma nueva tampoco borra una utilización anterior.

La observación de controles y causas de rechazo mediante las extensiones de registro puede ayudar a reconstruir decisiones, evitando exponer tokens utilizables o datos personales. Un indicador de éxito no prueba todas las comprobaciones. La evidencia disponible es el protocolo publicado, no una frecuencia de errores medida.

Fuentes