Resumen

  • RFC 9674 exige que las referencias a Snapshot y Delta y las redirecciones HTTP permanezcan en el origen de la notificación RRDP: mismo esquema, host y puerto.
  • El resultado terminal de una descarga no basta para auditar la sesión; hay que conservar cada destino intermedio y la decisión de origen tomada antes de seguirlo.
  • Superar esa prueba solo autoriza la recuperación. Formato, sesión, serial, hashes, certificados, CRL, manifiestos, objetos firmados, cache validada, router y política local continúan separados.

El informe mostraba tres datos: 200, tiempo de descarga y hash correcto. Con ellos, la migración parecía impecable. Lo que no mostraba era que la petición había empezado en el host anunciado por el certificado y había terminado, tras una redirección, en otro origen.

Según RFC 9674, ese salto no es un detalle de transporte. La parte que confía —el Relying Party— no debe seguirlo. Si lo encuentra al descargar la notificación, un Delta o el Snapshot, debe rechazar la sesión y dejar de usar RRDP para esa operación.

El dato descartado era la decisión

RFC 8182 organiza RRDP alrededor de una notificación localizada por rpkiNotify en el SIA de un certificado de recursos. La notificación declara un session_id, un serial, un Snapshot y, si existen, Deltas. Los hashes enlazan el índice con los archivos recuperados.

El diseño original no decía de manera explícita que esas URI debieran pertenecer al mismo origen, ni qué hacer si una respuesta HTTP enviaba al cliente a otro. RFC 9674 añade ambas obligaciones. El servidor debe publicar referencias con el mismo esquema, host y puerto que la notificación y no debe redirigir fuera. El cliente debe comprobarlo, rechazar y registrar el evento.

RFC 6454 explica por qué un nombre empresarial no entra en la comparación. Un origen es una protección definida por URI. http y https no son iguales aunque el host coincida. Dos hosts distintos no son iguales aunque compartan propietario o certificado. Dos puertos distintos tampoco son el mismo servicio autorizado.

La consecuencia para la observabilidad es incómoda: guardar solo el estado final elimina el hecho que decidió la conformidad. Un registro defendible necesita la URI SIA exacta, el origen normalizado, las referencias del XML, cada código y Location, y el resultado de cada comparación.

El hash no otorga permiso

El RFC 9110 define la redirección como una acción posterior hacia otra URI. Un cliente puede automatizarla, pero automatizar no significa autorizar. RFC 9674 limita esa automatización con el principal nombrado por la notificación.

Puede ocurrir que el servidor alternativo entregue exactamente los bytes cuyo hash figura en el XML. La integridad del archivo responderá «sí». La autoridad de recuperación seguirá respondiendo «no». El motivo de seguridad incluye el consumo de recursos: sin el límite, un repositorio podría hacer que numerosos validadores solicitaran archivos a otro servidor y trasladar allí la carga.

La prueba de contenido tampoco sirve al revés. Estar en el mismo origen no garantiza que el hash coincida, que el XML sea válido o que la serie avance correctamente. Origen y contenido protegen superficies distintas.

La sesión RRDP todavía tiene trabajo

Después de aceptar el origen, RFC 8182 exige verificar la forma de la notificación, su esquema, la combinación de ubicación y sesión, la cadena de Deltas y los seriales. El Snapshot y cada Delta deben coincidir con el hash anunciado. Los Deltas rechazados pueden obligar a usar el Snapshot; si este se rechaza, RRDP ya no puede continuar.

La alternativa indicada en el SIA puede permitir otro mecanismo de repositorio. Ese cambio no convierte la sesión fallida en válida. Crea un nuevo camino de adquisición que debe conservar sus propios recibos.

Y aun después de una sincronización impecable, faltan las decisiones criptográficas. RFC 6480 separa certificados de recursos, objetos firmados y repositorios. RFC 6487 define certificados, CRL y validación de caminos. RFC 9286 obliga a examinar el número, los tiempos y el inventario de nombres y hashes del manifiesto.

Por eso un Snapshot del origen correcto puede contener objetos que la validación descarta. También puede conservar material antiguo dentro de una sesión coherente. La palabra «mismo» en same-origin describe al principal de recuperación, no la actualidad semántica del repositorio.

Del cache validado al tráfico hay otra frontera

RFC 7115 distingue el cache validado: objetos que el RP realmente verificó. RFC 8210 añade la distribución de payloads a routers mediante versión, sesión y serial propios. RFC 6811 produce estados de validación de origen que una política local puede usar, rechazar o ponderar.

No existe una flecha automática desde same-origin=true hasta «tráfico correcto». La cadena incluye recuperación autorizada, integridad RRDP, validación RPKI, emisión de payload, ingestión del router, política de ruta, selección y observación del tráfico. Cada afirmación necesita sujeto, versión y hora.

Esto cambia también el lenguaje de incidentes. Un evento cross-origin demuestra una incompatibilidad normativa. No demuestra por sí solo un ataque ni una cuenta comprometida. Un evento same-origin demuestra que no se cruzó ese límite. No demuestra honestidad del servidor, validez del objeto o efecto sobre BGP.

La medición de 2024 conserva fecha y alcance

RFC 9674 examinó archivos históricos. En el periodo citado no observó URI cross-origin en las notificaciones, y encontró un servidor con redirección same-origin en otra ventana de 2024. Ese resultado justificó que la nueva regla no rompía una práctica común observada entonces.

No autoriza una cifra de despliegue para 2026. La muestra, las fechas y el objetivo deben acompañar la afirmación. Repetir «cero observado» sin ellos convertiría evidencia histórica en garantía universal.

La gobernanza interna debe ser igual de precisa. Un cambio de CDN, puerto o nombre que altera el origen es una modificación de protocolo aunque el archivo permanezca igual. La prueba previa debe recorrer todos los saltos y no solo comparar el objeto final.

La especificación inicial mínima ofrece la lectura correcta: una restricción común pequeña y verificable, sin apropiarse de todas las decisiones futuras. Las capas de realidad separan organización, URI, bytes, validación y resultado. La primacía del código en ejecución exige, finalmente, observar el RP, el cache y el router que hicieron el trabajo.

El éxito de RFC 9674 no consiste en afirmar que una fuente es verdadera. Consiste en impedir que una notificación amplíe en silencio quién puede actuar como su fuente.

Fuentes