Resumen

  • RFC 3183 describió servicios experimentales de seguridad de dominio con S/MIME y asignó significados distintos a la firma del originador, la del dominio, la de revisión y la de atributos adicionales.
  • Una organización podía autenticar internamente al remitente y autorizar la salida, mientras que el receptor externo solo podía justificar el nombre del dominio si no conservaba una firma personal del originador.

La escena del guardia es importante porque evita empezar por un candado verde. El guardia recibe el mensaje, comprueba las condiciones de la política y emite una firma de revisión. Lo que queda probado es la aprobación para transmitir. No queda probado que el guardia sea autor, que el originador haya sido autenticado por esa firma, que el contenido sea verdadero ni que el destinatario lo haya recibido.

Esa precisión formaba parte de Domain Security Services using S/MIME, publicado en octubre de 2001 como RFC Experimental. RFC 3183 contemplaba agentes de transferencia, cortafuegos, guardias y pasarelas que podían crear o procesar objetos S/MIME por cuenta de una organización. Había varios motivos: usuarios sin PKI en el escritorio, sistemas internos incompatibles, almacenes que reformateaban el correo, inspección obligatoria o necesidad de auditoría en el perímetro. El documento no pretendía ganar la disputa entre seguridad de extremo a extremo y seguridad de dominio. Ofrecía mecanismos para políticas diferentes.

Esos mecanismos no componían una sola firma genérica.

La firma del originador vinculaba a la persona originadora con el contenido. La firma de dominio era una firma por delegación. Antes de crearla, el firmante de dominio debía autenticar al originador, verificando una firma interior o usando un mecanismo externo a S/MIME, y validar las firmas de las que dependiera. Si fallaba esa autenticación, la firma de dominio no debía producirse.

Sin embargo, lo que el dominio sabía y lo que el receptor podía mostrar seguían siendo capas distintas. Con una firma personal del originador, el certificado podía proporcionar el nombre individual. Sin ella, RFC 3183 limitaba la suposición del receptor al dominio de origen. El sistema interno quizá sabía exactamente qué empleado estaba detrás del mensaje; fuera de la frontera viajaba una atestación verificable del dominio, no necesariamente una identidad personal certificada.

La diferencia parece pequeña hasta que una interfaz afirma «Ana envió esto» basándose en una evidencia que solo dice «el dominio X liberó esto después de sus controles». La primera frase es una atribución personal pública. La segunda describe una decisión institucional y una observación criptográfica. Puede existir una relación correcta entre ambas, pero requiere conservar el método de autenticación interno y la cadena que la justifica.

La firma de revisión introducía un segundo eje: permiso de circulación. Un revisor puede reconocer riesgos, aplicar una norma y aprobar el paso sin afirmar autoría. Tampoco certifica automáticamente legalidad, exactitud o seguridad. Convertir la revisión en verdad sustantiva sería usar una prueba válida para responder a una pregunta diferente.

La firma de atributos adicionales resolvía otra pregunta. Vinculaba atributos incluidos en SignerInfo con el mensaje. Así era posible demostrar que una autoridad concreta había unido ciertos datos a cierto contenido. No demostraba por sí sola que el hecho externo representado por un atributo fuera correcto, vigente o suficiente para una decisión posterior. Firmar una etiqueta demuestra la unión de la etiqueta; no hace verdadera la realidad descrita.

RFC 3183 utilizó el atributo firmado SignatureType para marcar estas funciones. El Erratum verificado 3757 añadió el identificador que faltaba en el texto: id-aa-signatureType, 1.2.840.113549.1.9.2.28. La corrección permite que el software identifique el atributo sin ambigüedad. No amplía su significado: tipar una prueba ayuda a impedir que revisión, dominio, originador y atributos se intercambien.

Después aparece la custodia del secreto. Una autoridad de confidencialidad de dominio podía cifrar para usuarios o descifrar en su nombre. La solución desplazaba claves y texto claro hacia la frontera. Una clave de dominio comprometida tenía un radio de daño mayor que una clave individual. Cuando la autoridad receptora descifraba, el texto claro existía a partir de ese punto. Y si esa autoridad estaba comprometida, el usuario no podía deducir la integridad del mensaje solo porque la misma autoridad declarara que la había verificado; necesitaba una firma independiente que sobreviviera y pudiera comprobar.

Los objetos anidados hacían visible esta cadena de custodia. Una pasarela podía verificar una capa, descifrar otra, retirar un envoltorio, conservar atributos, añadir una firma de dominio, volver a cifrar y preservar el historial de expansión de una lista en una capa adicional. Por eso «el mensaje está firmado» era una descripción insuficiente. Había que preguntar qué bytes, bajo qué tipo de contenido, firmó quién y antes o después de qué transformación.

Las especificaciones contemporáneas de S/MIME, CMS y Enhanced Security Services proporcionaban los contenedores. RFC posteriores actualizaron CMS, S/MIME y el contexto PKIX. Son contexto técnico, no evidencia de que RFC 3183 se desplegara ampliamente ni de que dejara de ser Experimental. El registro de IANA acredita una asignación de identificador; tampoco prueba uso real.

La importancia histórica reside en que la frontera no era un simple tubo. Era un lugar donde distintas autoridades tomaban decisiones diferentes. El originador producía. El dominio autenticaba y liberaba. El guardia aprobaba el tránsito. La autoridad de atributos vinculaba datos. La autoridad de confidencialidad abría o cerraba el contenido. El receptor observaba un resultado. Conservar esos verbos es conservar responsabilidad.