Summary

  • AS2-From y AS2-To son identificadores de texto sensibles a mayúsculas acordados entre socios, no identidades universales derivadas de un certificado.
  • El borrador draft-ietf-ediint-rfc4130bis-04 exige separar el certificado TLS del certificado AS2 de firma o cifrado y proteger la distribución de este último con autenticación y autorización.
  • Una firma y un MIC correctos prueban una cadena concreta. No prueban quién aprobó que esa clave representara ese nombre, en esa dirección y relación.

La llamada que la PKI no puede sustituir

Cuando el certificado AS2 es autofirmado, la revisión 04 exige una verificación adicional fuera de banda antes de usarlo en producción. El ejemplo es confirmar la huella por un canal seguro. Esa llamada no mejora el algoritmo. Resuelve una cuestión institucional: conecta los bytes recibidos con una autoridad conocida del socio.

El texto es un Internet-Draft activo del grupo EDIINT. Así lo muestra el Datatracker; la API mantiene el estado I-D Exists, y el historial sitúa la revisión 04 el 24 de septiembre de 2026. Su destino declarado es Proposed Standard. Todavía no es un RFC y sólo sustituiría a RFC 4130 si fuera aprobado.

Un nombre AS2 es un acuerdo

La sección 6.3 permite números DUNS o cadenas elegidas por los socios. Los valores tienen entre 1 y 128 caracteres ASCII imprimibles, distinguen mayúsculas y minúsculas y aparecen en todos los mensajes y MDN. La respuesta refleja la pareja en sentido inverso.

Esa regla permite detectar que la respuesta corresponde a los nombres esperados. No demuestra que el nombre sea una razón social, un dominio o el sujeto de un certificado. Si el sistema no reconoce la pareja, puede responder con unknown-trading-relationship o unknown-trading-partner. Para hacerlo necesita una tabla local de relaciones; no existe en el borrador un registro mundial nombre-clave.

Un error frecuente consiste en tratar tres superficies como una sola. La primera es ese nombre bilateral. La segunda es el extremo HTTPS, protegido por TLS. RFC 8446 define TLS 1.3, RFC 9110 aporta la semántica HTTP y RFC 9525 sirve de contexto moderno para identidad de servicio, no de vínculo incorporado por el borrador AS2.

La tercera superficie es el mensaje. S/MIME y CMS, en RFC 8551 y RFC 5652, permiten firmar y cifrar; RFC 5280 representa la validación PKIX. El borrador exige que el certificado AS2 no sea el mismo que el de TLS. Un canal sano ya no puede usarse como atajo para decir que el documento fue firmado por la autoridad comercial correcta.

Entregar un certificado no asigna su papel

La sección 9.2 recomienda Certificate Exchange Messaging y remite al borrador CEM. Si se intercambia manualmente, deben garantizarse integridad y autenticidad antes de la activación. También cabe usar una URI Well-Known, pero la recuperación debe autenticar al solicitante y autorizar su acceso.

La distinción evita una falsa equivalencia. La firma del emisor protege el certificado contra alteración. No decide qué operador puede obtenerlo, a qué socio debe asignarse o si sirve para firma, cifrado, entrada o salida. La confirmación fuera de banda de una clave autofirmada hace visible esa decisión humana.

Una ficha de activación debería guardar nombre exacto, relación, dirección, uso, huella, serie, algoritmo, vigencia, origen, aprobadores, hora de entrada, solapamiento y clave de reversión. El borrador obliga a notificar de inmediato certificados caducados, revocados o no fiables. Pero “vigente y fiable” sigue siendo diferente de “autorizado para esta fila”.

El MDN no puede elegir su propia autoridad

El emisor conserva mensaje, Message-ID y MIC. El receptor devuelve un MDN que puede estar firmado. Se verifica la firma, se compara Original-Message-ID y se contrasta el MIC con el resumen guardado. RFC 8098 contiene el marco actual de MDN.

Es una prueba potente de recepción e integridad dentro de sus supuestos. El propio borrador usa “non-repudiation of receipt” tras verificar firma y MIC; aquí no se convierte esa frase en una conclusión jurídica universal. Tampoco se repite como tesis la diferencia entre entrega y aceptación de negocio, ya cubierta por otro artículo. La pregunta de esta pieza es anterior: ¿por qué la clave pública usada para verificar el MDN tenía autoridad sobre ese socio?

La escalera completa es: HTTP/TLS, nombres reflejados, validez de certificado, autorización local, firma, correlación Message-ID/MIC, disposición MDN, aceptación EDI y resultado comercial. Saltar la autorización hace que el resto sea preciso respecto de una premisa no documentada.

La revisión 03 ya contenía gran parte de estos controles. Por eso la afirmación prudente es que la revisión actual los codifica, no que los inventó todos. Las formas HTML y XML respaldan la lectura estructural, pero no demuestran despliegues.

Fuentes y límites

El expediente usa texto, HTML y XML de la revisión 04; página, API e historial del Datatracker; revisión 03; RFC 4130; RFC 8098; RFC 8551; RFC 8615; RFC 5652; RFC 5280; el borrador CEM; RFC 9110; RFC 9525 y RFC 8446. Para el análisis directivo se consultan aparte los ensayos de Lu Heng sobre primacía del código operativo, capas de realidad y especificación inicial mínima. No hay evidencia de un producto, incidente, ataque o litigio concreto.