Re: S/MIME c'est bien, PGP c'est mieux ;-)

[Aumont - Comite Reseaux des Universites <adresse@cachée>]

> Bonjour,
> 
> Je viens de tester la validation de messages et de commandes par
> signature S/MIME sur mon Sympa, et ça m'a l'air de marcher ma foi
> plutôt bien :-)
> 
> Mais je me dis comme ça, pourquoi s'arrêter en si bon chemin, et ne
> pas également implémenter la vérification de signatures GnuPG ou PGP
> ?

Je ne suis pas un spécialiste du chiffrement capable de trancher
entre PGP et SMIME. Disons qu'on a des raisons de penser que PGP
est resté très (trop) confidentiel malgrès ses nombreuses années
d'existence . La notion de chiffrement asymétrique est insuffisante
si on a pas le mécanisme de certification des clefs privées. 

Par ailleur, la problématique n'est pas seulement celle du mail, mais
c'est aussi celle du WEB. S/MIME et HTTPS sont étroitement liés. En gros,
si on a l'un, on a l'autre. Et justement, sympa va avec son interface www.

Le but est bien entendu de faire un mapping entre la méthode
d'authentification S/MIME et l'authentification HTTPS avec certificat
du client (et non pas le simple canal crypté avec certificat du serveur).

> 
> Car, si S/MIME est une bonne option pour authentifier des messages
> dans le contexte de listes de diffusion, il me semble toutefois qu'il
> est encore très peu utilisé en France, complexe de mise en oeuvre
> pour l'utilisateur Lambda, et supporté par relativement peu de
> logiciels de mail.
C'est supporté par les clients netscape et microsoft. Tout est dit ou
presque. Bien entendu il y a eudora qui est à la traine. C'est une question
préoccupante pour eudora. (pas pour sympa:).

>                           De plus, son cousin GnuPG, compatible avec
> lui, est sous licence GPL et largement disponible dans le monde UNIX.
> Et GnuPG est capable de vérifier les signatures faites avec PGP...
> Alors, hmmm.... Ca s'rait pas une bonne idée, ça?
On ne veut pas condamner PGP, mais nos priorités ne sont pas là. A noter
que nos développements sont basé sur sur OpenSSL du monde OpenSource.

> 
> Ensuite, la cerise sur le gâteau, ça serait d'avoir un système de
> mailing-lists chiffrées permettant le chiffrement automatique des
> messages par Sympa en utilisant automatiquement les clés PGP ou les
> certificats S/MIME des abonnés à ces listes, clés et certificats qui
> seraient déjà présents sur le serveur.
> 
> Ca serait pas beau, ça?

On y travail. Cela marche commence à marcher avec S/MIME. En gros, voila
ou j'en suis :
- on configure une liste pour obliger l'abonnement avec signature S/MIME,
  ce qui permet de choper les certificats de tout les abonnés.
- la liste ayant un certificat et une clef privée, le message de bienvenue
  dans la liste est signé avec S/MIME, ce qui permet à chaque abonné d'avoir
  automatiquement le certificat de la liste.
- un message recu non crypté pour  la liste est diffusé en clair ;
  un message reçu crypté avec le certificat de la liste est décrypté puis
  recrypté pour chacun des destinataires avec le certificat de celui-ci.

C'est encore très loin du compte :
- faire le cryptage pour la modération (par le web et par par mail).
- que faire de la réception en mode digest quand il y a un mélange
  de messages en clair et de messages cryptés : tout crypter, ou
  ne laisser que les messages en clair ?
- que faire des archives en mode messagerie
- pour les archives en mode HTML : stoker le message sous sa forme cryptée
  ne le décrypter que pour le donner dans une session HTTPS avec
  authentification du client.
- et les traitements d'erreur ... faut communiquer au  sender d'un mail
  la liste des destinataires à qui on a pas pu envoyé son message crypté ?
  certainement pas si celui-ci n'a pas accès à la liste des abonnés.
- ...
 

Il faudrait aussi songer à signer/crypter les rapports de commandes de
sympa. Après tout, si une commande review est envoyée dans un mail signé,
ce serait bien de répondre en cryptant pour protéger la liste des abonnés.

Bref, il y a du pain sur la planche.

Serge Aumont