Diskussion:S/MIME

Die Umleitung sollte m.E. durch einen eigenen Artikel ersetzt werden. Der referenzierte Artikel beschreibt zwar auch S/MIME, dies jedoch vor allem unter dem Gesichtspunkt der Signatur. Verschlüsselung kommt dabei ebenso zu kurz wie spezifische Eigenschaften, etwa die Unterschiede zwischen S/MIME 2 und 3, Domain-Zertifikate u.ä.

Pasc2 13:28, 20. Aug 2004 (CEST)

Weblinks

Warum hat denn der Benutzer Benutzer:Der_kleine_grüne_Schornstein alle Weblinks zu Anleitungen zum Verschlüsseln mit S/MIME, die ich eingefügt hatte, wieder gelöscht und dabei den wirklich inhaltsleeren Link zu smime.org nicht gelöscht? Was sucht den der Leser unter "S/MIME"? Viele werden Anleitungen zum Verschlüsseln suchen! --Oriel 12:11, 3. Apr. 2008 (CEST)

Lies WP:WWNI und WP:WEB und Du weißt warum.--Rotkaeppchen68 00:01, 29. Jul. 2010 (CEST)

fehlerhaften Link zum Vergleich s/mime pgp entfernt und ersetzt. möge es hilfreich gewesen sein.

Verständlichkeit

Kann bitte jemand mit Ahnung den Text verständlicher schreiben? Ich kenne mich schon etwas aus, aber das ist mir zu viel! Denkt mal an die, die sich gar nicht mit dem Thema auskennen! --Timmaexx (Diskussion) 21:29, 28. Jun. 2013 (CEST)

Was konkret vermisst du? Was verstehst du noch, was nicht mehr? --RokerHRO (Diskussion) 23:43, 1. Jul. 2013 (CEST)

Zumindest der Abschnitt "Funktion" erklärt mir nur, dass S/MIME inkompatible zu OpenPGP ist. Warum gibt es die Inkompatibilität? Die Sätze "Multipart/Signed-Format zur Signierung einer Mail" und "Multipart/Encrypted-Format zu deren Verschlüsselung" benötigen weiterreichende Erklärungen. --Timmaexx (Diskussion) 12:42, 3. Jul. 2013 (CEST)

Steht doch da: OpenPGP und S/MIME benutzen verschiedene Datenformate. Inhaltlich gleiche oder ähnliche Daten werden jeweils verschieden kodiert, so dass Software, die nur das OpenPGP-Format beherrscht, das S/MIME-Format nicht lesen kann und umgekehrt.

Und was "Verschlüsselung" und "Signieren" im Zusammenhang mit Kryptographie usw. bedeutet, ist im Einleitungssatz verlinkt.

--RokerHRO (Diskussion) 23:33, 8. Jul. 2013 (CEST)

Verständlichkeit 2

Moin. Ist zwar schon lange her, aber ich habe den Artikel heute zum ersten Mal gelesen. Ich bin als Anwender seit 1994 im Netz unterwegs, habe einigermaßen gutes Grundverständnis für die Zusammenhänge. Aber außer, dass mit S/MIME eine E-Mail verschlüsselt werden kann, habe ich nur wenig davon verstanden, was genauer passiert und wie die Abläufe sind. Ohne dem ist es aber relativ schwierig, sich ein Bild davon zu machen und es somit zu verstehen. Außer man ist leicht nerdig ohnehin immer in diesen Dingen unterwegs und versteht es einfach so immer.

Also, wer macht was, auf wessen Rechner, warum ist das sicher, was muss ein Nutzer tun, um zu verschlüsseln und zu entschlüsseln, woran sieht ein Nutzer ob es verschlüsselt ist, um welche Verschlüsselung es sich handelt und was es mit der Signatur auf sich hat?

Ein Lexikon richtet sich ja nicht nur an Fachleute, sondern auch an Unbedarfte. Mir nützt es nichts, wenn ich lese, dass es ein Multipart/Signed-Format ist, wenn ich nicht weiß, was das sein soll. "S/MIME für Dummies" wäre nicht schlecht. Das Problem der Unverständlichkeit gibt es aber bei vielen Themen, wenn Fachleute oder Leute mit Ahnung in der Tiefe etwas schreiben, weil man dann in seiner "Blase" gefangen ist, das inhaltlich gut zu schreiben, aber übersieht, dass die Fachsprache genau darauf abzielt: Fachpublikum und nicht Allerwelts-Publikum. --194.127.24.76 16:00, 7. Aug. 2023 (CEST)

Ich habe deinen Beitrag mal in einen separaten Absatz gepackt, da er keinen direkten Bezug zu der darüberliegenden Diskussion hat.

"Wer macht was?" – Der Rechner, der eine e-Mail abschicken will, verschlüsselt die Mail, der Rechner, der die Mail empfängt, entschlüsselt sie wieder.

"Warum ist das sicher?" – Weil die verwendeten Verschlüsselungsalgorithmen als sicher gelten und die Verschlüsselung auf den Endgeräten passiert und die dazwischenliegenden Mailserver nur die verschlüsselte Mail weiterleiten, aber den Inhalt nicht kennen ("Ende-zu-Ende-Verschlüsselung).

"Was muss ein Nutzer tun?" – Ein Mailprogramm benutzen, das S/MIME kann (z.B. Mozilla Thunderbird, MS Outlook) und den Schlüssel des Empfängers besitzen. Wie man an den Schlüssel kommt und wie das Mailprogramm anzeigt, ob eine Mail verschlüsselt ist, und ob die Signatur gültig ist, hängt vom Mailprogramm ab.

--RokerHRO (Diskussion) 20:23, 12. Aug. 2023 (CEST)

Fehlerhafter Abschnitt

Zunächst finde ich es zweifelhaft, dass der Artikel über "S/MIME" so viele Elemente von PGP beinhaltet. Nach einiger Recherche bin ich sogar zu dem Entschluss gekommen, dass der Abschnitt "Multipart/Encrypted" hier gar nichts zu suchen hat. Es ist wahr, dass der S/MIME-Standard einen (optionalen) Typen "Multipart/Signed" definiert, von "Multipart/Encrypted" ist aber in den RFC (rfc3851 und rfc5751) nirgendwo die Rede (außer in einem Titel einer referenzierten Literatur). Thunderbird behandelt E-Mails diesen Typs auch immer als OpenPGP-Nachrichten.

Ich schlage daher vor, diesen Abschnitt aus dem Artikel zu entfernen.

--Christian Ciach (Diskussion) 11:32, 15. Jul. 2013 (CEST)

... „außer in einem Titel einer referenzierten Literatur“, die aber der ursprüngliche Request for Comments ist, und immer noch proposed Standard. --84.157.221.63 21:25, 25. Jul. 2013 (CEST)

S/MIME verwendet Multipart/Encrypted nicht. Der Abschnitt war schlicht falsch. Trotzdem gibt es natürlich ein Verschlüsselungsformat. Ich habe den Abschnitt korrigiert.--Hauke Laging (Diskussion) 03:18, 16. Okt. 2013 (CEST)

Es gibt aktuell dreierlei:

1. S/MIME (gibt die Bezeichnung Multipart/Encrypted vor)
2. S/MIME mit PGP (folgt der Bezeichnung Multipart/Encrypted)
3. S/MIME Version 3 (folgt der Bezeichnung Multipart/Encrypted nicht)

S/MIME mit PGP war 1996 die erste öffentlich definierte Anwendung von S/MIME.(RFC 2015, RFC 1847) 1998 kam S/MIME V2 hinzu, 1999 von S/MIME V3 abgelöst, um den proprietären Bestand mit PKCS von RSA anzubinden, der eine andere Bezeichnung als Multipart/Encrypted erwartet.(RFC 2311, RFC 2633) Von daher steht S/MIME V3 irgendwie neben S/MIME und verdient eine deutliche Abgrenzung oder eine Auslagerung in einen separaten Artikel.

--84.157.203.116 21:26, 19. Mai 2015 (CEST)

CaCert

Ich habe gerade CaCert aus der Liste der Zertifikate entfernt, welche im Gegensatz zu Cacert in allen gängigen Browsern integriert sind... Dort bestand ein offensichtlicher Widerspruch. Des weiteren haben CaCert Zertifikate der Klasse 1 eine Gültigkeit von 6 Monaten und nicht von einem Jahr. --Dbauer271 (Diskussion) 11:32, 15. Feb. 2014 (CET)

Grobe Darstellung des Ablaufs bei der Ver/Entschlüsselung ? Grundlegende Frunktionsweise ?

Hallo und Danke für den Artikel ! Ich finde ihne sehr hilfreich, allerdings auch schwer verdaulich. Ich habe die Details verstanden, bin mir aber nicht sicher ob ich das Grundlegende verstanden habe. Vielleicht könnte ein Mensch der den gesamten Zusammenhang versteht in der Einleitung kurz darstellen, wie der prinzipielle Ablauf beim Verschlüsseln und Versenden / Empfangen und Entschlüsseln ist ?

Ich glaube verstanden zu haben dass es einen öffentlichen und einen privaten Teil des Zertfifikats gibt. Der Versender der Mail braucht den öffentlichen Teil des Empfängers, um zu verschlüsseln. Der Empfänger (und nur er) hat auch den privaten Teil, der für die Entschlüsselung notwendig ist. Korrekt ? Ich bin mir nicht sicher, wäre es aber gerne ... (nicht signierter Beitrag von 153.100.131.12 (Diskussion) 07:49, 25. Aug. 2014 (CEST))

Das ist so korrekt. :-) --RokerHRO (Diskussion) 20:41, 25. Aug. 2014 (CEST)

Kostenlose Zertifikate

Ich habe den Artikel ergänzt sowie die Sortierung der kostenlosen Zertifikate so verändert, dass die am längsten gültigen sowie am häufigsten in den Zertifikatsdatenbanken verbreiteten Anbieter von kostenlosen Zertifikaten zuerst genannt werden.

--OliOli (Diskussion) 17:13, 1. Okt. 2015 (CEST)

Nutzen

Ich habe mich gefragt, warum Leute am Emails ein smime anhängen, also mir die Frage "Was ist der Nutzen davon?" gestellt. Ich bin dann schnell auf Wiki gegoogelt, um die Antwort zu finden. Die Frage wird durch den Artikel nicht beantwortet. Eine Diskussion meines Beitrags ändert dies nicht. (nicht signierter Beitrag von 88.78.7.19 (Diskussion) 15:28, 15. Okt. 2015 (CEST))

Absicht oder Zufall ?

Ob HTTPS, ftps, smpts, pop3s oder was auch immer, als Nutzer kann man nicht-CA-signierte Zertifikate als Ausnahme zulassen. Bei E-Mails funktioniert das nach unseren Versuchen in der Regel nicht: Thunderbird und Windows-Mail-Agenten verweigern schlicht, solche Zertifikate als Ausnahmen zu akzeptieren (Windows 10 scheint das noch zu toppen: anscheinend wird die Verschlüsselung nur dann im Menü aktiviert, wenn man den E-Mail-Verkehr über einen MicroSoft-IMAP-Server abwickelt, was eine Verschlüsselung ziemlich sinnlos macht). Man kann sich zwar mit den beschriebenen Tricks eigener Root-Zertifikate usw. darum herum mogeln, aber warum funktionieren gerade Ausnahmen bei E-Mails nicht, obwohl das Problem einer CA-Authenfifizierung für die breite Masse der Nutzer keine Rolle spielt, da man den Gegenüber in der Regel kennt? Schließlich wäre gerade für den privaten Massenbereich eine einfache Verschlüsselung dringend notwendig, und s/mime mit x509-Zertifikaten wären gegenüber pgp die aus Benutzersicht technisch einfachere Lösung.

Ich kann da natürlich nur spekulieren. E-Mails sind ein absoluter Massenmarkt, und CA-Root-Zertifikat-signierte Nutzerzertifikate sind für die CAs eine Lizenz zum Gelddrucken. Wenn man sich die Mitgliederlisten der verschiedenen Internet Security Groups anschaut, findet man i.d.R. sowohl die Softwarehersteller als auch die Zertifizierer (und das allgegenwärtige DoD). Will sich da jemand nicht die Butter vom Brot nehmen lassen? Gilbert Brands (Diskussion) 15:02, 2. Nov. 2016 (CET)

Bitte WP:DS beachten. Inwiefern dient dein Beitrag nun der Verbesserung des Artikels? --RokerHRO (Diskussion) 00:04, 4. Nov. 2016 (CET)

Kostenlose Zertifikate

• StartSSL PKI wurde das Vertrauen durch Mozilla entzogen. Mit TB 52 werden die Root-Zertifikate noch ausgeliefert aber die Vertrauenseinstellungen wurden geändert.
  • http://i.imgur.com/B0Vgdap.png
  • https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
  • Interestingly, TB 52 still trusts all built in WoSign Certificates
• Secorio S/MIME: Secorio wurde offenbar von Comodo übernommen oder benutzt comodos Infrastruktur für die Zertifikatsausstellung.
  • http://i.imgur.com/nQZ87wj.png
• Symantec wird ggf. das Vertrauen entzogen.
  • http://thehackernews.com/2017/03/google-invalidate-symantec-certs.html

-- 77.6.11.14 02:11, 13. Apr. 2017 (CEST)

Ich habe für die kostenlosen Zertifikate von wiseid.com den Hinweis ergänzt, dass dieser Anbieter selbst auf dem Server "private"- und public-key erzeugt - und der Anbieter oder jeder, der von ihm den "private key" erhalten kann, die verschlüsselten emails lesen oder glaubwürdig signieren kann. Das untergräbt das fundamentale Prinzip von public/private key Verfahren, dass der "private"-key eben niemand anderem als dem Benutzer selbst bekannt sein sollte. Für die (aufgrund nur 30 Tagen Gültigkeit eingeschränkt nützlichen) kostenlosen Zertifikate der "instantssl.com"-nutzenden Unternehmen gilt das nicht, dort erzeugt der client selbst den private key. (Direkt-Link: https://secure.instantssl.com/products/frontpage?area=SecureEmailCertificate&currency=EUR&region=Europe&country=DE ). --92.194.37.92 23:46, 29. Dez. 2019 (CET)

DGN-Zertifikate nicht standardmäßig in der Liste vertrauenswürdiger Zertifikate: In der Beschreibung zur Liste, in der auch die DGN-Zertifikate gelistet werden, steht: "[...] welche im Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden [...]". Dies trifft mindestens auf Windows 10 nicht zu. Siehe zum Beispiel hier: https://www.frankysweb.de/tipp-kostenloses-s-mime-zertifikat-neu/. Auch auf der DGN-Seite selbst, wird man mehr oder weniger direkt darauf hingewiesen: "[...] Schaffen Sie eine Vertrauensbasis für die Kommunikation im Internet, indem Sie die Wurzel- und die CA-Zertifikate des DGN Trustcenters in Ihrem Browser installieren [...]" siehe https://www.dgn.de/dgncert/downloads.html. Ich denke, die DGN-Zertifikate sollten aus dieser Liste entfernt werden. Mit Hinblick auf die Vertrauenswürdigkeit der Root-Zertifikate scheinen sie eher mit CACert vergleichbar zu sein. --93.232.93.110 16:28, 10. Jan. 2021 (CET)

Auch Volksverschlüsselung passt nicht in die Liste. Die Liste wird überschrieben mit "Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden". Im Wikipedia-Artikel zu Volkgsverschlüsselung steht aber: "... und die Vertrauenskette (trustchain) der Volksverschlüsselung muss installiert sein". Für mich liest sich das nicht so, als wäre das in in den geängigen Anwendungen standardmäßig dabei... --93.232.91.172 10:01, 15. Apr. 2021 (CEST)

PGP

Bei „Alternativen“ wird pretty easy privacy angeboten. Zuvor wird aber bei „Sicherheitsrisiko“ unbedingt davon abgeraten eine Zertifizierungsstelle zu nehmen die beide Schlüssel erzeugt. p≡p generiert für den Benutzer automatisch ein Schlüsselpaar oder importiert es von einem lokalen PGP-Client. Dann sollte man PGP doch lieber nicht nehmen,oder ?

Ich habe nur kurz reingelesen. Bei Pretty Easy privacy steht, dass dies eine Software und keine Zertifizierungsstelle ist. Die Software erzeugt das Schlüsselpaar auf deinem Gerät, sodass nie ein Dritter auf deinen privaten Schlüssel Zugriff hat. Dagegen wird davon abgeraten eine Zertifizierungsstelle zu nutzen, die das Schlüsselpaar auf ihren eigenen Servern erzeugt und dir eine Kopie beider Schlüssel schickt. Diese kennt dann deinen privaten Schlüssel und kann nicht beweisen, dass sie ihn gelöscht haben. --2.202.59.78 16:09, 13. Mär. 2019 (CET)

Stammzertifikat

Sollte man nicht den Begriff "Stammzertifikat" besser durch "Wurzelzertifikat" oder auch "Root-Certificate" ersetzen? Das würde die Verwendung dieses Artikels bei weitergehendem Recherchebedarf deutlich vergrößern.--Constejo (Diskussion) 14:30, 29. Jul. 2019 (CEST)

Kostenlose Zertifikate

Regarding Actalis, the followig sentence (translated to English) is not correct:

<< attention: "private key" is generated by the server and is therefore known to the provider>>

Actalis does not retain the private key, as it's clearly explained in the related certificate policy document. (nicht signierter Beitrag von A46s91 (Diskussion | Beiträge) 14:50, 19. Nov. 2020 (CET))

I guess the focus is on "generated by the server". One could may be add "potentially [known to the provider]". Or simply remove this part of the sentence. --93.232.93.110 16:32, 10. Jan. 2021 (CET)

Klassifizierung der Zertifikate

Es gibt in "Klassifizierung der Zertifikate" keinerlei Quellangaben und ich habe noch nie diese Klassifizierung gesehen. Ich würde den Abschnitt daher in den nächsten Tagen entfernen.