Summary

  • RFC 2440 definió muchas etiquetas de paquete OpenPGP, pero no un procedimiento ordinario para añadir otras de forma permanente: sus interacciones podían reducir la seguridad del protocolo completo.
  • Que hubiera números disponibles no equivalía a permiso. Los valores 60 a 63 quedaron para uso privado o experimental; las solicitudes nuevas debían llegar a los directores de seguridad del IESG o a un grupo de trabajo IETF competente.
  • En una firma, lo desconocido normalmente se ignoraba. El bit crítico permitía que el firmante prefiriese un error antes que perder silenciosamente el significado de una función. Reconocer no era implementar, y los metadatos no hasheados no eran prueba definitiva.
  • Las versiones posteriores formalizaron registros y revisión. Un número asignado, una lectura válida o una firma correcta siguen sin probar la seguridad de la composición ni su despliegue.

El hueco no resolvía la decisión

Imaginemos que una desarrolladora encuentra una etiqueta libre en un paquete OpenPGP. Dos clientes nuevos la escriben y vuelven a leerla; la prueba pasa. Los bytes caben. Pero ¿qué hará un verificador antiguo? ¿Puede una negociación desactivar la función? ¿Otro paquete cambia su sentido? ¿Puede una firma seguir siendo matemáticamente válida mientras se ignora la semántica nueva? La prueba local no responde.

Esa cautela aparece en la nota del IESG de RFC 2440, de noviembre de 1998. El documento definía muchas etiquetas, pero no un mecanismo normal para agregar otras. Aunque la cabecera de formato nuevo podía representar valores hasta 63, la especificación advertía que las interacciones entre funciones nuevas y existentes podían reducir mucho la seguridad general. Las solicitudes —por ejemplo, para nuevos algoritmos de cifrado— debían dirigirse a los directores de seguridad del IESG o a un grupo de trabajo apropiado. Los valores 60 a 63 eran privados o experimentales. Había espacio numérico, pero de ahí no nacía un proceso seguro de extensión.

OpenPGP no era una colección de algoritmos aislados. Los paquetes se combinan para formar claves, firmas y mensajes cifrados. Una función puede cambiar cómo un programa antiguo analiza una secuencia, cómo uno nuevo interpreta un campo heredado o qué cree el destinatario que cubre una firma. Una etiqueta puede estar disponible en la sintaxis mientras sus interacciones siguen sin estudiarse. RFC 2440 separó capacidad de codificación y autorización del protocolo.

Las firmas hicieron visible el límite

Los subpaquetes de firma presentaban la misma tensión en pequeño. Ignorar uno desconocido favorecía la compatibilidad: un programa antiguo podía procesar una firma que incluía metadatos nuevos. Por eso RFC 2440 recomendaba ignorar los tipos no reconocidos. Pero ese silencio podía borrar una función de la que dependía quien firmaba.

El bit 7 del tipo de subpaquete ofrecía una opción. Si marcaba como crítico un subpaquete desconocido, el evaluador debía considerar errónea la firma. El firmante podía preferir un fallo visible a una aceptación que descartara el significado. No era una garantía total: el evaluador tenía que conocer la regla y, aun reconociendo el subpaquete, podía no implementarlo. El estándar distinguía expresamente ambos estados.

Un dato reconocido junto a una firma válida tampoco adquiría necesariamente la autoridad de esa firma. Los subpaquetes podían estar en la sección hasheada o en la no hasheada. RFC 2440 advertía que la información no hasheada no era definitiva porque quedaba fuera de la firma propiamente dicha. El lector podía verla y el verificador analizarla, pero eso no la convertía en dato cubierto criptográficamente. Presencia, análisis, reconocimiento, implementación y cobertura eran estados distintos.

De la cautela al registro

RFC 4880, que reemplazó a RFC 2440 en 2007, creó registros explícitos de IANA y exigió consenso del IETF para nuevos tipos de paquete, considerados funciones importantes. También señaló riesgos de degradación y cambio de nivel en torno a las extensiones del mecanismo de detección de modificaciones. El proceso quedó más claro, pero interoperabilidad, implementación y análisis de seguridad no cabían en una sola casilla.

RFC 9580, publicado en 2024, reemplazó RFC 4880 y mantuvo procedimientos diferenciados. Algunos registros OpenPGP usan «Specification Required»; los tipos de paquete y ciertos espacios de versiones e identidades aplican «RFC Required». Sus expertos deben examinar las propiedades de seguridad esperadas y la interoperabilidad con implementaciones existentes. Es una respuesta institucional al vacío anterior, no prueba de que cualquier extensión aceptada sea segura en todos los entornos.

Los documentos no dicen que toda extensión sea dañina ni que todos los implementadores siguieran una única práctica. Muestran algo más acotado: en un protocolo criptográfico, añadir significado puede cambiar el comportamiento de rutas ya existentes. Un entero disponible es solo una dirección del formato. No prueba compatibilidad, cobertura criptográfica, comprensión del usuario ni seguridad operativa.

Fuentes