Ah. Unter dem Hashtag #efail lernen Leute auch 2018 noch das html-Mails unsicher sind weil sie ausführbaren Code zulassen. 
MDC wurde so 2003 rum in GnuPG eingeführt. Lang genug Zeit, das zum Standard zu machen und den alten Mist zu deprecaten. Mit einer warning ist halt niemandem geholfen.
-
-
Und "Warning statt Error" ist okay, solange keine externen Ressourcen nachgeladen und keine JS-Scripte ausgeführt werden. Der Fehler liegt bei Enigmail, nicht bei GPG an sich. (Und natürlich bei HTML-Mails, aber das ist eh klar)
-
Seh ich anders. Defense in depth fängt dabei an, schlechte Crypto irgendwann auch mal loszuwerden.
-
Hmm, für mich fängt "defense in depth" schon an bei "Nehmt doch gleich S/MIME, wenn ihr X.509 eh schon für TLS implementieren müsst, und diese Implementierung um Größenordnungen besser getestet/reviewed ist/wird". Aber das ist ein anderes Thema.
-
Die Algorithmen, die S/MIME so verwendet, sind aber ähnlich angestaubt...
-
Siehe meinen vorherigen Tweet. Es gibt nen RFC für CMS mit AES-GCM seit November 2007. Und es gibt nen RFC, der ein passendes ASN.1-Modul für S/MIME spezifiziert, seit Juni 2010.
-
Das ist zugegebenermassen 8 Jahre weiter als PGP. Ob das jetzt von Outlook unterstützt wird, hab ich spontan nicht herausfinden können.
End of conversation
New conversation -
-
-
Was vergleichbares haben sie ja auch gemacht. Kurz nach Einführung von MDC haben sie AES-Support eingebaut, und bei AES-verschlüsselten Mails erzwingen sie MDC AFAIK.
-
Erzwingen sie eben nicht, das ist genau der Vorwurf.
-
Wie eben schon geschrieben: Halte ich für vertretbar. Nur die Plugins für HTML-fähige MUAs müssten halt nen Fehler werfen, wenn GPG ihnen nen ungültigen MDC meldet.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.