Resumen

  • RFC 1421 situó PEM en los extremos, junto al agente de usuario, para que los relés SMTP ya instalados transportaran el objeto sin interpretar su criptografía. La protección no abarcaba todos los encabezados ni los cambios realizados entre esos extremos.
  • MIC-CLEAR aplicaba autenticación e integridad como MIC-ONLY, pero omitía la codificación imprimible que aislaba el texto de cambios del sistema de transferencia. Quien no tenía software PEM podía leer el cuerpo, aunque no validar su firma.
  • El MIC se calculaba sobre ASCII canónico con finales CRLF. Una conversión ordinaria podía producir un fallo auténtico sin demostrar por sí sola un ataque. El resultado, la causa y la clasificación de seguridad debían conservarse por separado.

El problema histórico no era hacer que un mensaje pareciera una carta sellada. Era decidir qué parte exacta de un sistema de correo heterogéneo podía convertirse en objeto verificable sin obligar al resto de la red a cambiar a la vez.

En febrero de 1993, el correo de Internet atravesaba agentes de usuario, servidores de transferencia y pasarelas con representaciones locales distintas. Un equipo podía usar una convención de líneas y el siguiente otra. Un reenviador podía envolver el contenido, añadir comentarios o cruzar a un sistema ajeno a SMTP. La seguridad de extremo a extremo tenía que convivir con esas máquinas, no imaginarlas ausentes.

RFC 1421 colocó el procesamiento de Privacy Enhanced Mail en el agente de usuario o por encima. El remitente convertía el cuerpo antes de entregarlo al sistema de transferencia; el destinatario lo recuperaba y verificaba al final. Los relés intermedios podían seguir funcionando sin conocer PEM.

La instalación local se volvió posible, pero la frontera también quedó expuesta. Los campos añadidos o transformados por los relés no recibían protección. El objeto firmado vivía dentro del texto del mensaje exterior. No incluía automáticamente toda la envoltura, los campos de traza ni las decisiones de encaminamiento.

Por eso una pieza de correo tenía más de una realidad. Estaba la aceptación SMTP, la historia de encabezados, la secuencia de transformaciones del objeto PEM, el cálculo criptográfico y la eventual lectura. Ninguna de ellas podía sustituir a las demás.

La red común transportaba; los extremos juzgaban

RFC 1421 quería evitar modificaciones previas y generalizadas de los protocolos de correo. También declaró una preferencia: aumentar las capacidades del usuario en lugar de imponer restricciones que le impidieran enviar texto sin protección. No presumía agentes de usuario universalmente confiables.

El reparto redujo el coste político y técnico de entrada. Un operador SMTP no tenía que adoptar una nueva autoridad criptográfica. Un usuario o sitio podía añadir PEM en su extremo. Pero el remitente adquiría otra obligación: saber si el destinatario podía deshacer la codificación o el cifrado seleccionados y compartir un mecanismo de claves compatible.

La existencia de una dirección no ofrecía esa prueba. Tampoco la respuesta positiva de un servidor a RCPT TO. Esos hechos mostraban que una etapa de transporte aceptaba un destinatario; no que la aplicación final entendiera la transformación PEM.

El propio RFC enumeró lo que quedaba fuera: control de acceso, confidencialidad del flujo, exactitud de las direcciones, control de ruta, prueba y no negación de recepción, asociación automática de acuses, detección de duplicados y prevención de repetición. Firmar un cuerpo no permitía atribuirle todas las garantías posibles del correo.

La pantalla mostraba texto; el MIC comparaba bytes canónicos

El proceso partía de la forma local del host. Para crear una referencia común, PEM convertía el cuerpo a ASCII con finales de línea CRLF, semejante a la representación inter-SMTP. El relleno de puntos propio de SMTP no formaba parte de esa forma canónica.

Sobre ella se calculaba el Message Integrity Check. Si el tipo exigía confidencialidad, también se cifraba. El documento resumió la cadena general como Encode(Encrypt(Canonicalize(Local_Form))), retirando las operaciones no aplicables. El receptor invertía los pasos antes de convertir el resultado a su formato local.

La firma, por tanto, no recaía sobre una noción humana de “el mismo párrafo”. Recaía sobre la salida de una reconstrucción. Dos cuerpos visualmente iguales podían contener diferencias de bytes. Un cuerpo de tránsito visiblemente distinto podía volver al objeto firmado si cada cambio externo era conocido y reversible.

RFC 822 describía encabezados y un cuerpo opcional de líneas ASCII. RFC 821 definía la transferencia DATA y la transparencia SMTP. RFC 1421 aprovechó esa gramática familiar, pero aclaró que la forma canónica era un modelo para la criptografía, no una prueba de un tránsito concreto.

El precio de leer sin herramientas

Los tres tipos principales repartían el precio de modo distinto. ENCRYPTED combinaba confidencialidad, autenticación e integridad; tras cifrar, utilizaba una representación imprimible restringida para atravesar sistemas diversos.

MIC-ONLY no ocultaba el contenido desde el punto de vista criptográfico, pero todavía lo codificaba. Esa capa protegía la representación firmada frente a cambios habituales del transporte. El lector necesitaba PEM para recuperarla y comprobarla.

MIC-CLEAR conservaba los servicios de autenticación e integridad de MIC-ONLY y retiraba la codificación imprimible. El cuerpo quedaba a la vista. Un destinatario sin PEM entendía el mensaje, pero no podía verificar la firma que lo acompañaba.

RFC 1421 no suavizó esa diferencia. Legibilidad era acceso al significado. Verificabilidad requería los campos de control, una ruta de claves válida, la forma canónica correcta y un MIC coincidente. El primero podía existir mientras el segundo seguía siendo desconocido.

Ahí apareció una asimetría que ninguna suma criptográfica resolvía: el ser humano podía creer y actuar antes de que la aplicación terminara de justificar el origen. Mantener el texto abierto exigía mantener también abierta la condición de su autoridad.

Un fallo podía ser exacto y su explicación seguir incompleta

La codificación de MIC-ONLY buscaba soportar modificaciones dentro del sistema de transferencia. MIC-CLEAR la omitía. Su firma sólo podía validarse cuando el camino no había cambiado el texto, o cuando el receptor podía identificar y deshacer los cambios.

Las terminaciones de línea eran el caso básico. El sistema receptor podía convertir CRLF a su convención local antes de entregar el cuerpo al módulo PEM. Para verificar, ese módulo tenía que recanonizar el texto y recuperar la representación inter-SMTP sobre la que se calculó el MIC original.

El reenvío añadía otra conversión. RFC 1421 adoptó las fronteras de RFC 934. Una línea de MIC-CLEAR iniciada por guion podía recibir para no confundirse con un delimitador. El MIC se calculaba antes de añadir ese escape. La capa de envoltura debía retirarlo antes de la comparación.

Si la comparación fallaba, había una divergencia demostrada. No había todavía una causa demostrada. Un atacante podía haber alterado el cuerpo; una pasarela inocente podía haber aplicado una transformación imposible de invertir. RFC 1421 dijo por eso que un fallo de MIC-CLEAR no significaba necesariamente un incidente de seguridad.

La interfaz debía informar el tipo de mensaje junto con el fallo. Para mensajes sintácticamente válidos cuyo MIC no coincidiera, no era apropiado mostrar el contenido como confiable sin avisar que autenticidad e integridad no estaban garantizadas y obtener una confirmación positiva del usuario. La prudencia no consistía en ocultar el dato, sino en impedir que el dato fingiera ser un veredicto total.

Ni el borde ni la cercanía firmaban lo que estaba fuera

Los controles PEM residían en un encabezado encapsulado dentro del cuerpo exterior. Podían existir anotaciones no protegidas antes o después, varios objetos protegidos y capas anidadas. La proximidad visual no ampliaba la cobertura del MIC.

Un resultado válido tampoco certificaba el encabezado SMTP, la lista de direcciones, la ruta, el buzón final o la lectura humana. Sólo establecía una relación entre un objeto canónico, un MIC y una ruta de claves. La autoría de una persona, la recepción, el consentimiento y la acción exigían pruebas posteriores.

RFC 1423 separó algoritmos, modos e identificadores del procedimiento general. Esa modularidad dejó una superficie reemplazable, pero no convierte sus opciones de 1993 en recomendaciones actuales. RFC 1421 y RFC 1423 tienen hoy estado Histórico.

La lección de MIC-CLEAR no es que la compatibilidad venciera a toda modificación. Es que el sistema pudo preservar la red común y el acceso humano sólo si admitía dónde aparecía la deuda. Cada cambio tenía que ser reversible, atribuible o reconocido como una pérdida de evidencia. El correo seguía legible; el verificador cargaba con su historia.