← RFC Reference

RFC 5751: Especificación de Mensajes S/MIME 3.2

Por Qué Existe

La seguridad de la capa de transporte (TLS, STARTTLS) protege el correo entre saltos, pero tiene límites:

• Los operadores del servidor pueden leer tu correo. TLS termina en cada servidor. El servidor de envío, el servidor de recepción y cualquier intermediario ven el contenido en texto plano.
• Sin garantía de origen. DKIM prueba que un dominio manejó el mensaje, pero no prueba qué persona lo escribió.
• Sin detección de alteración después de la entrega. Una vez que un mensaje se almacena en el servidor, las firmas DKIM pueden romperse si el mensaje se modifica. Las firmas S/MIME protegen el contenido en sí.

S/MIME proporciona cifrado de extremo a extremo (solo el destinatario puede descifrar) y firmas digitales (el destinatario puede verificar la identidad del remitente y que el contenido no fue alterado). Utiliza certificados X.509 de la misma infraestructura de clave pública que asegura HTTPS.

Cómo Funciona

Las Dos Operaciones

S/MIME envuelve mensajes MIME estándar en sobres criptográficos utilizando CMS (Sintaxis de Mensaje Criptográfico):

Puedes firmar solamente, cifrar solamente, o firmar-luego-cifrar (la combinación más común).

Firmar un Mensaje

El remitente usa su clave privada para crear una firma digital sobre el contenido del mensaje. Existen dos formatos:

• Firmado en claro (multipart/signed): El mensaje original es legible por cualquier cliente. La firma es una parte MIME separada. Los clientes que no son S/MIME ven el mensaje normalmente e ignoran la firma.
• Firmado opaco (application/pkcs7-mime): El mensaje y la firma se agrupan juntos. Solo los clientes S/MIME pueden extraer el contenido.

-- Estructura de mensaje firmado en claro --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

This is the original message content.
It is readable by any email client.

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
(CMS SignedData codificado en base64)
------sig--

Cifrar un Mensaje

El remitente cifra usando la clave pública del destinatario (del certificado X.509 del destinatario). Solo la clave privada correspondiente del destinatario puede descifrar:

-- Estructura de mensaje cifrado --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
(CMS EnvelopedData codificado en base64)

En la práctica, S/MIME utiliza cifrado híbrido: una clave simétrica aleatoria (p. ej., AES-128-CBC) cifra el mensaje, y la clave pública RSA/EC del destinatario cifra esa clave simétrica.

Detalles Técnicos Clave

Requisitos de Certificado

S/MIME se basa en certificados X.509 emitidos por una Autoridad Certificadora (CA). El certificado debe:

• Incluir la dirección de correo electrónico del remitente en el Nombre Alternativo del Asunto (SAN) o el campo Asunto.
• Tener el Uso Extendido de Clave (EKU) de emailProtection.
• Ser emitido por una CA en la que confíe el cliente del destinatario.

Esta es la barrera práctica más grande para la adopción de S/MIME: cada remitente necesita un certificado, y cada destinatario necesita el certificado público del remitente para verificar firmas o enviar respuestas cifradas.

Requisitos de Algoritmo (S/MIME 3.2)

SHA-1 y 3DES aún se mencionan para compatibilidad hacia atrás, pero se consideran débiles. S/MIME 4.0 actualiza significativamente estos requisitos.

Descubrimiento de Certificado

Para cifrado, el remitente necesita el certificado del destinatario. Métodos comunes de descubrimiento:

• Correspondencia anterior: Extrae el certificado de un mensaje firmado que el destinatario te envió.
• Directorio LDAP: Muchas organizaciones publican certificados en un directorio LDAP.
• DNS (SMIMEA/DANE): RFC 8162 define el descubrimiento de certificados basado en DNS mediante registros SMIMEA.
• Servidor de claves o puerta de enlace: Las puertas de enlace S/MIME empresariales gestionan certificados centralmente.

Errores Comunes

• Confundir S/MIME con TLS. TLS protege la conexión entre servidores. S/MIME protege el contenido del mensaje de extremo a extremo. Resuelven problemas diferentes y deben usarse juntos.
• Usar SHA-1 para firmas. SHA-1 es criptográficamente quebrado para resistencia de colisión. Siempre usa SHA-256 o más fuerte.
• Cifrar sin firmar. Un mensaje cifrado pero sin firma no prueba nada sobre la identidad del remitente. Siempre firma antes de cifrar para cifrado autenticado.
• Olvidar la distribución de certificado. No puedes enviar correo cifrado a alguien si no tienes su certificado público. Planifica el intercambio de certificado antes de implementar S/MIME.
• Usar certificados autofirmados. Los clientes de los destinatarios mostrarán advertencias de confianza. Usa certificados de una CA reconocida para interoperabilidad.
• No manejar destinatarios mixtos. Si algunos destinatarios tienen certificados S/MIME y otros no, necesitas enviar el mensaje dos veces: cifrado para los que tienen certificados, sin cifrar para los que no.
• Romper DKIM con firma opaca. Los mensajes firmados opacos reestructuran el cuerpo MIME, lo que puede invalidar los hashes del cuerpo DKIM. Los mensajes firmados en claro son más seguros para compatibilidad DKIM.

Impacto en la Entregabilidad

• Las firmas S/MIME pueden mejorar la confianza. Algunas puertas de enlace de correo empresariales verifican firmas S/MIME y tratan los mensajes firmados más favorablemente. Microsoft Outlook muestra prominentemente una cinta de confianza para firmas S/MIME válidas.
• El contenido cifrado es opaco para los filtros de spam. Los filtros de spam no pueden inspeccionar cuerpos de mensajes cifrados. Algunos filtros pueden tratar mensajes cifrados con sospecha, mientras que otros los dejan pasar. Para correo masivo, el cifrado S/MIME normalmente no es práctico.
• No es un reemplazo para SPF/DKIM/DMARC. S/MIME opera a nivel de usuario; SPF, DKIM y DMARC operan a nivel de dominio. Ambas capas sirven propósitos diferentes. S/MIME prueba identidad individual; DKIM prueba autorización de dominio.
• Cumplimiento empresarial. Las industrias reguladas (finanzas, sanidad, gobierno) a menudo requieren S/MIME. Soportar firmas S/MIME en correo transaccional puede ser un diferenciador para destinatarios sensibles al cumplimiento.

Related RFCs