S/MIME frente a OpenPGP: firma y cifrado de correo

S/MIME frente a OpenPGP es la elección entre los dos estándares de seguridad de extremo a extremo para el correo electrónico. S/MIME (RFC 8551) envuelve los mensajes en la sintaxis de mensajes criptográficos (Cryptographic Message Syntax) e identifica a las personas con certificados X.509 emitidos por autoridades de certificación. OpenPGP (RFC 9580) usa su propio formato de paquetes y claves que sus propietarios generan y publican por su cuenta, y la confianza se establece mediante la comprobación de huellas digitales, las firmas de otros usuarios o el dominio del destinatario.

De un vistazo

Cómo es una firma

El script siguiente firma el mismo mensaje corto de las dos formas con GnuPG 2.5.21 y OpenSSL 3.6.5 y después verifica cada firma. Las claves y la CA desechable se crean en un directorio temporal y se borran al terminar.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
export GNUPGHOME="$dir/gnupg"
mkdir -m 700 "$GNUPGHOME"
printf 'Quarterly report attached.\n' > msg.txt

echo "== OpenPGP (GnuPG)"
gpg --batch --quiet --passphrase '' --quick-gen-key "Alice <alice@example.org>" ed25519 sign 1d
gpg --batch --quiet --detach-sign msg.txt
gpg --batch --verify msg.txt.sig msg.txt 2>&1 | grep -E "using|Good"
echo "signature bytes: $(wc -c < msg.txt.sig)"
gpgconf --kill gpg-agent

echo "== S/MIME (OpenSSL CMS)"
EC="-newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc"
openssl req -x509 $EC -keyout ca.key -out ca.pem -days 30 -subj "/CN=Example Mail CA" \
  -addext "keyUsage=critical,keyCertSign" 2>/dev/null
openssl req -x509 $EC -CA ca.pem -CAkey ca.key -keyout alice.key -out alice.pem -days 30 \
  -subj "/CN=Alice" -addext "subjectAltName=email:alice@example.org" \
  -addext "keyUsage=critical,digitalSignature" \
  -addext "extendedKeyUsage=emailProtection" 2>/dev/null
openssl cms -sign -binary -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out msg.p7s
openssl cms -verify -binary -in msg.p7s -inform DER -content msg.txt -CAfile ca.pem -out /dev/null
echo "signature bytes: $(wc -c < msg.p7s)"
openssl cms -sign -binary -nocerts -in msg.txt -signer alice.pem -inkey alice.key -outform DER -out bare.p7s
echo "without the embedded certificate: $(wc -c < bare.p7s)"
cd / && rm -rf "$dir"

== OpenPGP (GnuPG)
gpg:                using EDDSA key 57AE27428681EABC417A15B7DDA5B1FF5FAE8694
gpg: Good signature from "Alice <alice@example.org>" [ultimate]
signature bytes:      147
== S/MIME (OpenSSL CMS)
CMS Verification successful
signature bytes:      907
without the embedded certificate:      446

La diferencia de tamaño es estructural. Una firma CMS suele llevar el certificado del firmante, de modo que cualquier destinatario puede verificarla contra una raíz de confianza y guardar el certificado para cifrar las respuestas; incluso sin él, los atributos firmados, como la hora de la firma y el tipo de contenido, hacen que la estructura sea mayor. Una firma separada de OpenPGP identifica la clave por su huella digital, así que el destinatario ya debe tener la clave o buscarla. La huella digital de 40 caracteres indica que GnuPG creó una clave de versión 4; las claves de versión 6 del RFC 9580 usan huellas digitales SHA-256 de 64 caracteres.

Cómo decide cada uno en quién confiar

S/MIME delega la decisión en las autoridades de certificación. Desde el 1 de septiembre de 2023, los certificados S/MIME de confianza pública siguen los S/MIME Baseline Requirements del CA/Browser Forum: la CA debe verificar el control de cada dirección de correo electrónico, los tipos de certificado van desde los que solo validan el buzón (mailbox-validated) hasta los que validan a la persona (individual-validated), los perfiles «legacy», más laxos, ya no se pueden emitir desde el 15 de julio de 2025, y los certificados de suscriptor duran 825 días como máximo. Las empresas también pueden operar su propia CA y desplegar los certificados mediante la gestión de dispositivos, que es como funcionan la mayoría de los grandes despliegues de S/MIME.

OpenPGP deja la decisión en manos de los usuarios. La red de confianza original, en la que los usuarios firman las claves de los demás, nunca escaló más allá de comunidades pequeñas, y los servidores de claves públicos que aceptaban cualquier subida dejaron de servir para identidades no verificadas. La práctica actual es comparar las huellas digitales por un canal independiente, aceptar una clave en el primer uso o buscarla mediante un Web Key Directory, donde el propio dominio del destinatario sirve la clave por HTTPS. keys.openpgp.org solo publica identidades después de verificar la dirección.

Clientes, compatibilidad y la división de OpenPGP

El punto fuerte de S/MIME es la integración: Outlook, Apple Mail e iOS Mail firman y cifran de forma nativa en cuanto se instala un certificado, y Gmail ofrece S/MIME alojado en algunas ediciones de Google Workspace. OpenPGP es nativo en Thunderbird y Proton Mail, y en otros clientes está disponible mediante complementos.

OpenPGP tiene además una división de estándares. El IETF publicó el RFC 9580 en julio de 2024, con claves de versión 6, cifrado AEAD obligatorio y protección de la frase de contraseña con Argon2, y el RFC 9980 en junio de 2026 para las claves poscuánticas. GnuPG, en cambio, implementa LibrePGP, cuyas claves de versión 5 y cuyo formato de paquete OCB difieren del RFC 9580. Las claves de versión 4 con el paquete clásico de datos cifrados funcionan en todas las implementaciones; GnuPG puede pasar a su paquete OCB para los destinatarios cuyas claves anuncien que lo admiten, y las funciones del RFC 9580, como las claves de versión 6, hay que probarlas con el software de tus corresponsales.

Los dos estándares se vieron afectados por EFAIL (2018), en el que un texto cifrado manipulado hacía que los clientes de correo filtraran el texto descifrado a través de HTML. Las soluciones duraderas son el cifrado autenticado (AES-GCM en S/MIME 4.0, el código de detección de modificaciones y ahora AEAD en OpenPGP) y los clientes que se niegan a mostrar el texto en claro que no supera la autenticación.

Cuándo elegir cada uno

• Correo de empresa en dispositivos gestionados: S/MIME con certificados desplegados por MDM; deposita en custodia las claves de cifrado, nunca las claves de firma.
• Socios externos que ya tienen certificados S/MIME (sector público, banca, salud): S/MIME.
• Particulares, periodistas, mantenedores de proyectos de código abierto: OpenPGP, con las claves publicadas mediante WKD o keys.openpgp.org.
• Cifrado de archivos, copias de seguridad o secretos en lugar de correo: ninguno de los dos; usa age (consulta age frente a GPG).
• Firma de versiones de software y de commits: OpenPGP sigue funcionando, pero Sigstore y las firmas SSH suelen ser más sencillos (consulta Sigstore frente a la firma con GPG).
• Protección de la línea de asunto: elijas el que elijas, usa un cliente que implemente la protección de encabezados (RFC 9788); de lo contrario, el asunto viaja en claro.

Notas de migración

1. Despliegues nuevos de S/MIME: solicita certificados de perfil estricto (strict) o multipropósito (multipurpose) con la dirección en el nombre alternativo del sujeto, y separa las claves de firma de las de cifrado para que solo estas últimas queden en custodia.
2. Usuarios actuales de S/MIME: los certificados emitidos con el perfil legacy se van sustituyendo en la renovación; comprueba que los clientes de tus socios aceptan los perfiles nuevos antes de que caduquen tus certificados antiguos.
3. Claves OpenPGP: genera claves Ed25519 y X25519 (o claves de versión 6 si el software de todos tus corresponsales las admite), fija una caducidad de uno a dos años y prorrógala, guarda un certificado de revocación sin conexión y publica las claves mediante WKD.
4. Correo archivado: conserva las claves de descifrado o los certificados antiguos mientras necesites leer el correo antiguo; volver a cifrar el correo archivado es la única forma de retirarlos.
5. Planificación poscuántica: el correo cifrado está expuesto a «cosechar ahora, descifrar después» (harvest now, decrypt later). ML-KEM está especificado para CMS (RFC 9936) y, combinado con X25519, para OpenPGP (RFC 9980); planifica primero las claves de cifrado y después las firmas. El inspector de OpenPGP y el verificador de S/MIME muestran qué algoritmos usa una clave, un certificado o un mensaje.

Referencias

• RFC 8551, especificación de mensajes S/MIME 4.0
• RFC 5652, sintaxis de mensajes criptográficos (CMS)
• RFC 9580, OpenPGP
• RFC 9980, criptografía poscuántica en OpenPGP
• RFC 9936, ML-KEM en CMS
• RFC 9788, protección de encabezados para el correo electrónico protegido criptográficamente
• S/MIME Baseline Requirements del CA/Browser Forum (§6.1.5, §6.3.2, §7.1.6.1)
• OpenPGP Web Key Directory (borrador de Internet)
• EFAIL