Resumen

  • La última llamada del grupo OpenPGP sobre draft-ietf-openpgp-nist-bp-comp-04 tenía como fecha final el 9 de septiembre de 2026. El documento sigue siendo un Internet-Draft activo, con destino Informational; la fecha no equivale a aprobación.
  • La revisión publicada usa los identificadores experimentales 100–107. Una propuesta y varias ramas ya prueban 37–44, pero el registro IANA capturado aún muestra 37–99 como no asignados.
  • En los KEM compuestos, el número se incorpora a multiKeyCombine y modifica la clave derivada que envuelve el secreto de sesión. En las firmas, cambia los paquetes y sus huellas.
  • La evidencia de interoperabilidad necesita un recibo de estado: revisión, número exacto, commit, hash de vectores, build probado, estado del registro y aptitud o no para una publicación formal.

La convocatoria de última llamada abrió el 19 de agosto y pidió respuestas antes del 9 de septiembre. No hay que convertir el calendario en una resolución. En la captura, la ficha de Datatracker mantiene el texto como In WG Last Call, mientras el estado de IESG es I-D Exists. El historial documenta su recorrido, sin que la ficha muestre shepherd, director de área responsable ni telechat. El estatus previsto es Informational.

La revisión 04 combina algoritmos poscuánticos de NIST con opciones clásicas de curva elíptica para OpenPGP. Define cuatro alternativas compuestas de encapsulación de claves y cuatro de firma. Todas son opcionales. Por ahora llevan los valores 100 a 107, reservados para uso privado o experimental. El propio texto limita esos números a software no publicado y a experimentos de interoperabilidad, prohíbe emplearlos en lanzamientos formales y aplaza el envío a IANA hasta que todos los algoritmos tengan identificadores no experimentales.

El laboratorio ya trabaja con el siguiente mapa

En la lista del grupo, una propuesta concreta ubica los ocho algoritmos en 37–44. La respuesta de Daniel Kahn Gillmor considera plausible la distribución, pero pide mantener los códigos experimentales hasta que una versión publicada del borrador contenga los nuevos. Es una pauta sensata para impedir que una hipótesis editorial se convierta, por repetición, en una asignación de hecho.

Sin embargo, ensayar el siguiente estado exige artefactos completos. La pull request 50 estaba abierta, no marcada como borrador y sin fusionar en la respuesta capturada. Su cabeza, 577adce5255e7382e5d4b0c9e52be626deb77126, cambia 100–107 por 37–44 y regenera huellas, resultados KEM y vectores en 27 archivos.

Un anuncio de los autores habla de vectores con códigos “asignados”. Otro mensaje sobre rPGP dice que la implementación ya usa 37–44 y coincide con los vectores de NIST, aunque la actualización de la suite de interoperabilidad espera confirmación. Esa cautela está codificada en la merge request 255: permanece abierta, en borrador y sin fusionar, y señala que no debe incorporarse antes de la asignación oficial.

No hay contradicción insoluble. Hay tres relojes: el texto publicado, la rama que anticipa la próxima revisión y el registro que expresa una decisión formal. El problema aparece cuando un artefacto omite cuál de esos relojes está leyendo.

El identificador participa en el resultado

En la operación compuesta de KEM, OpenPGP extrae del paquete de clave pública el identificador del algoritmo y lo entrega como algId a multiKeyCombine. La salida es una clave de cifrado que sirve para envolver el material de clave de sesión. Si una parte usa 100 y la otra 37, la entrada no coincide; por tanto, tampoco la clave derivada ni el envoltorio, aunque los componentes ML-KEM y ECDH sean iguales.

Con los algoritmos de firma, el identificador también forma parte de los paquetes OpenPGP. Cambiar el byte altera el material serializado y las huellas calculadas a partir de él. El renumerado no redefine ML-KEM, ECDH ni las primitivas de firma y no demuestra una mejora o un defecto de seguridad. Sí modifica la vinculación protocolaria y los resultados reproducibles. Por eso la regeneración de vectores es una necesidad técnica, no una limpieza editorial.

Lo que el registro dice hoy

El registro OpenPGP de IANA capturado muestra fecha de actualización de 2 de julio de 2026. Los valores 35 y 36 aparecen vinculados al RFC 9980; 37–99 figuran como no asignados y 100–110 como privados o experimentales. En ese momento, llamar “asignados” a 37–44 describe el estado esperado por una rama, no el registro público.

El RFC 9580 ofrece el marco actual del formato y los registros de OpenPGP. El RFC 8126 define el lenguaje de las políticas de asignación. La conclusión de gobernanza es limitada pero importante: propuesta, consenso, edición, implementación y registro son actos diferentes. IANA no certifica la seguridad ni ordena desplegar; una casilla libre tampoco invalida la experimentación que la documenta correctamente.

La pieza que falta es un recibo unido a cada resultado. Debe declarar revisión y estado del documento, código experimental publicado, código propuesto en la rama, estado y commit de PR/MR, fila y fecha observada del registro, commit y hash de vectores, build probado, número utilizado y si ese estado admite un lanzamiento formal. Así, un vector de 100 conserva su valor histórico y uno de 37 prueba exactamente lo que dice, sin adelantarse al registro.

Fuentes