Resumen

  • La migración RPKI poscuántica se justifica como preparación para riesgos, pero no existe una fecha creíble para un ordenador cuántico criptográficamente relevante. La respuesta correcta es una preparación escalonada con evidencia, no una transferencia apresurada de autoridad a la AC o al proveedor que se mueva primero.
  • Los estándares del IETF deberían definir certificados interoperables, entidades firmadas, comportamiento del validador e hitos de transición. Las AC deben implementar estas obligaciones. Ninguno de estos roles otorga a una AC la propiedad de los recursos representados, la clave privada del titular o el derecho a impedir el cambio a otro servicio calificado.
  • RFC 6916 ya trata la migración algorítmica como una transición descendente de varios años con conjuntos de productos paralelos y fechas de preparación definidas. Su estructura es útil, pero una transición cuántica también requiere reglas explícitas contra el bloqueo, equivalencia semántica, degradación, emergencia y reversión.
  • Los estándares ML-DSA y SLH-DSA de NIST proporcionan puntos de partida criptográficos maduros, pero no una selección automática para RPKI. Una propuesta individual del IETF de junio de 2026 perfila ML-DSA-65 para experimentos, registrando honestamente evidencia incompleta de entidades firmadas y validación multiválida.
  • La publicación paralela de RSA y poscuántica debe juzgarse por las semánticas de enrutamiento resultantes, no por una identidad byte a byte. Las divergencias en las autorizaciones de ruta, el estado de revocación o los manifiestos deben ser visibles y nunca fusionarse en silencio en una respuesta improvisada.
  • La custodia de claves controlada o autorizada por el titular debe seguir siendo portátil entre proveedores de hardware y servicios. Las claves no exportables pueden reemplazarse mediante renovación coordinada; no deben convertirse en una excusa para que una AC atrape la relación de certificación.
  • La reversibilidad requiere jerarquías de prueba aisladas, pilotos de producción medidos, retroceso limitado, retiro limpio de claves y un camino de retorno definido en caso de fallo de la nueva suite. Un retroceso clásico permanente se convertiría en un canal de degradación en lugar de una función de seguridad.
  • La NRS debería publicar una carta de migración 2025-2035 que cubra los derechos de decisión, los umbrales de evidencia, la neutralidad del proveedor, el apoyo a pequeños operadores, la respuesta a incidentes, las métricas públicas y la revisión independiente antes de cualquier fecha de producción obligatoria.

El riesgo cuántico es real, pero el cronograma sigue siendo incierto

La preocupación de seguridad es directa. La computación cuántica a gran escala podría hacer vulnerables los algoritmos basados en factorización de enteros o logaritmos discretos de una manera que la computación clásica ordinaria no lo hace. El perfil de producción actual del RPKI utiliza firmas RSA PKCS #1 v1.5 con SHA-256 y claves RSA de al menos 2048 bits. Un ordenador cuántico criptográficamente relevante socavaría la suposición de que solo el titular de la clave privada puede crear una firma RSA válida.

Esta afirmación no proporciona una fecha de implementación. El progreso en hardware cuántico, corrección de errores, estimaciones de recursos y viabilidad técnica sigue siendo incierto. La gobernanza del registro debería resistir dos errores simétricos: declarar la amenaza imaginaria hasta que ocurra una ruptura pública, o tratar cada pronóstico como una razón para un reemplazo inmediato. Las infraestructuras críticas no pueden comenzar una migración global el día que falla una suite antigua, pero no deberían forzar una suite inmadura a producción solo para parecer preparadas.

La urgencia difiere de los datos cifrados de larga duración. Un adversario puede recopilar datos cifrados hoy y descifrarlos más tarde si el texto plano sigue siendo valioso. Las firmas RPKI autorizan principalmente un estado actual o con límite de tiempo, y las partes interesadas obtienen repositorios cambiantes. Eso reduce algo de exposición de 'cosecha ahora', pero no elimina el problema de la transición. Una capacidad futura de falsificar certificados o entidades firmadas podría crear una falsa autoridad de enrutamiento, y un cambio de emergencia apresurado sería especialmente peligroso en un sistema jerárquico.

Por lo tanto, la preparación debe comenzar con un inventario criptográfico, experimentos de implementación, soporte de hardware, mediciones de repositorios, interoperabilidad de validadores y reglas de gobernanza. No debe comenzar con un mandato de proveedor. La pregunta clave para 2025 a 2035 es si el sistema puede evolucionar deliberadamente antes de que RSA deje de ser seguro, manteniendo suficiente flexibilidad para corregir un algoritmo, implementación o cronograma incorrecto.

Los estándares NIST de agosto de 2024 cambiaron materialmente el punto de partida. FIPS 204 define ML-DSA, un estándar de firma digital basado en retículos. FIPS 205 define SLH-DSA, una alternativa sin estado basada en hash. FIPS 203 cubre un mecanismo de encapsulación de claves en lugar de firmas, por lo que es menos directamente relevante para firmar objetos RPKI. El plan de transición de NIST indica la desaprobación y eliminación de estándares vulnerables a lo cuántico para 2035 en su propio contexto de estándares, y se espera que los sistemas de mayor riesgo migren antes.

Estos desarrollos justifican trabajar ahora. No deciden la suite RPKI. RPKI tiene restricciones específicas de certificado, CMS, repositorio, manifiesto, revocación y partes interesadas. Un algoritmo estandarizado y teóricamente seguro puede imponer un tamaño de entidad, costo de firma, hardware, interoperabilidad o comportamiento operativo inaceptables en ese entorno. La selección técnica requiere evidencia RPKI; la selección institucional requiere una autoridad legítima y verificable.

Las claves RPKI representan autoridad limitada, no propiedad

La arquitectura descrita en RFC 6480 sigue la jerarquía existente de asignación de recursos numéricos. Los certificados de recursos vinculan una clave pública a direcciones IP o números AS incluidos en las extensiones del certificado. El certificado permite afirmaciones criptográficamente verificables en el RPKI. No transforma la clave privada en un título de propiedad, ni hace que la AC emisora sea propietaria de los recursos representados.

Esta distinción es importante durante la migración porque cada titular puede necesitar nuevas claves, certificados y productos firmados. Una AC padre debe estar lista para emitir bajo la nueva suite antes de que sus hijos puedan migrar en el modelo descendente establecido. Esta dependencia técnica le da al padre poder de secuenciación. No justifica una afirmación discrecional de que un hijo debe renunciar a la custodia, aceptar un servicio afiliado o renegociar sus derechos de recursos subyacentes.

La autoridad reconocida del titular debe permanecer como invariante entre suites criptográficas. Los certificados correspondientes pueden usar diferentes claves y codificaciones mientras representan el mismo conjunto de recursos. Las autorizaciones de ruta correspondientes pueden tener el mismo significado de enrutamiento mientras las firmas difieren. La migración es un cambio en cómo se verifica la autoridad, no una transferencia de autoridad misma.

La política de la AC debería decir esto claramente. Emitir un certificado de reemplazo no crea una nueva asignación, borra una disputa existente, cura una autoridad subyacente defectuosa ni permite que un proveedor reclame control beneficial. Por el contrario, la posesión de una clave privada poscuántica no puede anular una transferencia de recursos legal o revocación reconocida por reglas de gobernanza. El control criptográfico y el reconocimiento de recursos deben permanecer conectados sin confundirse.

La misma regla se aplica a la operación alojada. Una AC o servicio contratado puede generar y mantener claves para un cliente que elige la firma gestionada. Realiza una función técnica limitada para el titular reconocido. Una migración que requiere nuevo hardware o claves más grandes no debe usarse para reescribir esta relación como custodia permanente. El cliente debe conservar visibilidad, aprobación, registros, una ruta de actualización a operación delegada y una salida documentada.

La NRS puede hacer cumplir la invariante a través de una carta de derechos de certificación. La carta debe proteger la generación de claves autorizada por el titular, la elección de proveedor, el servicio parental oportuno, el acceso a la publicación, la exportación de evidencia, la renovación rutinaria y de emergencia, el monitoreo independiente y la revisión de acciones adversas. Estos derechos se aplican a la suite actual y a las suites de reemplazo. Ninguna excepción de migración debe permitir la recentralización silenciosa.

La autoridad de decisión debe dividirse por función

Ninguna institución única debería decidir todos los aspectos de la migración cuántica. El IETF es el lugar apropiado para especificaciones técnicas interoperables de Internet: identificadores de algoritmo, perfiles de certificado y entidad firmada, comportamiento de las partes interesadas, gestión de repositorios y procedimientos de transición. Su revisión abierta puede exponer conflictos de ingeniería y producir requisitos comunes. No asigna recursos numéricos ni opera cada AC.

Las AC de RPKI implementan estándares técnicos como parte de sus responsabilidades de certificación. Generan o aceptan solicitudes de certificado, emiten certificados, gestionan la revocación, publican productos firmados y apoyan las transiciones de los hijos. Los operadores de anclas de confianza tienen un papel particularmente importante porque su preparación afecta la jerarquía inferior. Su autoridad operativa debe estar limitada por hitos publicados, evidencia de conformidad y observación independiente.

Las partes interesadas deciden qué anclas de confianza y políticas algorítmicas aceptan. Esto no es una nota al pie teórica. Una nueva suite solo tiene efecto práctico cuando los validadores pueden obtenerla y verificarla, producir la salida validada esperada y entregarla a los sistemas de red. Los operadores necesitan configuraciones claras para solo antigua, aceptación paralela, nueva preferida con retroceso limitado y solo nueva. Los valores predeterminados ocultos convertirían la política local en un comportamiento global accidental.

Los titulares de recursos deciden cómo se mantienen sus claves en el perfil aceptado, quién puede operarlas, qué autorizaciones de ruta pretenden y qué proveedor calificado los asiste. No eligen individualmente un algoritmo global arbitrario y esperan aceptación universal. Su autonomía se ejerce dentro de reglas interoperables, con opciones significativas sobre custodia, soporte y sincronización durante las ventanas permitidas.

La gobernanza de la NRS debe conectar estas funciones sin absorberlas. Puede representar las necesidades de los miembros en discusiones de estándares, calificar servicios interoperables, coordinar ejercicios de preparación, publicar evidencia, proteger la portabilidad y proporcionar revisión independiente. No debe anunciar una suite propietaria, forzar a los miembros a usar una clave retenida por la NRS ni reclamar que una migración técnica extiende el título de la Sociedad sobre los recursos.

Los gobiernos y las autoridades de seguridad pueden publicar fechas de transición para los sistemas bajo su jurisdicción. Estas fechas pueden influir en proveedores y entidades, especialmente en redes del sector público. No deberían fragmentar el RPKI global en raíces nacionales incompatibles. La NRS y los RIR deben mapear las obligaciones aplicables, buscar una implementación interoperable y divulgar los conflictos temprano. La seguridad del enrutamiento global depende de una validación compartida incluso cuando las leyes de contratación difieren.

RFC 6916 proporciona una estructura, no una respuesta constitucional completa

RFC 6916 anticipó que el RPKI eventualmente necesitaría una suite algorítmica más fuerte. Describe una transición planificada que abarca varios años en lugar de un cambio de emergencia. El modelo es descendente: las autoridades padres se vuelven capaces antes que los hijos. Define hitos para la preparación de la AC, la producción de la AC, la preparación de las partes interesadas, un período de crepúsculo y el eventual fin de vida de la suite antigua.

El diseño utiliza conjuntos de productos correspondientes paralelos. Durante las fases clave, los certificados, listas de revocación, manifiestos y entidades firmadas pueden existir bajo ambas suites. Las partes interesadas pueden probar la siguiente suite mientras continúan usando la suite actual, luego preferir la nueva suite mientras retienen el camino antiguo por un intervalo limitado. Este es un mecanismo de seguridad importante porque una PKI global no puede depender de que todas las implementaciones cambien al mismo tiempo.

La estructura también expone el poder de gobernanza. Alguien debe publicar el cronograma de transición, decidir los umbrales de preparación y determinar cuándo la suite antigua llega al crepúsculo y al fin de vida. Un padre puede retrasar a un hijo al no soportar la nueva suite. Un validador puede seguir aceptando la suite antigua después del límite de seguridad previsto. Un proveedor puede usar la complejidad de la transición para desalentar la salida. La secuencia técnica necesita reglas institucionales en torno a estas acciones.

RFC 6916 no define explícitamente la transición de emergencia. Esta omisión es comprensible para su modelo planificado, pero la preparación cuántica no puede ignorar la posibilidad de evidencia acelerada: un avance criptoanalítico, un desastre de implementación o una indicación creíble de que la seguridad RSA se ha deteriorado más rápido de lo esperado. La NRS y los RIR necesitan un marco de decisión de emergencia que no improvise propiedad, anclas de confianza o retroceso bajo presión.

El procedimiento existente también es anterior a los tamaños de entidades poscuánticas actuales y las realidades de implementación. La publicación paralela puede multiplicar los costos de transferencia, caché y validación del repositorio. El sistema necesita mediciones en AC grandes y pequeñas, diversas condiciones de red y múltiples implementaciones de validadores. Un cronograma que solo los operadores mejor financiados puedan cumplir convertiría la seguridad criptográfica en una nueva barrera para la participación.

El suplemento constitucional debería definir cinco cosas: quién puede proponer y aprobar hitos; qué evidencia interoperable se requiere; cómo los titulares reciben igual acceso a la migración; cómo se manejan la divergencia y la degradación; y cómo se pueden revertir las decisiones. Los estándares describen un comportamiento válido. La gobernanza determina si el poder para exigir ese comportamiento se ejerce de manera justa.

La propuesta RPKI de 2026 es una prueba de progreso e incompletitud

Un borrador de Internet individual enviado a la comunidad SIDROPS del IETF en junio de 2026 proporciona un marcador actual útil. Propone ML-DSA-65 como candidato principal para la próxima suite de firmas RPKI y reutiliza convenciones de certificados y CMS poscuánticos desarrolladas en otras partes del IETF. Su objetivo es mantener intacta la arquitectura RPKI existente, el modelo de repositorio y el modelo de salida validada orientada al enrutador.

La propuesta no es un estándar de Internet adoptado y no debe describirse como tal. Su estatus es importante porque las decisiones de migración pueden volverse políticamente sensibles una vez que las instituciones invierten. Tratar una propuesta temprana como un hecho favorecería a los primeros implementadores y proveedores antes de que exista evidencia independiente. La respuesta adecuada es probar la propuesta rigurosamente y comparar alternativas según criterios publicados.

Su franqueza es valiosa. La revisión inicial informó la generación de certificados de CA ML-DSA y SLH-DSA, certificados de entidad final y listas de revocación utilizando una biblioteca criptográfica contemporánea. También informó que la ruta de CMS de línea de comandos probada no produjo los datos firmados ML-DSA necesarios, por lo que no se generaron manifiestos RPKI completos ni autorizaciones de ruta en ese entorno. La interoperabilidad multiválida con objetos RPKI poscuánticos completos seguía siendo trabajo futuro.

Esto no es evidencia de que ML-DSA no pueda funcionar en RPKI. Es evidencia de que una referencia de estándar, una implementación de algoritmo y una capacidad RPKI de extremo a extremo son diferentes niveles de madurez. La gobernanza debería recompensar la publicación de tales brechas. Suprimirlas para mantener el impulso aumentaría el riesgo de una fecha obligatoria frágil.

La propuesta también identifica claves y firmas más grandes como preocupaciones para repositorios y validación. ML-DSA-65 se selecciona como candidato porque tiene un estándar NIST finalizado e identificadores estables de certificado IETF y CMS, no porque sea siempre la opción más pequeña o más rápida. SLH-DSA ofrece diversidad criptográfica pero puede imponer firmas significativamente más grandes o costos de firma más altos, dependiendo de la variante. Otros candidatos pueden ofrecer ventajas de tamaño pero carecen de perfiles y madurez de implementación equivalentes.

La NRS debe tratar el borrador como una invitación a la medición compartida. Puede financiar implementaciones independientes, pruebas de repositorio, ensayos de hardware y comparación de validadores sin declarar un ganador. Los resultados deben incluir fallas y detalles del entorno. Un proveedor que aporte evidencia útil no debe recibir control exclusivo sobre la migración de producción como recompensa.

La selección de algoritmos necesita un estándar de evidencia público

La suite seleccionada debe cumplir criterios criptográficos, operativos e institucionales. Los criterios criptográficos incluyen la base de seguridad, la fuerza de los parámetros, la resistencia de implementación, los requisitos de aleatoriedad, el comportamiento de canales laterales, el comportamiento ante fallos y la diversidad con respecto a otras suites aceptadas. La existencia de un estándar formal es necesaria para la confianza pero no elimina el riesgo de implementación.

Los criterios operativos incluyen el tamaño de la clave pública y la firma, el crecimiento del certificado y la lista de revocación, el tamaño del manifiesto, las instantáneas y diferencias del repositorio, la latencia de firma, la CPU y memoria del validador, el tamaño de caché, el manejo de fallos y la disponibilidad de hardware. Las mediciones deben usar repositorios globales representativos así como casos extremos sintéticos. Un resultado mediano puede ocultar una falla para un validador pequeño o un punto de publicación grande.

Los criterios de interoperabilidad requieren que al menos dos implementaciones de AC independientes, múltiples entornos de repositorio e implementaciones importantes de partes interesadas se pongan de acuerdo sobre conjuntos completos de entidades válidas e inválidas. Las pruebas deben cubrir identificadores de algoritmo malformados, parámetros no soportados, manifiestos obsoletos, revocación inconsistente, suites desconocidas y ramas mixtas antiguas-nuevas. Aceptación significa un comportamiento de seguridad consistente, no solo una verificación exitosa de una entidad feliz.

Los criterios institucionales incluyen licencias, concentración de proveedores, diversidad de hardware, soporte de exportación y renovación, disponibilidad entre regiones, costo para operadores pequeños y capacidad de reemplazar un proveedor. Una suite teóricamente excelente puede crear riesgo de gobernanza si un solo proveedor controla el hardware utilizable o solo un servicio puede operar el formato de clave requerido. La evidencia de adquisiciones debe acompañar a la evidencia de rendimiento.

Los criterios deben fijarse antes de comparar algoritmos favorecidos. De lo contrario, las instituciones pueden seleccionar métricas que justifiquen una inversión existente. La NRS debe publicar criterios, métodos de prueba, conjuntos de datos, excepciones y conflictos de revisores. Los comentarios de la comunidad deben responderse con razones. La recomendación final debe explicar por qué se rechazaron alternativas y qué evidencia podría provocar una reconsideración.

La diversidad algorítmica es valiosa pero no gratuita. Soportar múltiples suites aumenta la complejidad del código, la configuración y la desaprobación. RFC 7696 advierte que demasiadas opciones pueden dañar la interoperabilidad y dejar algoritmos débiles implementados demasiado tiempo. El objetivo es un conjunto pequeño y coherente con un camino de reemplazo creíble, no un menú permanente que cada validador interprete de manera diferente.

La equivalencia semántica es la prueba de fuego de la migración

Las entidades de la suite antigua y la nueva no serán idénticas byte a byte. Las claves, firmas, números de serie de certificados, detalles de validez y rutas de repositorio pueden diferir. La pregunta significativa es si producen la misma semántica de recursos y enrutamiento aceptada. Para las autorizaciones de ruta, los validadores deben comparar la carga útil validada resultante por prefijo, longitud máxima, AS de origen y contexto de confianza relevante.

Si las ramas divergen, un validador no debe fusionarlas en silencio. Supongamos que la rama RSA autoriza un origen mientras que la rama poscuántica autoriza otro, o una rama ha revocado un certificado hijo mientras la otra permanece actual. Combinar ambas podría ampliar la autoridad más allá de cualquier estado previsto. Elegir la que se valide primero puede ocultar un error operativo grave o un ataque.

La divergencia debe producir telemetría explícita y una respuesta de política limitada. Durante una fase de prueba temprana, la producción puede continuar confiando en la suite establecida mientras se investiga la nueva rama. Durante una fase de preferencia de nueva suite, se puede permitir el retroceso para una clase definida de falla técnica, pero no para un conflicto semántico. La diferencia entre no soportado, no disponible, malformado, expirado y contradictorio debe permanecer visible.

La AC tiene el deber de mantener un estado coincidente entre las ramas durante la publicación paralela. Las revocaciones, cambios de recursos e instrucciones del titular deben aplicarse de manera consistente. La generación automatizada puede reducir la deriva, pero la automatización compartida también puede repetir un error. Los validadores independientes y los monitores del titular deben comparar las salidas en lugar de confiar en una pantalla administrativa común.

Las comprobaciones semánticas deben extenderse más allá de las autorizaciones de ruta. Los conjuntos de recursos del certificado, el estado de revocación, la cobertura del manifiesto y el inventario de entidades necesitan comparaciones correspondientes. Las entidades firmadas más nuevas y los usos futuros pueden requerir reglas de equivalencia específicas de la entidad. El principio rector es estable: la migración cambia la representación criptográfica, no la autoridad de recursos prevista.

La NRS debe hacer públicas las estadísticas de divergencia de forma agregada. Los informes pueden mostrar entidades no emparejadas, salidas validadas inconsistentes, ramas obsoletas, eventos de retroceso, desacuerdos de validadores y tiempo de corrección. Los detalles sensibles del titular pueden permanecer protegidos. Una transición que afirma éxito mientras oculta divergencia semántica ha medido criptografía pero no seguridad de enrutamiento.

La publicación paralela no debe convertirse en degradación permanente

Ejecutar dos suites proporciona un camino de recuperación mientras la nueva madura. También preserva el camino vulnerable. Si los validadores aceptan RSA indefinidamente cuando la rama poscuántica falta o es inválida, un atacante puede suprimir la rama más fuerte y obtener el resultado más débil. El retroceso se convierte en un canal de degradación cuando sus condiciones son amplias, silenciosas o permanentes.

Cada fase necesita una política de aceptación explícita. En la fase de prueba, la suite actual sigue siendo autoritativa y la siguiente suite proporciona evidencia. En la fase de producción paralela, ambas deben estar presentes y ser semánticamente equivalentes. En la fase de preferencia, la nueva suite gobierna, con retroceso definido estrictamente para fallas de disponibilidad. Al final de la vida, la aceptación de la suite antigua cesa excepto en contextos forenses o de prueba aislados.

El retroceso debe tener límite de tiempo, registrarse y ser visible para el operador. Un validador que retrocede repetidamente debe alertar en lugar de normalizar la condición. Los operadores de anclas de confianza y AC deben recibir señales agregadas para que puedan distinguir una falla de repositorio de una incompatibilidad sistémica. Los titulares de recursos deben poder ver si sus productos se aceptan bajo ambas suites.

La fecha de retiro debe basarse en evidencia pero ser creíble. Una fecha que cambia cada vez que un proveedor se retrasa da a cada proveedor un incentivo para retrasarse. Una fecha que ignora una incompatibilidad de hardware puede fragmentar la validación. La gobernanza debe definir umbrales de preparación, categorías de excepción y consecuencias de antemano. Los operadores críticos tardíos pueden recibir asistencia limitada o medidas de transición aisladas, no un veto indefinido.

Las claves y productos antiguos requieren un retiro controlado. Eliminarlos demasiado pronto puede crear brechas de validación; mantener la capacidad de firma demasiado tiempo preserva la superficie de ataque. Las AC deben destruir o archivar las claves privadas antiguas según un riesgo definido, retirar el material de confianza antiguo en la etapa declarada y conservar suficiente evidencia pública para explicar el estado histórico. La evidencia de retiro debe ser revisada independientemente para AC de nivel superior.

La capacidad de deshacer la nueva suite es diferente de continuar confiando en la antigua para siempre. Un plan de reemplazo puede activar otra suite resistente, restaurar una implementación anterior buena conocida o suspender la nueva emisión mientras los productos válidos actuales persisten. La reversibilidad debe diseñarse como una transición gobernada, no como una excepción oculta que anula el propósito de seguridad.

La custodia de claves debe seguir siendo portátil a través de cambios de hardware

Las claves privadas poscuánticas pueden requerir nuevas bibliotecas criptográficas, módulos de seguridad de hardware, perfiles de memoria, ceremonias de firma y arreglos de respaldo. Estos cambios crean una oportunidad natural para que los proveedores agrupen custodia, publicación y soporte. La agrupación puede reducir el costo operativo. También puede atrapar a los titulares si la nueva clave solo se puede usar a través de la cuenta de un solo proveedor o una interfaz no documentada.

La NRS debe preservar la presunción de que un titular puede operar una AC delegada o nombrar un proveedor bajo autoridad controlada por el titular. La generación de claves debe ocurrir dentro de un límite de seguridad que el titular controle o sobre el que tenga derechos contractuales decisivos. El titular debe saber quién puede activar la firma, cómo funcionan las aprobaciones, qué evidencia se conserva y cómo ocurre el reemplazo.

La exportación de claves privadas no siempre es deseable. Un dispositivo de hardware puede prevenirlo deliberadamente. Por lo tanto, la portabilidad no puede significar que cada clave privada deba ser extraíble. Significa que la relación de certificación, los productos públicos, la configuración, la evidencia de auditoría y el servicio de publicación pueden moverse, mientras se genera y certifica una nueva clave a través de una renovación coordinada. La no exportabilidad protege el material clave; no confiere propiedad al operador del dispositivo.

Los proveedores deben soportar interfaces comunes de solicitud de certificado, publicación y monitoreo. Los envoltorios de clave personalizados, las opciones de parámetros no divulgados y los sistemas de aprobación propietarios no deben convertirse en condiciones para la participación en RPKI. Cuando el soporte de hardware es escaso durante la implementación temprana, la NRS puede calificar servicios compartidos, pero los contratos deben incluir asistencia para la transición y ningún reclamo sobre los recursos del titular.

La copia de seguridad y la recuperación requieren pruebas específicas del algoritmo. Algunos métodos de firma poscuántica dependen críticamente de una aleatoriedad segura. El hardware y el software pueden representar las claves de diferentes formas. Las ceremonias de recuperación deben verificar que las claves restauradas o de reemplazo funcionen con codificaciones conformes y no repitan aleatoriedad insegura. La respuesta más segura a una sospecha de compromiso suele ser el reemplazo en lugar de la recuperación de la misma clave de firma.

Los operadores pequeños necesitan acceso financiado a una migración segura. Si solo las grandes redes pueden permitirse hardware y pruebas compatibles, la custodia central alojada se convertirá en el valor predeterminado práctico. La NRS puede proporcionar subvenciones, configuraciones de referencia, ceremonias gestionadas y entornos de prueba compartidos utilizables con múltiples proveedores. El apoyo debe seguir al miembro, no subsidiar a un anfitrión dominante.

La capacidad del repositorio es una preocupación de gobernanza

Las firmas poscuánticas pueden ser mucho más grandes que las firmas RSA actuales. La publicación paralela puede multiplicar certificados, listas de revocación, manifiestos y entidades firmadas. Las partes interesadas sincronizan repetidamente el contenido del repositorio global, lo validan y producen salidas locales. Una suite que aumenta drásticamente la transferencia o el procesamiento puede afectar a los operadores de manera desigual y crear una nueva concentración entre validadores de alta capacidad.

Las mediciones deben cubrir instantáneas completas, actualizaciones incrementales, arranque en frío, actualización ordinaria, renovación masiva, eventos de revocación y recuperación después de la pérdida de estado local. El comportamiento de la instantánea y delta de RRDP es importante, así como el retroceso a otros métodos de recuperación. Las pruebas deben incluir redes restringidas, regiones remotas y hardware básico en lugar de solo un laboratorio bien conectado.

Los límites de tamaño de entidad y los controles de recursos deben evitar dos fallas. Los límites demasiado laxos pueden permitir el agotamiento de la memoria, el almacenamiento o el procesamiento. Los límites demasiado estrictos pueden rechazar productos poscuánticos legítimos. Los validadores deben informar si el rechazo se debió a la política algorítmica, sintaxis, tamaño, tiempo, memoria o validación semántica. Un resultado genérico de 'inválido' impide el diagnóstico y puede fragmentar la respuesta del operador.

Los proveedores de repositorios no deben ganar autoridad política simplemente porque absorben costos adicionales. Su función es publicar productos conformes de manera confiable e informar la capacidad. Las tarifas pueden reflejar el costo medible del servicio, sujeto a transparencia y competencia. Un repositorio no debe decidir que solo su AC afiliada puede usar la nueva suite o retrasar la migración de un cliente para proteger un paquete comercial.

La evidencia de capacidad debe informar la elección del algoritmo y el cronograma. Si ML-DSA produce un crecimiento significativo pero manejable, la ingeniería y la inversión pueden ser preferibles a seleccionar una alternativa menos madura solo por el tamaño. Si las mediciones muestran que una suite propuesta hace que la validación global sea impracticable, el trabajo de estandarización debe adaptarse. La decisión pertenece a la evaluación técnica abierta, no a una negociación contractual privada.

La NRS puede coordinar repositorios de prueba compartidos y publicar distribuciones de rendimiento anonimizadas. Debe separar las pruebas de las anclas de confianza y las claves de producción. Los experimentos tempranos no deben filtrarse a la producción porque un operador reutiliza una ruta de repositorio conveniente. La separación visual y técnica clara protege tanto la seguridad como la credibilidad de los resultados.

La migración de emergencia requiere un modelo de poder más restringido

Una migración planificada permite años de preparación. Una emergencia puede ofrecer solo semanas o días. El desencadenante podría ser evidencia criptoanalítica creíble, un compromiso de una implementación ampliamente utilizada, una falla catastrófica de aleatoriedad o un defecto en la suite poscuántica seleccionada después del despliegue. Diferentes desencadenantes requieren diferentes respuestas; 'emergencia cuántica' no debe ser un cheque en blanco.

La autoridad para declarar una emergencia debe distribuirse. La evidencia técnica puede venir de criptógrafos, mantenedores de implementación, organismos de seguridad nacional o investigadores independientes. Los operadores de anclas de confianza y los organismos de estándares deben evaluar el efecto global. La NRS y otros órganos de gobernanza deben proteger la continuidad de los miembros y prevenir cambios de servicio interesados. Ningún proveedor de AC debe poder declarar una emergencia que obligue a los clientes a usar su producto.

Los poderes de emergencia deben preespecificarse: acelerar un hito ya probado, acortar la validez del certificado, suspender cierta emisión, requerir monitoreo mejorado, activar una suite alternativa resistente o limitar el retroceso. Cada acción debe indicar alcance, evidencia, duración y revisión. La respuesta debe evitar modificar el reconocimiento de recursos subyacente a menos que el incidente cuestione directamente ese reconocimiento.

Una renovación de clave de emergencia puede ser técnicamente válida pero institucionalmente abusiva. Un padre podría negar la nueva solicitud de un hijo, insistir en la custodia alojada o usar la emergencia para retirar un recurso en disputa. La revisión independiente debe poder distinguir la necesidad de seguridad del apalancamiento no relacionado. La continuidad temporal puede preservar un estado previo no disputado mientras se desarrolla la disputa.

La comunicación debe evitar la falsa certeza. Si la evidencia es preliminar, los operadores deben saber qué se conoce, qué permanece desconocido y qué acciones protectoras son reversibles. Ocultar la incertidumbre puede producir una sobrerreacción descoordinada. Publicar detalles operativos sensibles demasiado pronto puede aumentar el riesgo. Un plan de divulgación escalonado debe servir a implementadores, operadores de red, titulares y al público en niveles apropiados.

Toda acción de emergencia debe terminar. Las fechas de finalización, la revisión posterior a la acción, el retiro de claves y la compensación por acciones indebidas deben definirse antes de su uso. Una autoridad de emergencia que se convierte en control ordinario convertiría el riesgo criptográfico en captura institucional.

La reversión es una capacidad, no una admisión de fracaso

Las instituciones a veces evitan discutir la reversión porque parece debilitar la confianza en la suite seleccionada. Lo contrario es cierto. Una migración sin una respuesta segura a defectos de implementación, divergencia semántica o sobrecarga operativa se basa en el optimismo. La reversibilidad permite pruebas más tempranas mientras limita las consecuencias de un error.

La reversión no significa necesariamente volver a RSA como respuesta de producción. Antes del fin de vida de la suite antigua, se puede aceptar una reversión limitada si la nueva implementación falla pero RSA permanece dentro de la ventana de seguridad declarada. Más tarde, la reversión puede significar cambiar a una segunda suite resistente, restaurar una versión corregida o preservar el estado firmado actual mientras se suspende la nueva emisión.

Los criterios de aceptación deben declararse antes de cada fase de producción. Los ejemplos incluyen desacuerdo del validador por encima de un umbral, divergencia semántica, crecimiento del repositorio más allá de los límites probados, comportamiento de hardware no soportado, aleatoriedad insegura, fuga de claves o incapacidad para revocar de manera consistente. Los criterios deben identificar quién ordena la reversión y cómo se conserva la evidencia.

Los ejercicios deben simular una reversión parcial. Una AC puede necesitar revertir mientras otras permanecen en la nueva suite. Una versión de validador puede ser defectuosa. Un repositorio puede rechazar una entidad válida. La jerarquía descendente y el modelo de producto paralelo pueden crear dependencias que dificulten la corrección local. Probar estos límites revela si la reversibilidad reclamada existe en la práctica.

El camino de retorno debe evitar la autoridad dual descontrolada. Las AC necesitan manifiestos ordenados, estado de revocación y claves actuales claras. Los validadores necesitan política explícita y telemetría. Los titulares necesitan confirmación de que sus autorizaciones de ruta previstas permanecen sin cambios. Las claves antiguas o las nuevas fallidas deben retirarse cuando ya no sean necesarias, con evidencia suficiente para una revisión posterior.

Los informes públicos deben distinguir la causa de la reversión de la falla algorítmica. Una mala integración de biblioteca no prueba que el primitivo criptográfico esté roto. Un problema de capacidad de recursos puede requerir trabajo de arquitectura en lugar de abandono. La clasificación precisa protege el aprendizaje técnico y evita que los proveedores utilicen una falla para desacreditar a competidores sin evidencia.

Tres casos de migración revelan lo que está en juego en la gobernanza

Considere una AC delegada grande que controla su propio hardware y publicación. Se une a un piloto de producción después de que dos validadores independientes soporten la siguiente suite. El padre emite certificados correspondientes y el titular publica productos semánticamente equivalentes bajo ambas suites. Los monitores externos comparan las salidas validadas. Después de un intervalo medido, la nueva suite se vuelve preferida. El titular cambia de proveedor de hardware durante el piloto a través de una renovación normal sin cambiar su estado de recursos.

Este es un resultado sólido porque la migración técnica y el movimiento del proveedor coexisten. El padre cumple con su deber de certificación, el titular retiene la custodia, los repositorios publican ambas ramas y los validadores exponen la divergencia. Ninguna parte obtiene un reclamo permanente por haber sido primero. La evidencia, no el prestigio institucional, respalda el siguiente hito.

Ahora considere un operador pequeño que utiliza firma alojada. Su proveedor anuncia que el servicio poscuántico requiere un contrato de diez años porque el hardware es caro y dice que la nueva clave no se puede mover. La NRS debe rechazar el reclamo de bloqueo. El proveedor puede cobrar tarifas transparentes por el servicio, pero el operador debe poder reemplazar la clave, mover la publicación y nombrar otro anfitrión calificado. Una clave no exportable se retira mediante renovación; el derecho de recurso continúa.

El tercer caso es un conflicto semántico. La rama RSA contiene una autorización de ruta establecida, mientras que la rama poscuántica la omite después de un error de publicación. Los validadores que prefieren la nueva suite clasificarían la ruta de manera diferente. El sistema debe alertar, evitar la fusión silenciosa y permitir un retroceso limitado mientras la AC corrige la nueva rama. Los recibos del titular y el estado anterior ayudan a establecer la intención. El incidente se revisa y se incluye en las métricas de preparación.

Cambie los hechos una vez más: la nueva rama contiene una autorización adicional no presente bajo RSA. El retroceso no puede resolver esto seleccionando el resultado que mantenga estable el tráfico. La autoridad adicional puede ser maliciosa o errónea. La entidad afectada debe aislarse, la evidencia de firma y administrativa de la AC debe examinarse, y el titular debe ser contactado a través de canales protegidos. La validez criptográfica no hace que la semántica divergente sea legítima.

Estos casos muestran por qué la migración no puede reducirse a identificadores de algoritmo. Los resultados decisivos son la autoridad portátil, el significado de enrutamiento consistente, la falla observable y la acción institucional verificable. Un sistema puede ser resistente a lo cuántico y mal gobernado. También puede ser institucionalmente justo pero técnicamente no preparado. La transición debe satisfacer ambas pruebas.

La NRS debería adoptar una carta de migración 2025-2035

La carta debe comenzar con invariantes. El reconocimiento de recursos numéricos no cambia simplemente porque cambie la suite de firmas. El titular retiene el derecho a la custodia autorizada y la elección de proveedor. Las AC no reciben nuevos reclamos de propiedad. Las partes interesadas retienen una elección explícita de política de confianza. Los poderes de emergencia son temporales, limitados y revisables.

La segunda parte debe definir puertas de evidencia técnica. No se debe establecer ninguna suite de producción obligatoria antes de que se logre la interoperabilidad completa de certificado, revocación, manifiesto y autorización de ruta en implementaciones independientes. Las mediciones de repositorio y validador deben cubrir una escala representativa. Las comprobaciones de equivalencia semántica, las pruebas de entidades malformadas, el comportamiento de degradación y la renovación deben pasar los criterios de aceptación publicados.

La tercera parte debe definir pasos y fechas como rangos antes de que se conviertan en compromisos. De 2025 a 2027, dominan el inventario, la revisión de estándares y los experimentos aislados. De 2027 a 2030, las jerarquías de prueba interoperables y los pilotos paralelos seleccionados pueden expandirse si la evidencia los respalda. A partir de 2030, la preferencia de producción y el retiro clásico pueden programarse según la evidencia de seguridad, la preparación del proveedor y la interoperabilidad global. El horizonte 2035 debe motivar la finalización sin pretender que un cronograma se ajuste a cada contexto de confianza.

La cuarta parte debe proteger la participación. Los operadores pequeños reciben soporte de referencia y servicio gestionado portátil. Los proveedores divulgan dependencias y condiciones de salida. Las obligaciones del sector público se mapean sin crear raíces incompatibles. Los representantes de los miembros, expertos en seguridad, implementadores y revisores independientes participan en las decisiones de hitos. Los conflictos de interés se registran.

La quinta parte debe definir la autoridad de incidentes y reversión. Las clases de activación, los órganos de decisión, las medidas temporales, los límites de retroceso, la comunicación, la revisión y la finalización se aprueban antes de la crisis. Ninguna emergencia permite que una AC resuelva disputas de recursos no relacionadas. La compensación y la corrección se aplican cuando se abusan de los poderes excepcionales.

Finalmente, la carta debe exigir evidencia anual. La NRS informa sobre cobertura de implementación, diversidad de hardware, crecimiento del repositorio, tiempo de validación, divergencia de ramas, retroceso, éxito de renovación, concentración de proveedores, preparación de pequeños operadores y riesgos no resueltos. Las métricas deben mostrar distribuciones y pruebas fallidas, no solo un porcentaje marcado como listo.

La migración tiene éxito solo si los usuarios pueden irse

Las transiciones criptográficas concentran naturalmente la experiencia. El hardware temprano es escaso, las bibliotecas son desconocidas, los estándares cambian y los errores operativos pueden ser costosos. Algunos proveedores pueden volverse indispensables. Es precisamente en este momento cuando los derechos de salida deben ser más fuertes, porque la dependencia formada durante la transición puede persistir mucho después de que la tecnología madure.

Cada servicio poscuántico calificado debe ofrecer incorporación documentada, exportación de evidencia, portabilidad de publicación, renovación de clave de reemplazo, terminación y cooperación en incidentes. El contrato debe indicar que los certificados y productos firmados se ejecutan para el titular reconocido, no son propiedad del servicio. Los cambios de precio significativos o la adquisición del proveedor deben activar una ventana de movimiento razonable.

La NRS debe probar la salida de forma anónima. Un cliente sintético puede pasar de un servicio alojado a otro, de una operación alojada a una delegada y de un proveedor de hardware a otro. La prueba observa la respuesta del padre, la continuidad del repositorio, la equivalencia semántica, el retiro de credenciales y la convergencia del validador. Un proveedor que puede firmar pero no puede liberar a un cliente no está completamente calificado.

La competencia debe incluir capacidad de continuidad. Si un servicio dominante falla, los proveedores alternativos deben tener suficiente hardware, personal y capacidad de repositorio para aceptar migraciones en oleadas. La capacidad de reserva puede probarse sin asignar recursos en vivo. Los mapas de dependencia deben revelar si las alternativas aparentes utilizan el mismo módulo criptográfico, control en la nube o equipo de soporte.

La elección del usuario no es absoluta. Un titular no puede exigir un algoritmo no estandarizado, un manejo de claves inseguro o la aceptación indefinida de la suite antigua. La Sociedad puede imponer resultados de seguridad comunes. La prueba de legitimidad es si los requisitos son neutrales para el proveedor, basados en evidencia, remediables y no más amplios de lo necesario para la interoperabilidad y la seguridad.

Irse es la evidencia más fuerte de que el papel técnico de una AC no se ha convertido en un reclamo de activos. Si el titular puede generar una clave de reemplazo, obtener la certificación correspondiente, mover la publicación y preservar la semántica de enrutamiento bajo un nuevo servicio calificado, la jerarquía ha coordinado la seguridad sin confiscar la elección.

La gobernanza debe seguir siendo adaptable después de la transición cuántica

La migración poscuántica no será el último cambio criptográfico. Los algoritmos pueden debilitarse, las implementaciones pueden fallar, el hardware puede concentrarse y las suposiciones operativas pueden envejecer. El objetivo duradero no es un solo pase exitoso de RSA a una suite favorita. Es un sistema capaz de cambiar nuevamente sin crisis o captura.

Esa capacidad depende de límites de abstracción limpios, formatos interoperables, política algorítmica explícita, claves portátiles o renovación, capacidad de repositorio, monitoreo semántico y derechos de decisión practicados. También depende de la memoria institucional. La evidencia de los primeros pilotos, pruebas fallidas, acciones de emergencia y cambios de proveedor debe preservarse para que los líderes futuros no repitan errores evitables.

La NRS debe separar la política algorítmica de la política de servicios comerciales. Una actualización técnica puede revisar las suites aceptadas sin reescribir los derechos de membresía. Una calificación de proveedor puede cambiar sin modificar el estándar. Una disputa de titular puede ser adjudicada sin elegir una arquitectura criptográfica. La separación reduce la probabilidad de que una pregunta urgente lleve consigo un poder no relacionado.

La revisión independiente debe continuar después del fin de vida de la suite antigua. Los revisores deben verificar que las claves antiguas se hayan retirado, que los validadores no soportados sigan ausentes, que las excepciones de retroceso no sean persistentes, que el nuevo mercado no esté concentrado y que los titulares aún puedan moverse. Una declaración de finalización no debe terminar la observación.

La Sociedad también debe mantener la humildad sobre la palabra 'seguro'. Los algoritmos poscuánticos están diseñados para resistir ataques clásicos y cuánticos conocidos bajo el análisis actual. No son garantías contra cualquier descubrimiento futuro, canal lateral, error de implementación o abuso administrativo. Las afirmaciones precisas preservan la confianza mejor que el lenguaje absoluto.

El éxito de la gobernanza será visible cuando el próximo cambio algorítmico sea rutinario: los estándares maduran abiertamente, las implementaciones independientes interoperan, los titulares retienen autoridad, los proveedores compiten, los validadores exponen diferencias y las claves antiguas se retiran sobre la base de evidencia. La migración cuántica es el caso de prueba para esa capacidad duradera.

Una clave más fuerte no debe crear una institución más fuerte de la que los miembros autorizaron

El período hasta 2035 invitará a afirmaciones dramáticas. Algunos predecirán un colapso cuántico inmediato; otros descartarán la preparación como especulativa. La posición responsable se encuentra en el medio. El RPKI debe construir y probar un camino poscuántico ahora porque las migraciones globales toman años y una falla criptográfica podría afectar la confianza en el enrutamiento. Debe mantener las fechas obligatorias condicionadas a evidencia completa porque una implementación prematura puede crear su propio riesgo sistémico.

La jerarquía técnica es inevitable. Las AC padre deben estar listas, los repositorios deben transportar nuevas entidades y las partes interesadas deben validarlas. La jerarquía institucional es una elección. El sistema puede coordinar estas funciones sin otorgar a una AC custodia permanente, control propietario o un veto sobre el movimiento del cliente. Los derechos claros y la renovación interoperable convierten la jerarquía en servicio en lugar de propiedad.

El registro de estándares ya proporciona bases útiles. RFC 6916 proporciona un modelo de fases plurianual. RFC 7696 explica por qué la agilidad algorítmica requiere más que identificadores y por qué demasiadas opciones pueden debilitar la interoperabilidad. NIST ha estandarizado firmas poscuánticas creíbles. Las especificaciones de certificados y CMS del IETF ahora soportan ML-DSA. El trabajo actual de RPKI identifica tanto un candidato plausible como preguntas de implementación no resueltas.

La tarea restante es la gobernanza bajo incertidumbre. La NRS debe definir quién decide, qué evidencia cuenta, cómo se maneja la disidencia, cuándo termina el retroceso, cómo funciona la reversión y qué derechos sobreviven a cada paso. Debe medir las consecuencias en repositorios y validadores, apoyar a los miembros pequeños y evitar que la concentración de proveedores se convierta en política.

Una clave privada más larga o más compleja no confiere un derecho mayor. Un nuevo certificado no crea una nueva asignación. Una AC que coordina la migración no adquiere el recurso. Un proveedor que almacena la clave no posee la relación de certificación. Estas proposiciones deben escribirse antes de que la infraestructura costosa y la retórica de emergencia las hagan más difíciles de defender.

La migración cuántica tendrá éxito cuando la criptografía cambie y la distribución legítima del poder no. El titular permanece reconocido, la AC sigue siendo responsable, el validador permanece explícito, el proveedor sigue siendo reemplazable y el estándar permanece abierto a la evidencia. Eso no es un obstáculo para la seguridad del enrutamiento. Es la condición de gobernanza que hace que la seguridad del enrutamiento más fuerte sea digna de confianza.

Evidencia y lecturas adicionales