Resumen

  • RFC 9980 permite combinar, durante una migración, destinatarios PQ/T y tradicionales para evitar una interrupción; esa continuidad no equivale a confidencialidad poscuántica del mensaje.
  • La unidad que debe auditarse es el conjunto real de destinatarios y los PKESK que salieron del emisor, con cada excepción clásica atribuida y limitada en el tiempo.

El mensaje hereda su límite del camino más antiguo

Un inventario puede mostrar una nueva clave ML-KEM-768+X25519 y dar una impresión tranquilizadora. Sin embargo, una clave publicada sólo prueba que existe un material de clave con ese identificador. No prueba que el cliente destinatario lo procese, que la clave corresponda a quien se cree, que se haya usado para un envío concreto ni que la organización haya decidido retirar los caminos previos.

La sección 8.1 de RFC 9980 reconoce precisamente el problema de la transición. Un emisor puede cifrar para claves PQ(/T) y tradicionales a la vez con el fin de no romper la comunicación. OpenPGP logra esto mediante varios paquetes PKESK, cada uno de los cuales permite recuperar la misma clave de sesión para un destinatario. La sección 3.1 impide transformar ese arreglo de compatibilidad en una promesa exagerada: si alguna de las claves empleadas no es PQ(/T), la confidencialidad del mensaje no es poscuántica.

Eso no convierte al destinatario tradicional en una falta técnica ni obliga a bloquearlo sin contexto. Puede existir una obligación de continuidad, una relación que no ha actualizado su cliente o un mecanismo de recuperación aceptado. Lo que no puede hacerse es describir el mensaje como resistente a la amenaza que se quiso evitar y esconder la excepción dentro de una lista de distribución. La excepción cambia la propiedad de ese cifrado y merece un responsable.

Compuesto y paralelo son formas distintas de protección

La palabra «híbrido» suele borrar una diferencia crucial. En la construcción compuesta de RFC 9980, ML-KEM y un KEM ECDH forman una sola clave destinataria PQ/T. Sus encapsulaciones se ejecutan por separado, pero sus resultados se combinan con datos de contexto para obtener la clave que envuelve la clave de sesión. La estructura exige ambos componentes para el descifrado de esa ruta.

Varios PKESK no crean automáticamente esa estructura. Un PKESK clásico situado junto a uno PQ/T permite otra ruta independiente hacia la clave de sesión. Por eso la pregunta operativa no es «¿aparece criptografía híbrida en el mensaje?», sino «¿qué rutas de destinatario puede utilizar este cifrado?». La segunda pregunta puede responderse con metadatos de paquete; la primera puede ser cierta y aun así insuficiente.

Firmar durante la transición es otro problema

Para firmas, el RFC acepta una estrategia de compatibilidad diferente. El remitente puede incluir una firma tradicional y otra PQ(/T), pues un verificador antiguo puede recurrir a la primera. El software más nuevo puede aceptar ambas; también puede preferir ignorar la firma tradicional cuando sabe que el par dispone de una clave PQ/T y el riesgo cuántico importa para ese contexto.

Una firma válida sigue sin probar identidad jurídica, autoridad para ordenar una acción o veracidad del texto firmado. Esta separación importa para la gobernanza: una política de destinatarios de cifrado y una política de verificación de firmas tienen condiciones de salida distintas. Declarar que un correo «usa PQC» no decide ninguna de las dos.

Evidencia suficiente, sin convertirla en vigilancia

La prueba útil puede ser pequeña: clase de mensaje, claves elegidas, algoritmo y versión, PKESK emitidos, resultado de capacidad conocido y decisión que permite cualquier destinatario tradicional. RFC 9980 sitúa la mayoría de las claves PQ(/T) en v6 o posterior y deja la excepción de ML-KEM-768+X25519 para determinadas subclaves v4 de cifrado. IANA registra los identificadores, pero un registro no es una prueba de adopción.

Guardar el contenido de cada correo para demostrar una migración sería desproporcionado. Registrar la forma criptográfica y la decisión de excepción, con protección adecuada, permite una revisión sin construir un archivo paralelo de correspondencia.

Fuentes