Resumen

  • RFC 5402 inserta CMS CompressedData en un mensaje EDIINT y permite que la compresión quede dentro o fuera de la firma, lo que cambia los octetos cubiertos por el MIC.
  • Los encabezados MIME, la canonicalización y Content-Transfer-Encoding pueden formar parte de la entrada; aplicar un hash al XML final no reproduce necesariamente la prueba recibida.
  • La evidencia debe conservar cada representación y su receta antes de inferir extracción, validez de la transacción o aceptación comercial.

El documento que entiende una persona llega al final

Una factura puede presentarse como un XML limpio en la interfaz. Antes de llegar allí quizá fue una entidad MIME, quedó dentro de CMS CompressedData, se unió a una firma, entró en un sobre cifrado y luego se representó en base64 para atravesar un transporte de siete bits. El camino inverso elimina capas, pero no vuelve irrelevantes los octetos intermedios.

RFC 5402, publicado en febrero de 2010 como documento Informational del Independent Stream, define cómo introducir compresión en los mensajes EDIINT de AS1, AS2 y AS3. Su nota IESG advierte que no pertenece al Standards Track y que debe evaluarse con cautela para implementación. El texto no certifica productos; describe reglas que permiten identificar exactamente qué se envió y qué debe comprobarse.

La lección operativa es directa. El contenido que una aplicación muestra es una representación semántica. El MIC es una afirmación sobre una secuencia definida de octetos. Ambas pueden referirse a la misma transacción sin ser intercambiables.

El orden decide qué se firmó

Para un documento firmado, RFC 5402 permite comprimir primero el cuerpo MIME interno y firmar la entidad comprimida. También permite firmar primero el cuerpo y comprimir después todo el multipart/signed. No permite hacer ambas cosas en el mismo documento, y el receptor debe admitir las dos.

En la primera forma, la firma cubre bytes de CMS CompressedData. En la segunda, cubre el MIME sin comprimir y queda protegida dentro de la compresión externa. La regla del MIC para mensajes firmados es seguir los mismos datos que fueron firmados. Por eso no existe una única respuesta universal a “¿cuál es el hash del archivo?”

Registrar sólo el valor deja abierta la interpretación. Se necesitan identificador del mensaje, orden de capas, rango firmado, algoritmo, canonicalización y etapa exacta. Si una herramienta exporta únicamente el XML final y un campo mic, una auditoría posterior no puede demostrar que ambos se relacionan como supone la interfaz.

Esta ambigüedad puede producir falsos positivos y falsos incidentes. Dos hashes diferentes pueden ser correctos para etapas distintas. Dos sistemas pueden mostrar el mismo XML aunque uno haya verificado un límite diferente o haya descartado encabezados que pertenecían a la prueba.

Base64 no es una envoltura inocente

El RFC explica que una parte comprimida binaria visible en un protocolo de siete bits como SMTP necesita base64. Si esa parte comprimida queda dentro de un contenido cifrado, no necesita su propia codificación de transferencia; la necesita la capa cifrada exterior.

Por tanto, la posición de base64 indica qué binario se expuso al transporte. Decodificarlo antes de guardar una copia puede eliminar la única evidencia de cortes de línea, truncamiento o transformación del agente de correo. Guardarlo sin identificar la etapa tampoco basta: el mismo mensaje puede tener bytes fuente, bytes comprimidos, bytes cifrados y bytes ASCII de transporte.

En los casos comprimidos no firmados, RFC 5402 calcula el MIC sobre el contenido descomprimido, incluidos los encabezados MIME y cualquier Content-Transfer-Encoding aplicable. RFC 4130 exige canonicalización para varios cálculos AS2. El investigador debe repetir la receta normativa, no inventar una forma “más limpia” del documento.

La práctica útil consiste en producir una cadena de huellas: MIME fuente, contenedor comprimido, sobre cifrado si existe, forma de transporte, salida descifrada, salida descomprimida y adjuntos extraídos. Cada huella tiene un nombre de etapa y una relación verificable con la anterior.

ZLIB identifica un decodificador, no una política completa

RFC 5402 exige ZLIB, basado en DEFLATE. RFC 3274 define el tipo CMS y el identificador del algoritmo. Los niveles de compresión siguen siendo compatibles, de modo que no se codifican como parámetro. Sin embargo, el propio RFC 3274 admite que el campo de parámetros pueda aparecer omitido o como ASN.1 NULL por razones históricas.

Un producto que reconoce una sola forma puede fallar ante un mensaje compatible. Otro puede tolerar ambas formas pero aplicar límites distintos. Además, la capacidad de descomprimir no determina dónde se coloca la capa, cómo se canonicaliza MIME o qué error se devuelve.

RFC 5402 exige AS2 o AS3 versión 1.1 o superior para el perfil. Ese encabezado declara una versión. No es un recibo de que el interlocutor haya usado la configuración esperada en esta transacción. También debe existir acuerdo entre socios, configuración activa y evidencia del procesamiento observado.

La diferencia importa cuando se actualiza una biblioteca. Si el sistema sólo conserva “ZLIB=true”, una regresión de parámetros, tamaño o orden aparecerá como fallo inexplicable del socio. Conservar la forma literal permite probar el cambio.

decompression-failed delimita el fallo

Cuando la descompresión falla y se pidió recibo, RFC 5402 incorpora Error: decompression-failed al MDN firmado. Un informe negativo firmado sigue siendo una pieza fuerte: atribuye al receptor una imposibilidad concreta y evita que el silencio se convierta en especulación.

No autoriza a decir que la factura fue rechazada por su contenido. El sistema quizá nunca obtuvo la factura. Tampoco identifica por sí solo la causa: puede haber datos dañados, un límite local, un algoritmo mal interpretado o una representación alterada.

RFC 4130 exige devolver un recibo firmado aunque el procesamiento del contenido encuentre un error, y advierte que la transacción puede no ser válida. El MDN confirma su propia disposición. Debe abrir una investigación en la etapa correspondiente, no cerrar el flujo con una sentencia comercial.

La corrección es conservar los bytes de entrada, el identificador del algoritmo, la traza de capas y el error preciso; después se decide si retransmitir, cambiar el perfil o escalar el acuerdo. Traducir todo a “rechazado” impide saber qué se debe reparar.

Un cuerpo multipart añade una segunda frontera

RFC 6362 permite varias piezas en multipart/related. Para mensajes comprimidos no firmados, el MIC se calcula sobre todo el cuerpo multipart descomprimido, canonicalizado según el transporte. Si el MIC no coincide, se consideran inválidas todas las piezas y se retransmiten.

Esa regla protege el conjunto, no valida el significado de cada elemento. Después de extraerlo, un XML puede fallar el esquema, un PDF puede carecer de una firma requerida y una imagen puede no corresponder a la orden. El almacenamiento y el procesamiento de los documentos quedan en manos de la implementación.

La base de datos necesita un registro padre para el sobre y registros hijos para cada pieza. El padre contiene la prueba criptográfica común; cada hijo conserva Content-ID, tipo MIME, hash extraído, validación y decisión de aplicación. Sin esa relación, una retransmisión puede duplicar piezas ya procesadas o una aplicación puede heredar una certeza que nunca se midió.

La aceptación comienza después del recibo

Un recibo AS2 firmado puede acreditar que el socio recibió el intercambio, verificó su integridad y, en mensajes firmados, autenticó al remitente dentro de la política aplicada. El original-message-id enlaza el informe con el envío y Received-content-MIC enlaza el límite de bytes.

Todavía faltan preguntas de negocio: ¿se extrajeron todas las piezas?, ¿pasaron la sintaxis?, ¿la orden era nueva?, ¿tenía autoridad el comprador?, ¿había crédito?, ¿el sistema de inventario la aceptó?, ¿se emitió una aceptación contractual? Ninguna surge de la igualdad de dos digests.

Las fuentes no muestran una adopción actual, una cuota de proveedor ni un incidente concreto. Sí fijan un principio reproducible: nunca reconstruir el MIC a partir de lo que resulta cómodo mostrar. Primero se identifica la representación; después se decide qué conclusión admite.