Resumen

  • El orden normal de RFC 1991 era firmar junto a los datos literales, comprimir, cifrar con una clave de sesión, anteponer un paquete de esa clave por destinatario y, si hacía falta, envolver todo con ASCII Armor.
  • El CTB y las longitudes permitían recorrer el archivo; el CRC y los controles de clave detectaban fallos limitados. Esos resultados no autenticaban automáticamente al emisor ni el propósito del mensaje.
  • La firma de documento cubría los datos literales definidos, no todos los metadatos del paquete. Identidad, tiempo confiable, autorización y recepción requerían pruebas distintas.

Un expediente con varias jurisdicciones

Conviene imaginar el mensaje no como una caja fuerte, sino como un expediente con varias jurisdicciones. Primero aparece la firma y el paquete literal. Si se activa la compresión, ambos pasan a ser el contenido de un nuevo paquete. Después, una clave convencional de un solo uso cifra ese resultado. Cada destinatario recibe, delante del texto cifrado, su propio paquete con la clave de sesión cifrada mediante clave pública. El formato imprimible se agrega al final, alrededor del conjunto binario.

La secuencia decide qué puede afirmar cada comprobación. La firma se calcula antes de comprimir y cifrar. Cuando el receptor reconstruye el texto claro, verifica una relación entre una clave y los bytes interiores. No verifica el encabezado del correo, el recorrido por servidores o la capa ASCII exterior. El cifrado, a su vez, protege confidencialidad; no extiende la cobertura de la firma.

RFC 1991 ofrece un ejemplo incómodo para cualquier interfaz moderna. El paquete literal incluye modo, nombre de archivo sugerido, hora y datos. En una firma de documento sólo los datos literales forman parte del resumen firmado. Mostrar nombre y fecha bajo el mismo icono verde puede convertir una asociación visual en una afirmación que la criptografía nunca hizo.

Las firmas separadas y anidadas añaden otra diferencia. Una firma separada se calcula sobre un archivo externo, sin los campos de cabecera del paquete literal. Varios firmantes pueden producir firmas independientes. En una construcción anidada, el firmante posterior cubre también la firma anterior. El registro útil no dice sólo “válida”: identifica los bytes cubiertos y el orden de dependencia entre firmas.

El CTB declara una frontera

El Cipher Type Byte, CTB, abre la estructura de cada paquete. Codifica el tipo y cómo leer su longitud. Esa pequeña pieza permite que un programa avance por una concatenación, distinga datos literales, comprimidos o cifrados y encuentre el siguiente límite. Existe además una variante sin longitud explícita para datos comprimidos, que continúa hasta el final de la estructura que la contiene.

La ganancia histórica fue hacer procesable un objeto compuesto. Pero un CTB bien formado sólo demuestra conformidad sintáctica. La longitud correcta sólo demuestra que el lector llegó al límite anunciado. Ninguna de las dos asegura que el autor sea quien dice ser, que el algoritmo siga siendo aceptable, que no falte una envoltura exterior o que el contenido deba ejecutarse.

La forma indefinida subraya la dependencia: para saber dónde acaba hay que confiar en un límite superior. Un resultado local correcto no elimina una premisa equivocada sobre la estructura completa.

ASCII Armor era un adaptador de transporte

La infraestructura de correo alteraba o rechazaba con frecuencia los bytes binarios. ASCII Armor tomaba grupos de tres bytes y los representaba con cuatro caracteres imprimibles, evitando símbolos problemáticos. El bloque incluía cabecera, campos opcionales, cuerpo, un CRC de 24 bits calculado sobre el binario y una cola.

La apariencia de sello es engañosa. El RFC explica que los campos de cabecera del Armor pertenecen a la armadura, no al mensaje, y que pueden cambiar durante el transporte; por eso no deben contener información importante. Una aplicación informa de claves desconocidas bien formadas y sigue adelante.

La conclusión legítima del CRC es que los caracteres recibidos reconstruyeron un flujo compatible con esa comprobación de errores. No identifica al emisor y no impide que alguien sustituya todo el bloque y calcule otro CRC. Tampoco afirma que el contenido interior esté firmado. La capa de transporte resuelve un problema real precisamente porque no pretende resolver todos los demás.

Las señales internas de descifrado son locales

El texto cifrado convencional comienza con bytes aleatorios y repeticiones usadas para comprobar la clave. Tras descifrar, la coincidencia permite asumir que la clave de sesión es correcta. El paquete de clave pública también incluye una suma sobre la clave de cifrado de datos. Son atajos útiles para rechazar una ruta equivocada, no pruebas de que el uso de la clave privada estuviera autorizado.

El identificador de clave de 64 bits tampoco equivale a identidad. El propio RFC admite colisiones accidentales o maliciosas. Sirve para encontrar candidatos. Un sistema probatorio debe registrar qué material de clave se eligió, cómo se resolvió la colisión, su revocación o compromiso y la política que vinculaba la clave con una persona o función.

Incluso el tiempo firmado tiene un límite explícito. La hora ordinaria suele aproximarse a la creación, pero el usuario puede elegirla. Para una hora confiable, RFC 1991 describe una firma notarial separada sobre el paquete de firma. Validez matemática, frescura y momento jurídico son afirmaciones diferentes.

Un estándar histórico, no una coartada automática

El RFC Editor registra RFC 1991 como Informational, publicado en agosto de 1996 y posteriormente obsoleto por RFC 4880. El texto, el HTML y la ficha del IETF preservan la especificación; no prueban que toda implementación histórica siguiera cada detalle.

La entrada del IETF en el directorio sólo aporta navegación institucional; no demuestra que la organización respalde la interpretación de este artículo.

Los ensayos de Lu Heng sobre código en funcionamiento, especificación mínima y decisión localizada y capas de realidad se usan aquí como método editorial, no como fuente sobre el despliegue de PGP. Ayudan a formular la pregunta correcta: ¿qué observó de verdad cada capa, y quién intenta convertir ese dato limitado en autoridad institucional?

RFC 1991 deja una respuesta operativa duradera. La composición funciona cuando cada paso produce su propio recibo y ninguno habla en nombre del siguiente.