S/MIME est effectivement pris en charge nativement par davantage de clients qu’OpenPGP (du moins sur le desktop — pas sûr que beaucoup de clients mobiles prennent en charge l’un ou l’autre), mais :
– à l’usage, les interfaces utilisateurs pour S/MIME ne sont pas plus intuitives que celles pour OpenPGP ; leur seul avantage est qu’il n’y a pas de greffon à installer, mais je ne pense pas que ce soit l’installation de Enigmail qui pose le plus de difficultés aux gens ;
– ce n’est pas plus adapté qu’OpenPGP à l’utilisation dans un webmail ;
– surtout, ça ne change rien au problème majeur d’utilisabilité que représente la distribution des clefs.
Mettons qu’Alice vient de générer un certificat (OpenPGP ou X.509, peu importe, le problème est le même ; peu importe aussi qu’elle ait fait ça consciemment ou que son client de messagerie s’en soit chargé sans intervention de sa part). Comment le diffuse-t-elle auprès de ses contacts ? Et quand elle veut écrire à Bob, comment peut-elle obtenir automatiquement le certificat de Bob ?
Les serveurs de clefs sont une réponse possible, mais pas nécessairement la meilleure, surtout si l’on veut que tout soit automatisé : il peut y avoir douze mille clefs au nom de Bob bob@example.com sur les serveurs de clef, une intervention de l’utilisateur sera forcément nécessaire pour savoir laquelle choisir.
S/MIME est surtout utilisé dans un environnement restreint et contrôlé (dans une grande entreprise par exemple), où ces questions peuvent être résolues par une politique appropriée. Par exemple, lorsqu’on crée le compte du nouvel employé Bob, on génére automatiquement un certificat signé par la CA interne à l’entreprise. Le client mail d’Alice a été configuré par les administrateurs (avec interdiction pour Alice d’en utiliser un autre, d’ailleurs elle n’a pas les droits root sur sa machine) pour, d’une part, aller chercher automatiquement le certificat de Bob sur l’annuaire LDAP de la boîte, et d’autre part, faire confiance à la CA interne.
C’est cool, ça marche tout seul (enfin, du point de vue d’Alice et Bob, parce qu’en réalité, ça ne marche que parce qu’il y a un service IT derrière pour faire tout le boulot), mais ce n’est pas transposable au grand public.
[^] # Re: S/MIME
Posté par gouttegd . En réponse au journal Un client mail, automatisé GPG. Évalué à 5.
S/MIME est effectivement pris en charge nativement par davantage de clients qu’OpenPGP (du moins sur le desktop — pas sûr que beaucoup de clients mobiles prennent en charge l’un ou l’autre), mais :
– à l’usage, les interfaces utilisateurs pour S/MIME ne sont pas plus intuitives que celles pour OpenPGP ; leur seul avantage est qu’il n’y a pas de greffon à installer, mais je ne pense pas que ce soit l’installation de Enigmail qui pose le plus de difficultés aux gens ;
– ce n’est pas plus adapté qu’OpenPGP à l’utilisation dans un webmail ;
– surtout, ça ne change rien au problème majeur d’utilisabilité que représente la distribution des clefs.
Mettons qu’Alice vient de générer un certificat (OpenPGP ou X.509, peu importe, le problème est le même ; peu importe aussi qu’elle ait fait ça consciemment ou que son client de messagerie s’en soit chargé sans intervention de sa part). Comment le diffuse-t-elle auprès de ses contacts ? Et quand elle veut écrire à Bob, comment peut-elle obtenir automatiquement le certificat de Bob ?
Les serveurs de clefs sont une réponse possible, mais pas nécessairement la meilleure, surtout si l’on veut que tout soit automatisé : il peut y avoir douze mille clefs au nom de Bob bob@example.com sur les serveurs de clef, une intervention de l’utilisateur sera forcément nécessaire pour savoir laquelle choisir.
S/MIME est surtout utilisé dans un environnement restreint et contrôlé (dans une grande entreprise par exemple), où ces questions peuvent être résolues par une politique appropriée. Par exemple, lorsqu’on crée le compte du nouvel employé Bob, on génére automatiquement un certificat signé par la CA interne à l’entreprise. Le client mail d’Alice a été configuré par les administrateurs (avec interdiction pour Alice d’en utiliser un autre, d’ailleurs elle n’a pas les droits root sur sa machine) pour, d’une part, aller chercher automatiquement le certificat de Bob sur l’annuaire LDAP de la boîte, et d’autre part, faire confiance à la CA interne.
C’est cool, ça marche tout seul (enfin, du point de vue d’Alice et Bob, parce qu’en réalité, ça ne marche que parce qu’il y a un service IT derrière pour faire tout le boulot), mais ce n’est pas transposable au grand public.