gouttegd a écrit 1805 commentaires

Donc si ton mot de passe est suffisamment fort, et si ta clé respecte les standards de sécurité actuels, il semble peu probable qu'elle soit utilisable par un attaquant.

Par défaut avec OpenSSH, la clef AES avec laquelle la clef privée est chiffrée est dérivée de la phrase de passe par une seule itération de la fonction MD5. Il y a intérêt à ce que la phrase de passe soit vraiment forte pour que ça arrête un attaquant…

OpenSSH 6.5 a introduit un nouveau format de stockage des clefs privées, avec lequel la clef de chiffrement est dérivée de la phrase de passe par 16 itérations (par défaut) de bcrypt, ce qui bloque plus efficacement les attaques par force brute.

Donc, si vous utilisez OpenSSH 6.5 au moins, assurez-vous de générer vos clefs dans ce nouveau format, avec l’option -o de ssh-keygen :

$ ssh-keygen -o -b 2048 -t rsa -f ma_nouvelle_clef

ou convertissez vos anciennes clefs vers ce nouveau format :

$ ssh-keygen -o -p -f mon_ancienne_clef

(Ce changement n’affecte que la clef privée et ne concerne donc que le côté client. Une clef stockée dans ce format peut toujours être utilisée pour se connecter à un serveur OpenSSH antérieur à la version 6.5.)

Je bricole pas mal avec le langage de macro d’ImageJ, qui est loin d’être mon langage préféré mais qui m’est plus ou moins incontournable, puisque mes collègues et moi-même sommes de gros utilisateurs de ce logiciel.

Du coup, j’ai répondu Java, parce qu’ImageJ est écrit en Java et qu’il m’arrive d’y toucher aussi, pour des tâches trop complexes pour être implémentées avec le seul langage de macro.

Mais je saisis le moindre prétexte pour faire des trucs en Python.

Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.

En revanche, par défaut Thunderbird ne compose pas en format flowed, et l’option pour le faire n’est, à ma connaissance, accessible que par le about:config, en mettant la clef mailnews.send_plaintext_flowed à true.

(Si tu veux critiquer l[e manque d’]ergonomie de Thunderbird, on peut sûrement tomber d’accord. ;) )

D’autre part, dire que la limitation de 65 caractères est pertinente est une connerie, on code pas une information d’affichage dans le format

D’accord en théorie, mais après il faut se mettre à la place des rédacteurs du RFC 5322 (et des RFC qui l’ont précédé) : ils étaient plus ou moins obligé de tenir compte du fait qu’il existe des implémentations qui font n’importe quoi lorsqu’un message comportaient des lignes trop longues… D’où l’introduction de la recommandation, pour un émetteur, de ne pas dépasser 78 caractères par ligne :

Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
[…]
The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification.

(La limite à 65 caractères découle de cette limite à 78 caractères, pour se ménager suffisamment de niveaux de citations — mais cette limite-là n’a jamais été imposée par un quelconque standard, seulement par la Netiquette qui n’est que « pour information ».)

Ajoutons à celà qu’après cette recommandation de ne pas dépasser 78 caractères par ligne, il y a ensuite une obligation de ne pas dépasser 998 caractères (cette limite-là vient tout droit du protocole SMTP), et le « bidouillage » du format=flowed devient logique : il permet de séparer clairement les retours à la ligne qui ne sont là que pour respecter le protocole, de ceux qui sont là pour exprimer la volonté de l’auteur du message d’aller à la ligne.

Ce « bidouillage » a aussi l’avantage de permettre un affichage à peu près correct du message même avec un client qui ne prend pas en charge le format flowed, ce qui est déterminant et trop souvent oublié par ceux qui proposent une « solution » peut-être bien meilleure et plus propre techniquement mais condamnée à l’échec parce qu’elle nécessite un support de la part de tous les acteurs…

Le problème c’est que Thunderbird est capable d’éditer en HTML et envoyer en texte, mais faut préciser pour chaque courriel d’envoyer en format texte si on réponds à un courriel en HTML.

Euh, non. Edit → Account settings, rubrique Composition & Addressing, décocher Compose messages in HTML format. Peu importe que le message auquel tu réponds soit en HTML, ta réponse sera en texte brut.

Si on m’envoyait des courriels en texte brut sans colonne à taille fixe et que mon courrielleur était capable de couper automatiquement les lignes, ça me plairait bien.

Je vais me répéter une dernière fois : format=flowed. C’est précisément à ça que ça sert.

Le format texte brut « de base » n’impose aucun format, sauf la longueur des lignes. Donc on a inventé le format flowed pour supprimer l’inconvénient des lignes de longueur fixe, tout en gardant les autres avantages du format texte.

1) personne n’envoie des courriels au format texte sans couper les lignes à taille fixe

Non, mais certains (moi par exemple) les envoie au format texte flowed, qui autorise ton client à recouper les lignes comme bon lui semble.

2) je crois que Thunderbird ne coupe pas les lignes automatiquement lors de l’affichage d’un courriel au format [brut]

Il le fait s’il est autorisé à le faire, c’est-à-dire si le format n’est pas seulement text/plain, mais text/plain; format=flowed. Si l’expéditeur n’a pas formatté son mail en format=flowed, Thunderbird n’y est pour rien.

Oui moi aussi, mais si je dois couper le texte en plusieurs bouts pour citer des parties c’est pas pratique.

Edit > Rewrap, ou Ctrl-R. De rien.

La théorie (oui mon truc à ligne fixe est géré par mon courrielleur) vs la réalité.

Évidemment, ce que moi je raconte c’est la théorie, alors que toi c’est la réalité.

le HTML c’est pratique (en plus c’est censé être sémantique)

Tout est dans le « censé ». Tu as déjà jeté un œil au code d’un mail HTML ? La plupart du temps il n’y a pas l’ombre de sémantique, c’est de l’HTML sorti tout droit de l’époque de HTML 3.2, rempli de <I>, <B>, <FONT>, et des mises en page réalisées à grand coups de <TABLE>… et encore, quand le message principal n’est pas dans des images embarquées !

C’est la théorie du HTML sémantique vs la réalité du HTML entièrement consacré à la forme.

Le problème est qu’on autorise trop de trucs, pas le HTML en lui-même…

Ah, ce n’est pas de la faute de l’HTML lui-même, mais de ceux qui s’en servent ? Donc tu seras d’accord que le problème du texte brut n’est pas le format lui-même, mais de ceux qui ne se servent pas de la disposition format=flowed ?

juste que dans l’état actuel des choses je préfère le HTML au texte brut (en particulier à colonne fixe) alors pas la peine de me dire que j’ai tort. À croire que le texte brut est une religion…

Pas la peine de faire l’offensé en déformant mes propos, nulle part je n’ai dit que tu avais tort de préférer HTML, je n’ai même pas critiqué HTML en lui-même. Je n’aime pas qu’on se serve pour m’imposer la manière d’afficher un mail dans mon client de messagerie, c’est tout.

En revanche, toi tu ne trouves rien de mieux pour défendre HTML que d’attaquer le texte brut, en lui inventant un défaut qui a été corrigé il y a seize ans ou en ignorant toutes les fonctions intégrées de longue date à n’importe quel client mail digne de ce nom. Tu peux comparer les utilisateurs du texte brut à des croisés (pendant que tu y es, dis carrément « adorateurs », ne te retiens pas), mais tu es pas mal dans le genre.

Je parlais de taille de ligne.

OK, dans ce cas la réponse est format=flowed.

C’est un peu ironique de citer un document écrit en taille fixe. ;)

Oui, le format canonique des RFC est le texte brut avec un format de page fixe. Libre à toi de railler l’IETF et ses vieux barbus restés à l’âge de pierre (tu ne seras pas le premier), mais en attendant, les RFC des années 1980 sont toujours lisibles aujourd’hui avec le plus rudimentaire des éditeurs de texte (même le bloc-notes de Windows peut les lire). On verra en 2050 si on peut en dire autant d’un document écrit aujourd’hui dans un format « riche ».

Note quand même que le lien que j’ai posté est celui de la version HTML du RFC (voici la version texte), qui comme tu le vois n’empêche pas du tout l’auteur d’imposer la taille de ligne qu’il souhaite, contrairement à ce que tu penses.

… ou pas? En pratique je reçois des courriels qui prennent la taille qu’ils veulent sur mon écran et c’est bien relou.

Ou bien l’expéditeur n’utilise pas format=flowed, ou bien c’est ton client qui ne le prend pas en charge. Dans le deuxième cas, utilise un vrai client mail. Dans le premier, prend ton bâton de pèlerin et va dire à tes correspondants d’utiliser un vrai client mail (bon courage !).

Je sais que c’est une question de gout, mais bon mettre des chevrons au début de chaque ligne de texte citée je trouve ça un peu horrible au 21e siècle.

Mon client reconnaît automatiquement les citations (précisément grâce aux chevrons en début de ligne) et les affiche en retrait avec une petite barre bleue sur le côté. Magie du texte brut : c’est chez moi que les décisions de mise en forme sont prises, pas chez l’expéditeur qui peut écrire en pensant uniquement au fond et pas à la forme (les chevrons ne sont pas de la mise en forme, c’est du balisage sémantique pour dire « cette ligne est une citation, affiche-là comme tu veux »).

Taille fixée par la personne qui écrit le courriel

Là je dois forcément mal comprendre de quoi tu parles, parce que précisément en texte brut l’émetteur n’envoie aucune information de mise en forme (y compris la taille). C’est le destinataire qui choisit la taille de la police d’affichage dans son client de messagerie.

Retour à la ligne d’un ou deux mots à la fin de chaque ligne si son client ne coupe à la même longueur que le client de l’autre personne

format=flowed, spécifié depuis au moins seize ans. Enough said.

Moche

Question de goût. Pour ma part, je trouve que la plupart de ceux qui écrivent des mails en HTML ont des goûts tellement déplorables en matière de choix de police, de graisse, de soulignement et de couleurs, que je préférerai toujours le rendu du texte brut — il est peut-être moche mais au moins il est uniforme, et je choisis la taille, la police et la couleur, merci.

Ah zut, j’ai marché dedans.

Dans l'article lié, il est question d'authentifier les serveurs (known_host sur le client), alors qu'ici il s'agit d'autoriser l'accès (authorized_keys sur le serveur). Les deux fonctionne pareil (en adaptant les commandes), ou bien je n'ai rien compris ?

Les deux fonctionnent en effet de la même façon — c’est du moins ce que dit le manuel, pour ma part je n’ai pas essayé pour l’authentification des clients.

Sais tu s'il y a d'autre clients à part OpenSSH qui gèrent les certificats (au hasard Putty) ?

Ça n’a pas l’air d’être le cas de Putty en tout cas, et je n’utilise pas d’autre client que celui d’OpenSSH, donc je ne sais pas.

J’aurais pu préciser que ces certificats SSH sont une extension d’OpenSSH. Elle est documentée mais elle n’a pas fait l’objet d’une proposition de standard à ma connaissance.

(Il y avait bien eu une proposition pour utiliser des certificats X.509 avec SSH mais il n’y a pas eu de suite. Et de toute façon je crois que les développeurs d’OpenSSH ne voulaient pas implémenter X.509, c’est justement pour ça qu’ils ont créé leur propre format de certificats.)

Si je perds ma sous-clé, je me retrouve coincé dehors.

C’est pour ça que générer les sous-clefs (particulièrement la sous-clef d’authentification) directement sur la carte n’est pas forcément une bonne idée à mon avis, puisqu’il n’y a aucune sauvegarde possible.

Ce sera ma prochaine étape d'investigation mais saurais-tu si l'on peut renseigner la clé primaire et autoriser toutes sous-clés d'authentification valides liées à celle-ci ?

Pas à ma connaissance, et je doute que ce soit possible en l’état.

Il faut bien voir que le démon SSH, en face, ne voit rien d’autre qu’une clef SSH tout ce qu’il y a de plus habituelle. Il n’a aucune prise en charge pour OpenPGP, et les notions de clefs primaires et de sous-clefs (qui sont propres à OpenPGP) lui sont donc totalement étrangères.

Il est peut-être possible de faire quelque chose d’approchant avec Monkeysphere, mais

• ça ne fonctionne plus avec n’importe quel serveur SSH (il faut obligatoirement Monkeysphere sur le serveur) ;
• je n’ai jamais essayé.

Une autre approche serait d’utiliser des certificats SSH : tu génères une clef SSH servant d’autorité de certification, et tu l’utilises pour signer les clefs d’authentification. Sur le serveur, tu peux dès lors ne mettre dans le fichier ~/.ssh/authorized_keys que la clef publique de l’autorité de certification, et toutes les clefs signées par celle-ci seront acceptées (supprimant ainsi la nécessité de mettre à jour le fichier ~/.ssh/authorized_keys à chaque changement de clef). Idéalement, la clef de signature sera stockée sur un support hors-ligne dont tu ne la sors qu’au moment de signer une nouvelle clef (et tu feras ça sur une machine « air-gappée »).

L’avantage de cette approche est qu’elle ne nécessite pas de modification côté serveur (les certificats SSH, comme leur nom le laisse supposer, sont pris en charge nativement par OpenSSH). L’inconvénient dans le cas présent est qu’à ma connaissance, c’est l’agent GnuPG qui ne les gère pas — donc ce n’est pas utilisable, en l’état, avec une clef d’authentification stockée sur carte OpenPGP…

Je n’avais pas fait vu ça :

L'empreinte de la clé sera indiquée avec le label cardno:_#SERIE_

Tu parlais d’une clef stockée sur une carte OpenPGP ? (Dans le fond c’est logique, vu que c’est la suite de ton journal précédent).

Alors dans ce cas, ajouter le keygrip de la clef dans le fichier ~/.gnupg/sshcontrol n’est pas nécessaire (même si ce n’est pas gênant) : lorsque l’agent GnuPG détecte une clef dans le slot d’authentification de la carte, il la rend automatiquement disponible pour SSH.

On pourrait penser qu’ajouter explicitement le keygrip de la clef permet tout de même de préciser la durée pendant laquelle l’agent GnuPG doit garder le PIN en cache (en le spécifiant après le keygrip comme dans l’exemple donné dans le journal), mais il n’en est rien : l’agent GnuPG ne cache jamais le PIN d’une carte à puce (en fait, avec des clefs stockées sur une carte, tous les paramètres de l’agent GnuPG relatifs au cache sont sans effets).

Comme d’habitude, je vais chipoter apporter quelques précisions.

La prochaine étape est d'indiquer à GnuPG qu'il pourra utiliser notre clé d'authentification pour SSH. Pour cela on rajoute la poignée de la clé (keygrip) dans le fichier ~/.gnupg/sshcontrol.

Attention, cela n’est possible qu’à partir de GnuPG 2.1 (que vous devriez sérieusement envisager d’utiliser si vous en êtes encore à GnuPG 2.0 — et encore plus si vous êtes resté à GnuPG 1.4).

Si malgré tout vous devez utiliser GnuPG 2.0, la procédure pour charger une clef OpenPGP dans l’agent est plus tordue, puisqu’il faut d’abord convertir la clef dans un format utilisable par SSH. On peut pour ça utiliser l’outil openpgp2ssh, fourni par le projet Monkeysphere.

Le chiffre après la poignée est la durée en seconde que l'agent pourra garder la clé en mémoire. Si 0 la valeur par défaut est utilisée qui est de 30 minutes.

Ce n’est pas la clef que l’agent garde en mémoire, mais la phrase de passe nécessaire pour la déprotéger.

C’est d’ailleurs une différence de comportement par rapport à l’agent SSH « standard » (ssh-agent, tel que fourni par OpenSSH) qu’il est utile de noter, surtout pour ceux qui utilisaient déjà cet agent auparavant :

• L’agent OpenSSH ne garde les clefs qu’en mémoire, sous une forme déchiffrée. Conséquemment, il faut charger les clefs dans l’agent à chaque session, et la phrase de passe ne doit être fournie qu’une fois, lors du chargement.

• L’agent GnuPG garde les clefs sur disque sous une forme chiffrée, et cache en mémoire les phrases de passe. Une clef ne doit être chargée dans l’agent qu’une fois pour toutes. La phrase de passe doit être fournie lors de la première utilisation de la clef, et devra éventuellement être saisie à nouveau pour une utilisation ultérieure si le cache a expiré entre-temps.

Vous pouvez maintenant profiter de l'authentification SSH par clé publique avec votre clé PGP.

Il peut être utile de préciser que l’agent GnuPG permet aussi d’utiliser des clefs SSH « classiques » (celles générées avec ssh-keygen par exemple). Il suffit de les charger dans l’agent GnuPG de la même façon qu’on le ferait avec l’agent OpenSSH, c’est-à-dire avec ssh-add.

Moi, ce qui me gène le plus, c'est les signatures de 30 km de long

Sans oublier le combo « signature de 30 km de long, en HTML ».

Le modèle de signature recommandé par mon labo (et fourni par le service IT, qui n’a apparemment jamais entendu parler de la Netiquette — notamment le passage recommandant des signatures de quatre lignes maximum) fait 121 lignes de code HTML (incluant liens vers des images externes, propre feuille de style CSS, et commentaires que personne n’a jamais pris la peine de nettoyer)…

Résultat, la seule signature est beaucoup plus longue (à la fois en termes de lignes de code HTML, et en termes d’espace pris sur l’écran après rendu) que le contenu d’un message moyen typique…

Le jargon a le défaut de ses qualités : il est spécifique et apporte la précision nécessaire, mais peu compréhensible en dehors des spécialistes

Il n’y a pas que le jargon, il y a aussi la pratique abondante (abusive ?) des renvois d’un texte à un autre qui rend la prose juridique particulièrement indigeste.

Et en l’occurence, même des spécialistes du droit se plaignent de la rédaction abominable de certains textes :

Maître Eolas sur un décret d’application de la loi HADOPI :

« Le résultat est d’une étonnante subtilité. » Traduire : « Ça a été écrit par un Orc. »
[…]
Mon Dieu ! Mon Dieu ! Mais il y a un concours de mauvaise rédaction de textes législatifs, ou quoi ? Quelle horreur ! Des éléments constitutifs repoussés dans un second paragraphe, et pas moins de six renvois textuels pour une contravention.

Le même sur une loi de « simplification » du droit, où l’abondance de renvois aboutit à une conséquence non-voulue par le législateur « qui ne sait plus ce qu’il vote ».

Toujours le même sur la loi LCEN :

Bon, rassurez-vous, j’arrête la torture. je voulais juste vous faire goûter un exemple de ce que nous vivons au quotidien avec la pratique des renvois d’un texte à un autre.

Maître Mô, sur une loi introduisant le mot « inceste » dans le code pénal, tellement mal rédigée qu’elle fait le contraire de ce que voulait son auteur :

[…] le Code Pénal est désormais mal rédigé, et truffé de renvois vers lui-même qui le rendent aussi digeste que le jugement Clearstream […]

Si on veut poursuivre la comparaison avec le code informatique, je dirais que les programmeurs, eux, ont compris qu’il fallait éviter le code spaghetti…

Oui.

$ ssh user@windows "powershell -File script.ps"

Par contre je me demande comment ça se passe pour faire tourner un serveur SSH. Faut lancer sshd à partir d’un fichier batch dans le dossier « Démarrage » ?

Non, Cygwin installe ça proprement comme un « service » Windows, que l’on peut ensuite contrôler comme n’importe quel autre service (y compris pour le faire démarrer lors du démarrage de la machine).

Ça fonctionne bien ? Tu utilises toi-même ou bien c’était juste une idée comme ça ?

J’utilise ça régulièrement pour accèder à une machine Windows Server 2008 à distance, et dans mon cas ça marche bien, oui.

Aucun navigateur ne le prend en charge de base (ce qui est regrettable et probablement pas près de changer, malheureusement).

Mais l’extension DNSSEC/TLSA Validator permet d’ajouter cette prise en charge à Mozilla Firefox, Internet Explorer, Chrome/Chromium, Opera et Safari — et je ne sais pas pour les quatre derniers, mais ça fonctionne très bien pour Firefox.

(Et j’ai aussi un plugin de mon cru pour uzbl, mais il faut mettre les mains dans le cambouis.)

s_client n’a effectivement aucun support pour HTTPS_PROXY. Ce n’est pas très étonnant si on considère que c’est un client TLS générique, alors que HTTPS_PROXY (comme son nom l’indique) est spécifique à HTTPS.

Une option -proxy host:port a été ajoutée à la version de développement il y a quelques semaines.

En tout cas, chez moi, sans cette option et sans rien à ce sujet dans la configuration, openssl req me sort spontanément des signatures avec hachage SHA-256.

Ça dépend des versions (et/ou peut-être des options à la compilation). Chez moi, c’est du SHA-1 par défaut avec OpenSSL 1.0.1p sur Slackware, mais SHA-256 par défaut avec OpenSSL 1.0.1k sur Debian…

Mais attention, ce n’est pas parce que la requête de certificat est signée sur un condensat SHA-256 que le certificat le sera forcément. C’est l’autorité de certification qui décide seule de l’algorithme de condensation qu’elle utilise pour signer le certificat : elle peut très bien utiliser SHA-1 même si la CSR a été générée avec SHA-256.

Non. Ça ne sert à rien, de mettre le certificat racine, auto-signé, de l'autorité de certification.

Ça peut servir dans le cas où ce certificat est épinglé comme trust anchor dans un enregistrement TLSA de type DANE-TA (RFC 6698), pour que le navigateur puisse comparer le certificat racine envoyé par le serveur avec le condensat publié dans le DNS.

Juste une précision, la directive SSLCertificateChainFile est obsolète à partir d’Apache httpd 2.4.8. La chaîne de certificat(s) intermédiaire(s) doit désormais être concaténée à la suite du certificat du serveur dans le fichier indiqué par la directive SSLCertificateFile.

À part ça, on peut (doit ?) considérer aussi l’utilisation de HPKP (épinglage des clefs publiques dans les en-têtes HTTP, RFC 7469). Il suffit d’une ligne supplémentaire (ici, toujour pour Apache httpd) :

Header always set Public-Key-Pins "max-age=5184000; includeSubDomains; pin-sha256=\"condensat_de_la_clef_active\"; pin-sha256=\"condensat_de_la_clef_de_secours\" env=HTTPS

Le condensat d’une clef peut s’obtenir ainsi :

$ openssl x509 -in libwalk.crt -noout -pubout | \   # Extraction de la clef publique depuis le certificat
  openssl rsa -pubin -outform DER | \               # Conversion en DER
  openssl dgst -sha256 -binary | \                  # Condensation
  openssl enc -base64                               # Encodage en Base64

Attention, l’épinglage d’une clef de secours n’est pas optionnel : le RFC 7469 dit clairement qu’un navigateur doit ignorer tout en-tête HPKP qui ne mentionnerait pas de clef de secours.

Content de voir que mes articles font des émules, j’espères que tu vas continuer ;)

J’ai deux petites remarques à partager sur ce journal.

Une première, insignifiante, concerne l’unité Systemd utilisé pour démarrer l’agent GnuPG :

ExecStart=/usr/bin/gpg-agent --homedir=%h/.gnupg --daemon --use-standard-socket

L’option homedir est redondante si tu laisses GnuPG utiliser son dossier par défaut ; et l’option --use-standard-socket est inutile si tu utilises GnuPG 2.1, qui utilises toujours la « socket standard » (l’option n’est restée que par souci de compatibilité avec des scripts écrits pour GnuPG 2.0, mais elle n’a pas d’effets).

Plus important, le choix de la phrase de passe :

$ for i in `seq 4`; do shuf -n1 /usr/share/dict/words; done | paste -s -d - | tr '[:upper:]' '[:lower:]'
blue-fish-mermaid-copycutter-hurris

Ça permet d'avoir un secret pas trop compliqué à retenir mais difficile à deviner.

Il n’est malheureusement pas sûr que ce secret soit difficile à deviner. Les crackers ont fait beaucoup de progrès au cours des dernières années, et le conseil de xkcd n’est plus forcément valide aujourd’hui, face aux combinator attacks :

It combines each word in a dictionary with every other word in the dictionary. […] This is an answer to the batteryhorsestaple thing.

Si il est impossible de faire la différence entre un MIME utile pour l'utilisateur (un document qu'il doit ouvrir ou sauvegarder) et un MIME "metadonnées" (une signature qu'on peut ignorer si on ne supporte pas la signature), il y a une problème technique.

Mais bien sûr qu’il est possible de faire la différence, il suffit de regarder le type MIME, c’est là pour ça.

Ton problème vient des clients qui ne savent pas gérer le type MIME multipart/signed, qui du coup ne peuvent pas savoir à quoi il sert (est-ce une pièce jointe ou une métadonnée ?) et donc se rabattent (à raison) sur le comportement recommandé (traiter ça comme un blob opaque).

Mais j'ai été emmerdé que par des gens utilisant PGP

Peut-être parce que personne ne t’a jamais envoyé de messages signés par S/MIME, parce que le fonctionnement est exactement le même…

un très bonne idée sur le papier, mais aucune gestion de l'ancien

Vois pas le rapport avec « la gestion de l’ancien ». PGP/MIME a expressément repris le format MIME qui existait déjà, justement pour ne pas inventer son propre truc de son côté.

cette "forme" de PGP utilise un endroit qu'il ne devrait pas utiliser, car non prévu pour ça.

OK, je crois comprendre. Tu sembles considérer que MIME ne sert qu’à transporter des pièces jointes, et donc que PGP/MIME (et S/MIME aussi du coup) devrait aller mettre ses signatures ailleurs (vu que ça n’a rien à voir avec une pièce jointe).

Sauf que non, MIME n’a jamais été limité au seul transport des « pièces jointes ».

MIME est prévu, entre autres choses (le premier « M » de MIME veut dire multi-purpose…), pour :

• envoyer des pièces jointes (multipart/mixed) ;
• envoyer plusieurs versions d’un même message (multipart/alternative, typiquement, une version texte et une version HTML, ou encore une version française et une version anglaise) ;
• envoyer plusieurs messages en un seul (multipart/digest) ;
• envoyer un message « forwardé » (multipart/rfc822) ;
• envoyer un message signé (multipart/signed) ;
• envoyer un message chiffré (multipart/encrypted).

Au passage, multipart/signed et multipart/encrypted ne sont pas des inventions de PGP, ça existait avant.

d'une en "mentant" car ce n'est pas une pièce jointe

D’après toi, que serait supposé faire un client mail en recevant un type MIME qu’il ne reconnaît pas ? Le masquer complètement à l’utilisateur ? Et si c’était une pièce jointe dans un format que le client ne connaît pas mais dont l’utilisateur, lui, sait quoi faire ?

Le traiter comme une pièce jointe opaque est le comportement attendu d’un client conforme à MIME (RFC 2049) :

Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.

(et je ne dois pas tour comprendre à cette superbe techno car je ne vois pas pourquoi il ne suffirait pas d'ajouter un champs d'en-tête PGP avec la signature, qui sera ignoré par les lecteurs ne supportant pas la chose vu que c'est prévu comme ça, à la place d'une pièce jointe)

Je ne sais pas ce qui a motivé les choix derrière PGP/MIME. Ils ont repris le format déjà créé pour S/MIME, donc la décision remonte en fait au RFC 1847, en… 1995.

A priori, je dirais qu’au moins une raison était d’avoir un seul format à la fois pour les messages signés et pour les messages chiffrés. Un en-tête de signature, à la manière de ce qui se fait pour DKIM, n’aurait évidemment pas été adapté.

Une autre raison est que mettre la signature dans l’en-tête ne dispense de toute façon pas du besoin de délimiter la partie du message qui est signée, ce qui implique d’empaqueter la partie signée dans un conteneur MIME (ce que font S/MIME ou PGP/MIME, et on retombe sur le problème de messages contenant des parts MIME dont le client mail et/ou l’utilisateur ne comprend pas la signification).

L’alternative serait d’indiquer dans l’en-tête ce qui est signé exactement — c’est ce que fait DKIM, et c’est pourquoi les signatures DKIM sont régulièrement cassées dès qu’un message passe à travers un MTA indélicat qui touche un peu trop au corps du message.