Cela se saurait si il y avait une solution universelle.
Le PGP/GPG l'est beaucoup moins que les certificats X509 pki, principalement pour des raisons historiques.
Les X509 pki sont plus anciens et ont plus de support dans les services. C'est juste un constat. cqfd
Quant à la fiabilité, PGP/GPG est équivalent lorsque le cercle de diffusion est faible ou limité dans un contexte.
Ensuite, concernant la messagerie, ce qui est ressentie comme une authentification forte, pour l'utilisateur final de PGP/GPG, ne l'est pas, au niveau du service smtp. Lorsque une solution serveur se déporte sur le logiciel client de messagerie, comme si il s'agissait d'une solution cliente, cela pose énormément de problème d'optimisation. C'est le cas actuel avec le smime.
Tous les problèmes pratiques, d'ergonomie, de manque de portabilité, liés au SMIME, viennent du fait que le protocole smtp, ne le calcule pas, et que les variables liées (certficats et clefs ), ne remontent pas au service smtp. Ce n'est pas prévu. Le SMIME est vraiment une spécificité du MUA, logiciel de client de messagerie.
je prends un exemple, un chiffrement simple sans signature, avec du x509 pki; un message est chiffré pour tata en smime dans le but d'envoyer en commande DATA (session telnet smtp). Pour le gpg, le raisonnement est similaire en changeant openssl smime.
SMIME x509 simulé comme sur un MUA. Il n'y a pas encore de connexion ouverte sur le service smtp.
nano bonjour.txt
bonjour
...
A/
openssl smime -encrypt -outform smime -in bonjour.txt -out bonjour.p7 -from toto@domain.tld -to tata@domain.tld -subject "service smtp" -aes256 tata@domain.tld-cert.pem
ce qui donne cat bonjour.p7
To: tata@domain.tld
From: toto@domain.tld
Subject: service smtp
MIME-Version: 1.0
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"
Content-Transfer-Encoding: base64
MIIB1gYJKoZIhvcNAQcDoIIBxzCCAcMCAQAxggFOMIIBSgIBADCBsjCBrDELMAkG
....
ensuite requête cliente smtp sur un MTA, en injectant en data le smime
avec swaks +smime
B/
cat bonjour.p7 | swaks -f toto@domain.tld -t tata@domain.tld -d - mail.domain.tld
cat bonjour.p7 | swaks -f toto@domain.tld -t tata@domain.tld -d - mail.domain.tld
=== Trying mail.domain.tld:25...
=== Connected to mail.domain.tld.
<- 220 mail.domain.tld ESMTP Postfix
-> EHLO mail.domain.tld
<- 250-mail.domain.tld
<- 250-PIPELINING
....
<- 250 DSN
-> MAIL FROM:<toto@domain.tld>
<- 250 2.1.0 Ok
-> RCPT TO:<tata@domain.tld>
<- 250 2.1.5 Ok
-> DATA
<- 354 End data with <CR><LF>.<CR><LF>
-> To: tata@domain.tld
-> From: toto@domain.tld
-> Subject: service smtp
-> MIME-Version: 1.0
-> Content-Disposition: attachment; filename="smime.p7m"
-> Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"
-> Content-Transfer-Encoding: base64
->
-> MIIB1gYJKoZIhvcNAQcDoIIBxzCCAcMCAQAxggFOMIIBSgIBADCBsjCBrDELMAkG
-> A1UEBhMCRlIxETAPBgNVBAgTCFZBVUNMVVNFMQ4wDAYDVQQHEwU4NDEwMDEbMBkG
-> ..........
->
-> .
<- 250 2.0.0 Ok: queued as D205581B74
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with remote host.
c'est clair;
les variables liées au smime ne remontent pas au niveau du service smtp.
B/ ne connait pas le certif tata@domain.tld-cert.pem A/. Postfix ne le sait pas.
Bref, dans les requêtes clientes smtp, il manque les arguments -option_smime*, pour que ce soit optimisé, un truc qui n'est pas encore implémenté en smtp.
Une plus value au x509 pki, est l'authentification forte cliente, au niveau service, que le GPG/PGP ne sait pas faire nativement. Il faut passer par ldap ou des solutions plus ou moins compliquées, pour amener le gpg/pgp comme backend d'authentification. Franchement lourdingue ...
openssl s_client -connect smtp.domain.tld:port -starttls smtp -cert toto@domain.tld-cert.pem -key toto@domain.tld-key.pem
Par x509 pki, la connexion est sécurisée. Le serveur est authentifié. Le client est authentifié aussi. Postfix sait qui se présente. idem pour apache ...
Bien que le SMIME x509 pki, pourrait utiliser un certificat différent (signature), il est judicieux d'
aligner l'authentification forte cliente au service smtp, au SMIME du MUA.
