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

["Michel Bouissou" <adresse@cachée>]

Bonjour Serge,

Merci de ta réponse détaillée,

Tu as écrit:

> 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 .

Je ne le pense pas. Tout d'abord, PGP dispose à travers le monde de centaines
de milliers d'utilisateurs (il suffit de regarder les stats de certains
keyservers pour s'en convaincre). Combien pour S/MIME ?
Si PGP a tardé à s'imposer en France, c'est un fait à imputer à l'interdiction
légale dont souffrait la cryptographie dans notre beau pays jusqu'au décret du
17 mars 1999, ce qui n'est pas si vieux.

PGP est un standard "de fait" au niveau mondial, et est employé dans de très
nombreux domaines en rapport direct avec Internet (comme par exemple la
validation automatique des groupes de news au niveau mondial, ou encore la
protection des domaines et des NIC-Handles déposés chez Network Solutions, au
RIPE ou chez GANDI, etc...) Tous ces organismes ont choisi PGP pour sa
diffusion, sa fiabilité, sa disponibilité multi-plateformes et sa réputation.
Ils n'ont pas choisi S/MIME...

En termes de diffusion / utilisation ou "confidentialité" du produit, comme tu
l'écris plus haut, j'utilise couramment à la fois PGP et S/MIME, et je 
constate
que j'ai infiniment plus de correspondants qui utilisent PGP que de
correspondants qui utilisent S/MIME...

Je suis moi-même certificateur (bénévole) pour le Web-of-Trust (X.509,
S/MIME...) gratuit de la société Thawte, et, dans cette activité, j'ai reçu
moins d'une dizaine de demandes sérieuses de certification en 9 mois
d'exercice, alors même que cette certification personnelle est gratuite, ce 
qui
en dit long sur l'utilisation de S/MIME par le public en France. Cependant, il
faut le reconnaître, la fréquence de ces demandes s'accroît très doucement.

Force est de constater que la notion même de certificat numerique X.509 est
absolument incompréhensible pour l'internaute lambda, et que la procédure
d'obtention de tels certificats auprès de sociétés tierces est un casse-tête
chinois. A tel point que je n'ai encore _JAMAIS_ rencontré aucun individu
non-informaticien qui utilise spontanément S/MIME... Même les informaticiens
qui l'utilisent sont une denrée rare ;-)

A contrario, je connais nombre de personnes qui, juste sensibilisées à
l'intérêt de la chose, ont installé PGP d'elles-mêmes et sont rapidement
parvenues à l'utiliser de manière correcte. Sans compétences informatiques
particulières.

> La notion de chiffrement asymétrique est insuffisante
> si on a pas le mécanisme de certification des clefs privées.

Le mécanisme de certification Web-of-Trust de PGP fonctionne parfaitement
depuis des lustres...

En matière d'abonnement à des listes de diffusion chiffrées, on pourrait
considérer que:

1) Une liste de diffusion chiffrée implique nécessairement un contrôle de
l'abonnement à la liste par le propriétaire de celle-ci (sinon quel intérêt à
chifffrer si n'importe qui peut s'abonner et donc faire chiffrer les messages 
à
son intention?)

2) Dans ce cas, on peut considérer que les clés PGP valides pour les abonnés
doivent soit être installées par le listowner lui-même, soit être signées par
lui. Ce qui résout le problème de la "certification" des clés.

> 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.

Certes, et c'est un argument de poids. MAIS...

1) Le support de PGP n'exclut pas S/MIME HTTPS pour autant ;-)

2) L'utilisation de HTTPS ne nécessite pas de certificat X.509 ni de S/MIME 
(on
peut toujours s'identifier par login / password par dessus une couche HTTPS
sans qu'une identification de la station cliente ne soit nécessaire)

3) Si l'interface Web de Sympa est EXTREMEMENT utile pour la gestion des 
listes
(listmaster, listowners) et pour l'abonnement / désabonnement des 
utilisateurs,
l'expérience montre toutefois qu'une fois abonnés à une liste, la plupart des
utilisateurs n'utiliseront pratiquement jamais l'interface Web, mais
échangeront simplement des mails avec la liste à laquelle ils sont abonnés. De
ce point de vue, les méthodes de chiffrement / authentification des messages
semblent bien plus cruciales que la question de l'interface Web.

> 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).

Oui, c'est un but louable, mais....

1) Est-ce vraiment nécessaire?

2) Quel pourcentage de listowners ressentiront la nécessité de
l'authentification forte de leur station-client, et surtout, combien seront
capables de mettre en place d'eux-mêmes les certificats nécessaires?

> 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:).

Il n'y a pas que Microsoft / Netscape / Eudora... Il y a bien d'autres outils,
comme par exemple StarOffice qui supporte PGP en natif mais pas S/MIME...

> 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.

GnuPG, le cousin GPL de PGP, est tout ce qu'il y a d'OpenSource...

Et, puisque nous parlons d'OpenSource, les implémentations de S/MIME dans les
clients Netscape et surtout Microsoft soulèvent bien des questions en termes 
de
crédibilité / sécurité / disponibilité des sources... Voir les récents CERT
advisories concernant l'implémetation de SSL dans Netscape par exemple.

A contrario, les utilisateurs de GnuPG ou PGP peuvent toujours disposer des
sources de leur outil de chiffrement, le contrôler, voire le compiler 
eux-mêmes
si tel est leur bon plaisir.

> > Ensuite, la cerise sur le gâteau, ça serait d'avoir un système de
> > mailing-lists chiffrées [...]
>
> 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.

Oui, encore qu'il me paraît nécessaire de subordonner l'abonnement à une liste
chiffrée à l'autorisation du listowner, comme je le mentionnais plus haut.

> - la liste ayant un certificat et une clef privée,

...qui ont été générés et installés comment ?

>    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.

Oui.

> - un message recu non crypté pour  la liste est diffusé en clair ;

Hum. peut-être faudrait-il une option permettant le rejet de tout message non
chiffré sur certaines listes. Ou de forcer le chiffrement du message même s'il
a été initialement reçu 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.

Oui.

On pourrait faire facilement la même chose aussi avec GnuPG, non...?

> C'est encore très loin du compte :
> - faire le cryptage pour la modération (par le web et par par mail).

Oui, il faut donc chiffrer pour la clé du modérateur.

> - 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 ?

Je dirais, puisque les messages sont reçus chiffrés pour la clé de la liste,
toujours les stocker tels quels. Au moment de l'envoi du digest, déchiffrer
puis chiffrer pour chaque destinataire du digest, comme pour l'envoi de
messages isolés...

> - que faire des archives en mode messagerie

Les garder chiffrées avec la clé de la liste. A réception d'une demande,
déchiffrer l'archive, puis la chiffrer pour le demandeur.

> - 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.

Hummm... Je dirais que des listes chiffrées vraiment sûres excluent de mon
point de vue la consultation d'archives par Web (et même la création 
d'archives
tout court ou de "digests").
Trouver un moyen de gérer des archives chiffrées dans une session Web me 
paraît
un important casse-tête, peut-être un truc à envisager un jour quand 110% des
autres fonctionnalités souhaitables pour Sympa auront été implémentées ;-)

Dans tous les cas, l'authentification du client peut être basée sur login /
password, sans nécessiter d'authentification du client (sauf pour des listes
paranos, qui ne voudront de toute manière surtout pas d'archives Web qui
traînent...)

> - 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.

Logique. Euh, actuellement, Sympa ne communique pas au sender d'un mail la
liste des envois échoués, de toute façon... Ou je me trompe?

> 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.

Ca serait bien, en effet. Mais note qu'avec S/MIME, ça serait un peu couillon,
vu le nombre d'exemplaires d'Outlook Express et de Netscape "mutilés" encore 
en
circulation, c'est à dire qui peuvent utiliser S/MIME pour signer mais pas 
pour
chiffrer/déchiffrer, ou dont le chiffrement est limité à 40 bits, ce qui est
dérisoire.

Tu risques donc soit de faire du chiffrement "faible", soit de chiffrer un
message que son destinataire sera incapable de déchiffrer.

Car, finalement, combien de personnes disposent en France d'un Outlook Express
ou d'un Netscape capable de faire du S/MIME (ou du HTTPS) à 128 bits ? Pas des
masses, je le crains. En tout cas pour le moment.

A contrario, avec PGP ou GnuPG, no problem. Si tu disposes de la clé PGP de 
Mr.
X, tu sais que tu peux chiffrer solidement avec, et que le propriétaire de la
clé sera en mesure de déchiffrer.

> Bref, il y a du pain sur la planche.

Oui, je vois ça ;-)))

Bon courage.

Cordialement.

Michel Bouissou <adresse@cachée> PGP DH/DSS ID 0x5C2BEE8F
Network Administrator - Internet Quake - http://www.i-quake.com