Diskussion:S/MIME

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

message: Warum hat denn der Benutzer Benutzer:Der_kleine_gr%C3%BCne_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)
replies: text: Lies WP:WWNI und WP:WEB und Du weißt warum.--Rotkaeppchen68 00:01, 29. Jul. 2010 (CEST)
thread_title:  Weblinks 

message: 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)
thread_title:  CaCert 

message: 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)
replies: text: Das ist so korrekt. :-) --RokerHRO (Diskussion) 20:41, 25. Aug. 2014 (CEST)
thread_title:  Grobe Darstellung des Ablaufs bei der Ver/Entschlüsselung ? Grundlegende Frunktionsweise ? 

message: 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)
thread_title:  Kostenlose Zertifikate 

message: 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)
thread_title:  Nutzen 

message: 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)
replies: text: Bitte WP:DS beachten. Inwiefern dient dein Beitrag nun der Verbesserung des Artikels? --RokerHRO (Diskussion) 00:04, 4. Nov. 2016 (CET)
thread_title:  Absicht oder Zufall ? 

message: * 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)
thread_title:  Kostenlose Zertifikate 

message: 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)
thread_title:  PGP 

message: 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)
thread_title:  Stammzertifikat 

message: 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. 
: 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)
thread_title:  Kostenlose Zertifikate