Secure Multipurpose Internet Mail Extensions: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
 
(24 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''S/MIME''' - Kurzbeschreibung
'''Secure [[Multipurpose Internet Mail Extensions]]''' ([[S/MIME]]) - Kurzbeschreibung


== Beschreibung ==
== Beschreibung ==
'''Secure / [[Multipurpose Internet Mail Extensions]]''' ('''S/MIME''') ist ein Standard für die [[Verschlüsselung]] und das [[Elektronische Signatur|Signieren]] von [[Multipurpose Internet Mail Extensions|MIME]]-[[Datenkapselung (Netzwerktechnik)|Objekten]] durch ein [[asymmetrisches Kryptosystem]]. S/MIME wird in sehr vielen Protokollen zur Absicherung in der Anwendungsschicht ([[Application Layer]]) eingesetzt. Typische Einsatzfälle von S/MIME sind [[E-Mail]], [[AS2]] und viele weitere. In der Praxis kann S/MIME (Inhaltsebene) mit [[Transport Layer Security|TLS]] (Transportebene) kombiniert werden.
Secure [[Multipurpose Internet Mail Extensions]] ([[S/MIME]]) ist ein Standard zu
* [[Verschlüsselung]]
* [[Elektronische Signatur]]  
von
* [[Multipurpose Internet Mail Extensions|MIME]]-[[Datenkapselung (Netzwerktechnik)|Objekten]]  
durch
* [[asymmetrisches Kryptosystem]]
 
S/MIME wird in vielen Protokollen zur Absicherung in der Anwendungsschicht ([[Application Layer]]) eingesetzt
 
; Typische Einsatzfälle von S/MIME
* [[E-Mail]]
* [[AS2]] und viele weitere
 
In der Praxis kann S/MIME (Inhaltsebene) mit [[Transport Layer Security|TLS]] (Transportebene) kombiniert werden


== Funktion ==
== Funktion ==
<nowiki>RFC&nbsp;1847</nowiki> (1995)<ref>{{RFC-Internet |RFC=1847 |Titel=Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted |Datum=1995-10}}</ref> definiert zwei [[Internet Media Type|Content-Types]] für MIME. Das <code>multipart/signed</code>-Format zur Signierung einer E-Mail und das <code>multipart/encrypted</code>-Format zu deren Verschlüsselung. Eine E-Mail kann dabei nur signiert, nur verschlüsselt oder beiden Operationen unterzogen werden. Sowohl S/MIME (<nowiki>RFC&nbsp;2633</nowiki><ref>{{RFC-Internet |RFC=2633 |Titel=S/MIME Version 3 Message Specification |Datum=1999-06}}</ref>) als auch [[OpenPGP]] (<nowiki>RFC&nbsp;2440</nowiki><ref>{{RFC-Internet |RFC=2440 |Titel=OpenPGP Message Format |Datum=1998-11}}</ref>), die beide erst später spezifiziert wurden, verwenden <code>multipart/signed</code>, wohingegen <code>multipart/encrypted</code> nur von OpenPGP verwendet wird. S/MIME definiert (auch) für Verschlüsselung den neuen Content-Type <code>application/pkcs7-mime</code>. S/MIME wird von den meisten modernen Mailclients unterstützt. Es erfordert [[X.509]]-basierte [[Digitales Zertifikat|Zertifikate]] für den Betrieb.
RFC&nbsp;1847 (1995)
definiert zwei [[Internet Media Type|Content-Types]] für MIME
* Das <code>multipart/signed</code>-Format zur Signierung einer E-Mail und das <code>multipart/encrypted</code>-Format zu deren Verschlüsselung
* Eine E-Mail kann dabei nur signiert, nur verschlüsselt oder beiden Operationen unterzogen werden
* Sowohl S/MIME (RFC&nbsp;2633), die beide erst später spezifiziert wurden, verwenden <code>multipart/signed</code>, wohingegen <code>multipart/encrypted</code> nur von OpenPGP verwendet wird
* S/MIME definiert (auch) für Verschlüsselung den neuen Content-Type <code>application/pkcs7-mime</code>
* S/MIME wird von den meisten modernen Mailclients unterstützt
* Es erfordert [[X.509]]-basierte [[Digitales Zertifikat|Zertifikate]] für den Betrieb


=== Multipart/Signed ===
=== Multipart/Signed ===
Das Format enthält genau zwei Blöcke. Der erste enthält die Daten, inklusive des MIME-Headers, über welche die digitale Signatur erstellt wurde. Der zweite enthält die Informationen, um die Signatur zu überprüfen. Die Mail bleibt dadurch auch für E-Mail-Clients lesbar, die kein S/MIME unterstützen. Deshalb ist <code>multipart/signed</code> die empfohlene von mehreren möglichen S/MIME-Methoden.
Das Format enthält genau zwei Blöcke
* Der erste enthält die Daten, inklusive des MIME-Headers, über welche die digitale Signatur erstellt wurde
* Der zweite enthält die Informationen, um die Signatur zu überprüfen
* Die Mail bleibt dadurch auch für E-Mail-Clients lesbar, die kein S/MIME unterstützen
* Deshalb ist <code>multipart/signed</code> die empfohlene von mehreren möglichen S/MIME-Methoden


=== application/pkcs7-mime ===
=== application/pkcs7-mime ===
Der Content-Type <code>application/pkcs7-mime</code> hat den optionalen Parameter smime-type, der die Art der Daten beschreibt (ohne dass sie dafür decodiert werden müssen): enveloped-data (Verschlüsselung), signed-data (Signatur), certs-only (Zertifikat). Außerdem zeigt der Dateiname des optionalen, aber erbetenen Headereintrags Content-Disposition die Art der Daten an: smime.p7m (signierte oder verschlüsselte Daten), smime.p7c (Zertifikat), smime.p7s (Signatur).
Der Content-Type <code>application/pkcs7-mime</code> hat den optionalen Parameter smime-type, der die Art der Daten beschreibt (ohne dass sie dafür decodiert werden müssen): enveloped-data (Verschlüsselung), signed-data (Signatur), certs-only (Zertifikat)
* Außerdem zeigt der Dateiname des optionalen, aber erbetenen Headereintrags Content-Disposition die Art der Daten an: smime.p7m (signierte oder verschlüsselte Daten), smime.p7c (Zertifikat), smime.p7s (Signatur)


Ein Abschnitt mit verschlüsselten Daten enthält ebenfalls genau zwei Blöcke. Der erste enthält benötigte Informationen zur Entschlüsselung. Im zweiten Block sind die verschlüsselten Daten enthalten. Der Mailrumpf ist komplett verschlüsselt und kann somit nur vom vorgesehenen Empfänger gelesen werden. Damit ist auch ein Scannen auf Viren und Spam erst auf dem Endgerät möglich. Die Mailheader (auch der Betreff) sind dagegen weiterhin unverschlüsselt und sollten daher keine vertraulichen Informationen enthalten.
Ein Abschnitt mit verschlüsselten Daten enthält ebenfalls genau zwei Blöcke
* Der erste enthält benötigte Informationen zur Entschlüsselung
* Im zweiten Block sind die verschlüsselten Daten enthalten
* Der Mailrumpf ist komplett verschlüsselt und kann somit nur vom vorgesehenen Empfänger gelesen werden
* Damit ist auch ein Scannen auf Viren und Spam erst auf dem Endgerät möglich
* Die Mailheader (auch der Betreff) sind dagegen weiterhin unverschlüsselt und sollten daher keine vertraulichen Informationen enthalten


So sieht eine verschlüsselte Nachricht beispielhaft aus:
So sieht eine verschlüsselte Nachricht beispielhaft aus:


    Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
Content-Type: application/pkcs7-mime; smime-type=enveloped-data
            name=smime.p7m
name=smime.p7m
    Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename=smime.p7m
Content-Disposition: attachment; filename=smime.p7m


    rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
    7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
    f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
    0GhIGfHfQbnj756YT64V
0GhIGfHfQbnj756YT64V


Zur Verschlüsselung einer E-Mail muss der Absender den ''öffentlichen Schlüssel'' des Empfängers kennen, den er beispielsweise dem Zertifikat einer zuvor vom Empfänger erhaltenen signierten E-Mail entnehmen kann. Ein E-Mail-Client vereinfacht die Handhabung, indem er automatisch alle erhaltenen Zertifikate speichert.
Zur Verschlüsselung einer E-Mail muss der Absender den ''öffentlichen Schlüssel'' des Empfängers kennen, den er beispielsweise dem Zertifikat einer zuvor vom Empfänger erhaltenen signierten E-Mail entnehmen kann
* Ein E-Mail-Client vereinfacht die Handhabung, indem er automatisch alle erhaltenen Zertifikate speichert


=== Klassifizierung der Zertifikate ===
=== Klassifizierung der Zertifikate ===
Die Anbieter von Zertifikaten für sichere E-Mail-Kommunikation klassifizieren diese meist in vier auf einander aufbauenden Klassen:
Die Anbieter von Zertifikaten für sichere E-Mail-Kommunikation klassifizieren diese meist in vier auf einander aufbauenden Klassen:
* '''Klasse 1''' – Nur die Echtheit der E-Mail-Adresse wird durch eine [[Zertifizierungsstelle (Digitale Zertifikate)|Zertifizierungsstelle]] (CA) bestätigt.
* '''Klasse 1''' – Nur die Echtheit der E-Mail-Adresse wird durch eine [[Zertifizierungsstelle (Digitale Zertifikate)|Zertifizierungsstelle]] (CA) bestätigt
* '''Klasse 2''' – Zusätzlich zur E-Mail-Adresse wird der dazugehörende Name (CN) in das Zertifikat mit aufgenommen, sowie ggf. die Organisation/Firma (OU).
* '''Klasse 2''' – Zusätzlich zur E-Mail-Adresse wird der dazugehörende Name (CN) in das Zertifikat mit aufgenommen, sowie ggf
* '''Klasse 3''' – Die Daten der Klasse 3 werden mithilfe von Drittdatenbanken, Ausweiskopien, Handelsregisterauszügen etc. zusätzlich verifiziert.
* die Organisation/Firma (OU)
* '''Klasse 4''' – Bei Zertifikaten der Klasse 4 muss der Antragsteller sich zusätzlich persönlich ausweisen.
* '''Klasse 3''' – Die Daten der Klasse 3 werden mithilfe von Drittdatenbanken, Ausweiskopien, Handelsregisterauszügen etc
* zusätzlich verifiziert
* '''Klasse 4''' – Bei Zertifikaten der Klasse 4 muss der Antragsteller sich zusätzlich persönlich ausweisen


== Kostenlose Zertifikate ==
== Kostenlose Zertifikate ==
Manche Unternehmen und nichtkommerzielle Organisationen bieten kostenlose S/MIME-Zertifikate an. Es können dabei nach einer Registrierung mehrere Zertifikate erstellt werden, die aber erst nach einer gewissen Anzahl von Identitätsnachweisen den Namen beinhalten. Diese können durch Mitglieder in einem [[Web of Trust]] oder anderen vertrauenswürdigen Stellen wie Rechtsanwälten oder Wirtschaftstreuhändern erfolgen. Grundsätzlich zerstört eine Ausstellung von Zertifikaten durch Anbieter ''ohne'' Identitätsüberprüfung des Antragstellers den Grundgedanken des sicheren Informationsaustauschs zwischen zwei Computern im Netz. So ist es bei einigen Zertifikatsausstellern tatsächlich möglich, mit erfundenen Betreiberangaben ein Zertifikat für eine völlig fremde Website zu erhalten. Der Benutzer würde über ein Umleiten der Informationsübertragung beispielsweise durch den Browser nicht mehr informiert, wenn die Zertifizierungsstelle durch den Browserhersteller von vornherein als vertrauenswürdig eingestuft wurde.<ref name=":0">{{Internetquelle |url=https://www.heise.de/newsticker/meldung/Vorsicht-bei-kostenlosen-SSL-Zertifikaten-137817.html |titel=Vorsicht bei kostenlosen SSL-Zertifikaten |werk=heise online |sprache=de |abruf=2021-01-17}}</ref>
Manche Unternehmen und nichtkommerzielle Organisationen bieten kostenlose S/MIME-Zertifikate an
* Es können dabei nach einer Registrierung mehrere Zertifikate erstellt werden, die aber erst nach einer gewissen Anzahl von Identitätsnachweisen den Namen beinhalten
* Diese können durch Mitglieder in einem [[Web of Trust]] oder anderen vertrauenswürdigen Stellen wie Rechtsanwälten oder Wirtschaftstreuhändern erfolgen
* Grundsätzlich zerstört eine Ausstellung von Zertifikaten durch Anbieter ''ohne'' Identitätsüberprüfung des Antragstellers den Grundgedanken des sicheren Informationsaustauschs zwischen zwei Computern im Netz
* So ist es bei einigen Zertifikatsausstellern tatsächlich möglich, mit erfundenen Betreiberangaben ein Zertifikat für eine völlig fremde Website zu erhalten
* Der Benutzer würde über ein Umleiten der Informationsübertragung beispielsweise durch den Browser nicht mehr informiert, wenn die Zertifizierungsstelle durch den Browserhersteller von vornherein als vertrauenswürdig eingestuft wurde


[[CAcert]], eine nichtkommerzielle, [[Gemeinschaft|gemeinschaftsbetriebene]] CA ([[Zertifizierungsstelle (Digitale Zertifikate)|Certificate Authority]]), stellt kostenlose Zertifikate zur Verfügung. Sie ist jedoch in vielen E-Mail-Clients und Webbrowsern nicht in der Zertifikatsdatenbank als vertrauenswürdige Zertifizierungsstelle eingetragen. Ein Benutzer, der eine Verbindung zu einem Server mit CAcert-Zertifikat aufbaut oder eine E-Mail mit einem von CAcert signierten S/MIME-Zertifikat erhält, wird daher die Fehlermeldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte (sofern CAcert nicht zuvor manuell als vertrauenswürdig im Programm eingetragen wurde).
[[CAcert]], eine nichtkommerzielle, [[Gemeinschaft|gemeinschaftsbetriebene]] CA ([[Zertifizierungsstelle (Digitale Zertifikate)|Certificate Authority]]), stellt kostenlose Zertifikate zur Verfügung
* Sie ist jedoch in vielen E-Mail-Clients und Webbrowsern nicht in der Zertifikatsdatenbank als vertrauenswürdige Zertifizierungsstelle eingetragen
* Ein Benutzer, der eine Verbindung zu einem Server mit CAcert-Zertifikat aufbaut oder eine E-Mail mit einem von CAcert signierten S/MIME-Zertifikat erhält, wird daher die Fehlermeldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte (sofern CAcert nicht zuvor manuell als vertrauenswürdig im Programm eingetragen wurde)


Weiterhin werden kostenlose Zertifikate der Klasse 1 (teilweise mit reduzierter Gültigkeitsdauer unter einem Jahr, beispielsweise als Testzertifikat) von Firmen angeboten, welche im Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden. Diese kostenlosen S/MIME-Zertifikate sind jedoch uneingeschränkt funktionsfähig. Beispiele für diese meist für den Privatgebrauch gedachten Zertifikate sind:
Weiterhin werden kostenlose Zertifikate der Klasse 1 (teilweise mit reduzierter Gültigkeitsdauer unter einem Jahr, beispielsweise als Testzertifikat) von Firmen angeboten, welche im Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden
* Diese kostenlosen S/MIME-Zertifikate sind jedoch uneingeschränkt funktionsfähig
* Beispiele für diese meist für den Privatgebrauch gedachten Zertifikate sind:


* Deutsches Gesundheitsnetz (DGN)<ref>{{Internetquelle |url=https://www.dgn.de/dgncert/anfordern.html |titel=DGNcert – Das E-Mail-Softzertifikat vom Deutschen Gesundheitsnetz |abruf=2020-03-01}}</ref> (1 Jahr gültig, Klasse&nbsp;1<ref>{{Internetquelle |url=https://www.dgn.de/dgncert/hilfe_support.form |titel=DGNcert – Das E-Mail-Softzertifikat vom Deutschen Gesundheitsnetz |abruf=2020-12-20}}</ref> – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* Deutsches Gesundheitsnetz (DGN) – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* ACTALIS S.p.A.<ref>{{Internetquelle |url=https://extrassl.actalis.it/portal/uapub/freemail |titel=ACTALIS Free Mail Certificate |abruf=2020-05-06}}</ref> (1 Jahr Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* ACTALIS S.p.A. (1 Jahr Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* free secure email eID von WISeKey<ref>[https://account.wisekey.com/ account.wisekey.com] Free Secure email eID.</ref> (3 Monate Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* free secure email eID von WISeKey (3 Monate Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
* Secorio S/MIME<ref>{{Internetquelle |url=https://secorio.com/knowledge-base/wieviel-kosten-email-zertifikate-fuer-privaten-gebrauch/ |titel=Wieviel kosten Email Zertifikate für privaten Gebrauch? |werk=Secorio AG |sprache=de-CH |abruf=2021-01-17}}</ref> (1 Monat Gültigkeit, verwendet Zertifikate von Comodo)
* Secorio S/MIME (1 Monat Gültigkeit, verwendet Zertifikate von Comodo)
* GlobalSign als Free Trial PersonalSign 1 Certificate<ref>[https://www.globalsign.com/de-de/personalsign/ PersonalSign Produkte.] GlobalSign.</ref> (30 Tage Gültigkeit)
* GlobalSign als Free Trial PersonalSign 1 Certificate (30 Tage Gültigkeit)
* [[Volksverschlüsselung]] (3 Jahre Gültigkeit, in gängigen Zertifikatsdatenbanken nicht als vertrauenswürdig gelistet<ref>{{Internetquelle |url=https://hardcoretec.com/de/blog/volksverschluesselung/ |titel=Segen oder Fluch: Die"„Volksverschlüsselung“ der Deutschen Telekom im Detail |abruf=2021-05-04}}</ref>, nur für privaten Gebrauch)
* [[Volksverschlüsselung]] (3 Jahre Gültigkeit, in gängigen Zertifikatsdatenbanken nicht als vertrauenswürdig gelistet, nur für privaten Gebrauch)


Außerdem ist es möglich, Nachrichten mit einem selbst signierten Zertifikat zu verschlüsseln. Dazu ist ein selbst erstelltes Stammzertifikat notwendig, das die eigene Zertifizierungsstelle repräsentiert. Damit können prinzipiell beliebige Zertifikate signiert werden. Alle Kommunikationspartner müssen jedoch zunächst dieses Stammzertifikat importieren und diesem vertrauen, bevor eine verschlüsselte Kommunikation möglich wird.
Außerdem ist es möglich, Nachrichten mit einem selbst signierten Zertifikat zu verschlüsseln
* Dazu ist ein selbst erstelltes Stammzertifikat notwendig, das die eigene Zertifizierungsstelle repräsentiert
* Damit können prinzipiell beliebige Zertifikate signiert werden
* Alle Kommunikationspartner müssen jedoch zunächst dieses Stammzertifikat importieren und diesem vertrauen, bevor eine verschlüsselte Kommunikation möglich wird


Mithilfe von SMIMEA ist es möglich, dass der Administrator der Domain ein (Stamm-)Zertifikat über DNS veröffentlicht und so die Beglaubigung übernimmt.<ref>{{Internetquelle |autor=Jakob Schlyter, Paul Hoffman |url=https://tools.ietf.org/html/draft-ietf-dane-smime-09 |titel=Using Secure DNS to Associate Certificates with Domain Names for S/MIME |sprache=en |abruf=2017-07-10}}</ref>
Mithilfe von SMIMEA ist es möglich, dass der Administrator der Domain ein (Stamm-)Zertifikat über DNS veröffentlicht und so die Beglaubigung übernimmt


== Sicherheit Schlüsselerzeugung ==
== Sicherheit Schlüsselerzeugung ==
Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des verwendeten [[Public-Key-Verschlüsselungsverfahren]]s ein Schlüsselpaar aus ''öffentlichem'' und ''privatem'' Schlüssel benötigt. Beide Schlüssel können durch einen Dienstleister erstellt werden. Die Erstellung des privaten Schlüssels durch den Dienstleister setzt das Vertrauen voraus, dass davon keine Kopie/Backup/Logdatei oder Ähnliches nach der Übergabe beim Dienstleister zurückbleibt. Seriöse Dienstleister [[Zertifizierungsstelle (Digitale Zertifikate)|Certificate Authorities]] (CAs) bieten stattdessen ein Verfahren an, bei welchem die Erstellung des privaten Schlüssels durch den Kunden erfolgt und zu keinem Zeitpunkt der CA übergeben werden muss.<ref name="heise-2014" /> Der Kunde übergibt dazu „seinen initialen öffentlichen Schlüssel“ per [[Certificate Signing Request]] (CSR-Antrag) an die CA und die CA erzeugt das weltweit überprüfbare öffentliche Zertifikat.<ref name="heise-2014" />
Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des verwendeten [[Public-Key-Verschlüsselungsverfahren]]s ein Schlüsselpaar aus ''öffentlichem'' und ''privatem'' Schlüssel benötigt
* Beide Schlüssel können durch einen Dienstleister erstellt werden
* Die Erstellung des privaten Schlüssels durch den Dienstleister setzt das Vertrauen voraus, dass davon keine Kopie/Backup/Logdatei oder Ähnliches nach der Übergabe beim Dienstleister zurückbleibt
* Seriöse Dienstleister [[Zertifizierungsstelle (Digitale Zertifikate)|Certificate Authorities]] (CAs) bieten stattdessen ein Verfahren an, bei welchem die Erstellung des privaten Schlüssels durch den Kunden erfolgt und zu keinem Zeitpunkt der CA übergeben werden muss


Je nach Schutzbedarf kann der private Schlüssel und die [[Certificate Signing Request|CSR-Datei]] entweder bequem im Browser erzeugt werden über eine Website, welche die CA bereitstellt oder im anderen Extrem kann dies auf einem separaten Computer erfolgen, der nur für diesen Einsatzzweck beschafft und dafür genutzt wird und über Konsolen-Befehle bedient wird. Das finale öffentliche Zertifikat der CA wird oft per E-Mail zugestellt. Seriöse CAs bieten jedes von ihr erzeugte öffentliche Zertifikat in einem eigenen öffentlich zugänglichen Zertifikatsverzeichnis inklusive öffentliche Sperrliste an.
Je nach Schutzbedarf kann der private Schlüssel und die [[Certificate Signing Request|CSR-Datei]] entweder bequem im Browser erzeugt werden über eine Website, welche die CA bereitstellt oder im anderen Extrem kann dies auf einem separaten Computer erfolgen, der nur für diesen Einsatzzweck beschafft und dafür genutzt wird und über Konsolen-Befehle bedient wird
* Das finale öffentliche Zertifikat der CA wird oft per E-Mail zugestellt
* Seriöse CAs bieten jedes von ihr erzeugte öffentliche Zertifikat in einem eigenen öffentlich zugänglichen Zertifikatsverzeichnis inklusive öffentliche Sperrliste an


Für Organisationen, die sehr viele S/MIME-Zertifikate benötigen, bieten die CAs auch besondere Zertifikatsmanager-Verwaltungsprogramme an, mit denen, auch bei erhöhtem Schutzbedarf, der Verwaltungsaufwand sinkt.
Für Organisationen, die sehr viele S/MIME-Zertifikate benötigen, bieten die CAs auch besondere Zertifikatsmanager-Verwaltungsprogramme an, mit denen, auch bei erhöhtem Schutzbedarf, der Verwaltungsaufwand sinkt


== Sicherheit S/MIME bei E-Mail ==
== Sicherheit S/MIME bei E-Mail ==
{{Hauptartikel|Efail}}
{{Hauptartikel|Efail}}
Zur Sicherheit der signierten und verschlüsselten Kommunikation per E-Mail mittels S/MIME und PGP wurden 2018 und 2019 von einer Gruppe von deutschen Sicherheitsforschern diverse Studien durchgeführt:
Zur Sicherheit der signierten und verschlüsselten Kommunikation per E-Mail mittels S/MIME und PGP wurden 2018 und 2019 von einer Gruppe von deutschen Sicherheitsforschern diverse Studien durchgeführt:
* Das kryptografische Verfahren ist weiterhin sicher, aber die Umsetzung als Protokoll S/MIME weist einige konzeptionelle Schwächen auf durch gewisse optionale Varianten. Diese Schwächen wurden unter dem Schlagwort [[Efail]] in der Öffentlichkeit diskutiert. Mit <nowiki>RFC&nbsp;8551</nowiki><ref>{{RFC-Internet |RFC=8551 |Titel=Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification |Datum=2019}}</ref> wurden die Änderungsvorschläge aufgegriffen als S/MIME 4.0 und Efail wird auch namentlich im RFC erwähnt.
* Das kryptografische Verfahren ist weiterhin sicher, aber die Umsetzung als Protokoll S/MIME weist einige konzeptionelle Schwächen auf durch gewisse optionale Varianten
* 2019 wurden diese Studien um die Fragestellung erweitert, inwieweit sich handelsübliche E-Mail-Software bei der Signaturprüfung auf der Seite des Empfängers austricksen lässt, wenn die Signatur per S/MIME mal als CMS oder mal auf dem Anhang angewendet wird oder eine E-Mail zwei Signaturen enthält. Die Forscher haben die Sicherheitslücken vor der Veröffentlichung den Herstellern mitgeteilt, so dass einige bereits Sicherheitsupdates bereitgestellt haben.<ref name="heise-2019-05-01">{{Internetquelle |autor=Fabian A. Scherschel |url=http://www.heise.de/-4411230 |titel=S/MIME und PGP: E-Mail-Signaturprüfung lässt sich austricksen |werk=heise online |datum=2019-05-01 |abruf=2019-05-04}}</ref>
* Diese Schwächen wurden unter dem Schlagwort [[Efail]] in der Öffentlichkeit diskutiert
* Mit RFC&nbsp;8551 wurden die Änderungsvorschläge aufgegriffen als S/MIME 4.0 und Efail wird auch namentlich im RFC erwähnt
* 2019 wurden diese Studien um die Fragestellung erweitert, inwieweit sich handelsübliche E-Mail-Software bei der Signaturprüfung auf der Seite des Empfängers austricksen lässt, wenn die Signatur per S/MIME mal als CMS oder mal auf dem Anhang angewendet wird oder eine E-Mail zwei Signaturen enthält
* Die Forscher haben die Sicherheitslücken vor der Veröffentlichung den Herstellern mitgeteilt, so dass einige bereits Sicherheitsupdates bereitgestellt haben


== Alternativen ==
== Alternativen ==
Als Alternative zu S/MIME kann auch [[Pretty Good Privacy|PGP]] bzw. [[OpenPGP]] unter Verwendung einer [[Public-Key-Infrastruktur]] (PKI) eingesetzt werden. Die beiden Verfahren sind allerdings nicht kompatibel, auch wenn sie teilweise die gleichen Verschlüsselungsverfahren einsetzen, da sie unterschiedliche Datenformate verwenden. Üblich sind hier [[PGP/INLINE]] oder [[PGP/MIME]]. Mit [[Pretty Easy privacy]] soll der Einsatz von S/MIME oder PGP automatisiert und somit massiv vereinfacht werden.
Als Alternative zu S/MIME kann auch [[Pretty Good Privacy|PGP]] bzw. [[OpenPGP]] unter Verwendung einer [[Public-Key-Infrastruktur]] (PKI) eingesetzt werden
* Die beiden Verfahren sind allerdings nicht kompatibel, auch wenn sie teilweise die gleichen Verschlüsselungsverfahren einsetzen, da sie unterschiedliche Datenformate verwenden. Üblich sind hier [[PGP/INLINE]] oder [[PGP/MIME]]
* Mit [[Pretty Easy privacy]] soll der Einsatz von S/MIME oder PGP automatisiert und somit massiv vereinfacht werden




Zeile 75: Zeile 131:
== Anhang ==
== Anhang ==
=== Siehe auch ===
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
* [[Thunderbird/SMIME]]
* [[Digitales Zertifikat]]
* [[Digitale Signatur]]
* [[Elektronische Signatur]]
 
==== Sicherheit ====
==== Sicherheit ====
==== Dokumentation ====
==== Dokumentation ====
===== RFC =====
===== RFC =====
{| class="wikitable sortable options"
{| class="wikitable options"
|-
! RFC !! Titel !! Staus
|-
| [https://www.rfc-editor.org/rfc/8551 8551] || Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification || aktuell
|-
| [https://www.rfc-editor.org/rfc/5751 5751] || Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification || veraltet
|-
|-
! RFC !! Titel
| [https://www.rfc-editor.org/rfc/3851 3851] || Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification || veraltet
|-
|-
| [https://www.rfc-editor.org/rfc/0000 0000] ||  
| [https://www.rfc-editor.org/rfc/2633 2633] || S/MIME Version 3 Message Specification || veraltet
|-
| [https://www.rfc-editor.org/rfc/2311 2311] || S/MIME Version 2 Message Specification || veraltet
|}
 
 
{| class="wikitable options"
|-
! RFC !! Titel !! Status
|-
| [https://www.rfc-editor.org/rfc/8550 8550] || S/MIME 4.0 Certificate Handling || aktuell
|-
| [https://www.rfc-editor.org/rfc/5750 5750] || S/MIME 3.2 Certificate Handling || veraltet
|-
| [https://www.rfc-editor.org/rfc/3850 3850] || S/MIME 3.1 Certificate Handling || veraltet
|-
| [https://www.rfc-editor.org/rfc/2632 2632] || S/MIME 3.0 Certificate Handling || veraltet
|}
|}


===== Man-Pages =====
===== Info-Pages =====
==== Links ====
==== Links ====
===== Projekt =====
===== Projekt =====
# https://datatracker.ietf.org/wg/smime/about/
# https://tools.ietf.org/wg/smime/
===== Weblinks =====
===== Weblinks =====
 
# [http://pgp.blafusel.de/ Quis custodiet custodes?] Anleitung zur Nutzung von S/MIME und [[GNU Privacy Guard|PGP]] unter Windows in [[Mozilla Thunderbird]] und [[Microsoft Outlook]] 2013
* [https://datatracker.ietf.org/wg/smime/about/ S/MIME IETF Working Group].
# [http://kb.mozillazine.org/Getting_an_SMIME_certificate Getting an SMIME certificate.] MozillaZine Knowledge Base
* [https://tools.ietf.org/wg/smime/ S/MIME Status Page.] [[Internet Engineering Task Force|IETF]].
# [http://www.openpgp-schulungen.de/kurzinfo/openpgp-smime/ OpenPGP vs.&nbsp; S/MIME.] openpgp-schulungen.de
* [http://pgp.blafusel.de/ Quis custodiet custodes?] Anleitung zur Nutzung von S/MIME und [[GNU Privacy Guard|PGP]] unter Windows in [[Mozilla Thunderbird]] und [[Microsoft Outlook]] 2013.
# [https://www.globaltrustpoint.com/ Global TrustPoint.] Trustcenterunabhängige Metasuchmaschine für PGP und X.509 Zertifikate
* [http://kb.mozillazine.org/Getting_an_SMIME_certificate Getting an SMIME certificate.] MozillaZine Knowledge Base.
* [http://www.openpgp-schulungen.de/kurzinfo/openpgp-smime/ OpenPGP vs. S/MIME.] openpgp-schulungen.de
* [https://www.globaltrustpoint.com/ Global TrustPoint.] Trustcenterunabhängige Metasuchmaschine für PGP und X.509 Zertifikate
 
= TMP =
== Siehe auch ==
* [[Digitales Zertifikat]]
* [[Digitale Signatur]]
* [[Elektronische Signatur]]
 
== Normen und Standards ==
S/MIME wird fortwährend weiterentwickelt:
* {{RFC-Internet |RFC=2311 |Titel=S/MIME Version 2 Message Specification |Datum=1998 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=2633 |Titel=S/MIME Version 3 Message Specification |Datum=1999 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=3851 |Titel=Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification |Datum=2004 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=5751 |Titel=Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification |Datum=2010 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=8551 |Titel=Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification |Datum=2019}}
 
Zusätzlich gibt es eine weitere S/MIME-Reihe, die sich mit dem Zertifikatshandling und Sperrlisten beschäftigt:
* {{RFC-Internet |RFC=2632 |Titel=S/MIME 3.0 Certificate Handling |Datum=1999 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=3850 |Titel=S/MIME 3.1 Certificate Handling |Datum=2004 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=5750 |Titel=S/MIME 3.2 Certificate Handling |Datum=2010 |Kommentar=veraltet}}
* {{RFC-Internet |RFC=8550 |Titel=S/MIME 4.0 Certificate Handling |Datum=2019}}


[[Kategorie:Kryptologischer Standard]]
[[Kategorie:Kryptologischer Standard]]
[[Kategorie:Abkürzung]]
[[Kategorie:E-Mail]]
[[Kategorie:E-Mail]]
[[Kategorie:Multipurpose Internet Mail Extensions]]
[[Kategorie:Multipurpose Internet Mail Extensions]]
[[Kategorie:Internet Engineering Task Force|IETF]]
</noinclude>
</noinclude>

Aktuelle Version vom 1. September 2024, 09:02 Uhr

Secure Multipurpose Internet Mail Extensions (S/MIME) - Kurzbeschreibung

Beschreibung

Secure Multipurpose Internet Mail Extensions (S/MIME) ist ein Standard zu

von

durch

S/MIME wird in vielen Protokollen zur Absicherung in der Anwendungsschicht (Application Layer) eingesetzt

Typische Einsatzfälle von S/MIME

In der Praxis kann S/MIME (Inhaltsebene) mit TLS (Transportebene) kombiniert werden

Funktion

RFC 1847 (1995) definiert zwei Content-Types für MIME

  • Das multipart/signed-Format zur Signierung einer E-Mail und das multipart/encrypted-Format zu deren Verschlüsselung
  • Eine E-Mail kann dabei nur signiert, nur verschlüsselt oder beiden Operationen unterzogen werden
  • Sowohl S/MIME (RFC 2633), die beide erst später spezifiziert wurden, verwenden multipart/signed, wohingegen multipart/encrypted nur von OpenPGP verwendet wird
  • S/MIME definiert (auch) für Verschlüsselung den neuen Content-Type application/pkcs7-mime
  • S/MIME wird von den meisten modernen Mailclients unterstützt
  • Es erfordert X.509-basierte Zertifikate für den Betrieb

Multipart/Signed

Das Format enthält genau zwei Blöcke

  • Der erste enthält die Daten, inklusive des MIME-Headers, über welche die digitale Signatur erstellt wurde
  • Der zweite enthält die Informationen, um die Signatur zu überprüfen
  • Die Mail bleibt dadurch auch für E-Mail-Clients lesbar, die kein S/MIME unterstützen
  • Deshalb ist multipart/signed die empfohlene von mehreren möglichen S/MIME-Methoden

application/pkcs7-mime

Der Content-Type application/pkcs7-mime hat den optionalen Parameter smime-type, der die Art der Daten beschreibt (ohne dass sie dafür decodiert werden müssen): enveloped-data (Verschlüsselung), signed-data (Signatur), certs-only (Zertifikat)

  • Außerdem zeigt der Dateiname des optionalen, aber erbetenen Headereintrags Content-Disposition die Art der Daten an: smime.p7m (signierte oder verschlüsselte Daten), smime.p7c (Zertifikat), smime.p7s (Signatur)

Ein Abschnitt mit verschlüsselten Daten enthält ebenfalls genau zwei Blöcke

  • Der erste enthält benötigte Informationen zur Entschlüsselung
  • Im zweiten Block sind die verschlüsselten Daten enthalten
  • Der Mailrumpf ist komplett verschlüsselt und kann somit nur vom vorgesehenen Empfänger gelesen werden
  • Damit ist auch ein Scannen auf Viren und Spam erst auf dem Endgerät möglich
  • Die Mailheader (auch der Betreff) sind dagegen weiterhin unverschlüsselt und sollten daher keine vertraulichen Informationen enthalten

So sieht eine verschlüsselte Nachricht beispielhaft aus: 

Content-Type: application/pkcs7-mime; smime-type=enveloped-data
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V

Zur Verschlüsselung einer E-Mail muss der Absender den öffentlichen Schlüssel des Empfängers kennen, den er beispielsweise dem Zertifikat einer zuvor vom Empfänger erhaltenen signierten E-Mail entnehmen kann

  • Ein E-Mail-Client vereinfacht die Handhabung, indem er automatisch alle erhaltenen Zertifikate speichert

Klassifizierung der Zertifikate

Die Anbieter von Zertifikaten für sichere E-Mail-Kommunikation klassifizieren diese meist in vier auf einander aufbauenden Klassen:

  • Klasse 1 – Nur die Echtheit der E-Mail-Adresse wird durch eine Zertifizierungsstelle (CA) bestätigt
  • Klasse 2 – Zusätzlich zur E-Mail-Adresse wird der dazugehörende Name (CN) in das Zertifikat mit aufgenommen, sowie ggf
  • die Organisation/Firma (OU)
  • Klasse 3 – Die Daten der Klasse 3 werden mithilfe von Drittdatenbanken, Ausweiskopien, Handelsregisterauszügen etc
  • zusätzlich verifiziert
  • Klasse 4 – Bei Zertifikaten der Klasse 4 muss der Antragsteller sich zusätzlich persönlich ausweisen

Kostenlose Zertifikate

Manche Unternehmen und nichtkommerzielle Organisationen bieten kostenlose S/MIME-Zertifikate an

  • Es können dabei nach einer Registrierung mehrere Zertifikate erstellt werden, die aber erst nach einer gewissen Anzahl von Identitätsnachweisen den Namen beinhalten
  • Diese können durch Mitglieder in einem Web of Trust oder anderen vertrauenswürdigen Stellen wie Rechtsanwälten oder Wirtschaftstreuhändern erfolgen
  • Grundsätzlich zerstört eine Ausstellung von Zertifikaten durch Anbieter ohne Identitätsüberprüfung des Antragstellers den Grundgedanken des sicheren Informationsaustauschs zwischen zwei Computern im Netz
  • So ist es bei einigen Zertifikatsausstellern tatsächlich möglich, mit erfundenen Betreiberangaben ein Zertifikat für eine völlig fremde Website zu erhalten
  • Der Benutzer würde über ein Umleiten der Informationsübertragung beispielsweise durch den Browser nicht mehr informiert, wenn die Zertifizierungsstelle durch den Browserhersteller von vornherein als vertrauenswürdig eingestuft wurde

CAcert, eine nichtkommerzielle, gemeinschaftsbetriebene CA (Certificate Authority), stellt kostenlose Zertifikate zur Verfügung

  • Sie ist jedoch in vielen E-Mail-Clients und Webbrowsern nicht in der Zertifikatsdatenbank als vertrauenswürdige Zertifizierungsstelle eingetragen
  • Ein Benutzer, der eine Verbindung zu einem Server mit CAcert-Zertifikat aufbaut oder eine E-Mail mit einem von CAcert signierten S/MIME-Zertifikat erhält, wird daher die Fehlermeldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte (sofern CAcert nicht zuvor manuell als vertrauenswürdig im Programm eingetragen wurde)

Weiterhin werden kostenlose Zertifikate der Klasse 1 (teilweise mit reduzierter Gültigkeitsdauer unter einem Jahr, beispielsweise als Testzertifikat) von Firmen angeboten, welche im Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden

  • Diese kostenlosen S/MIME-Zertifikate sind jedoch uneingeschränkt funktionsfähig
  • Beispiele für diese meist für den Privatgebrauch gedachten Zertifikate sind:
  • Deutsches Gesundheitsnetz (DGN) – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
  • ACTALIS S.p.A. (1 Jahr Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
  • free secure email eID von WISeKey (3 Monate Gültigkeit – Achtung: „private-key“ wird vom Server generiert und ist damit dem Anbieter bekannt)
  • Secorio S/MIME (1 Monat Gültigkeit, verwendet Zertifikate von Comodo)
  • GlobalSign als Free Trial PersonalSign 1 Certificate (30 Tage Gültigkeit)
  • Volksverschlüsselung (3 Jahre Gültigkeit, in gängigen Zertifikatsdatenbanken nicht als vertrauenswürdig gelistet, nur für privaten Gebrauch)

Außerdem ist es möglich, Nachrichten mit einem selbst signierten Zertifikat zu verschlüsseln

  • Dazu ist ein selbst erstelltes Stammzertifikat notwendig, das die eigene Zertifizierungsstelle repräsentiert
  • Damit können prinzipiell beliebige Zertifikate signiert werden
  • Alle Kommunikationspartner müssen jedoch zunächst dieses Stammzertifikat importieren und diesem vertrauen, bevor eine verschlüsselte Kommunikation möglich wird

Mithilfe von SMIMEA ist es möglich, dass der Administrator der Domain ein (Stamm-)Zertifikat über DNS veröffentlicht und so die Beglaubigung übernimmt

Sicherheit Schlüsselerzeugung

Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des verwendeten Public-Key-Verschlüsselungsverfahrens ein Schlüsselpaar aus öffentlichem und privatem Schlüssel benötigt

  • Beide Schlüssel können durch einen Dienstleister erstellt werden
  • Die Erstellung des privaten Schlüssels durch den Dienstleister setzt das Vertrauen voraus, dass davon keine Kopie/Backup/Logdatei oder Ähnliches nach der Übergabe beim Dienstleister zurückbleibt
  • Seriöse Dienstleister Certificate Authorities (CAs) bieten stattdessen ein Verfahren an, bei welchem die Erstellung des privaten Schlüssels durch den Kunden erfolgt und zu keinem Zeitpunkt der CA übergeben werden muss

Je nach Schutzbedarf kann der private Schlüssel und die CSR-Datei entweder bequem im Browser erzeugt werden über eine Website, welche die CA bereitstellt oder im anderen Extrem kann dies auf einem separaten Computer erfolgen, der nur für diesen Einsatzzweck beschafft und dafür genutzt wird und über Konsolen-Befehle bedient wird

  • Das finale öffentliche Zertifikat der CA wird oft per E-Mail zugestellt
  • Seriöse CAs bieten jedes von ihr erzeugte öffentliche Zertifikat in einem eigenen öffentlich zugänglichen Zertifikatsverzeichnis inklusive öffentliche Sperrliste an

Für Organisationen, die sehr viele S/MIME-Zertifikate benötigen, bieten die CAs auch besondere Zertifikatsmanager-Verwaltungsprogramme an, mit denen, auch bei erhöhtem Schutzbedarf, der Verwaltungsaufwand sinkt

Sicherheit S/MIME bei E-Mail

Vorlage:Hauptartikel Zur Sicherheit der signierten und verschlüsselten Kommunikation per E-Mail mittels S/MIME und PGP wurden 2018 und 2019 von einer Gruppe von deutschen Sicherheitsforschern diverse Studien durchgeführt:

  • Das kryptografische Verfahren ist weiterhin sicher, aber die Umsetzung als Protokoll S/MIME weist einige konzeptionelle Schwächen auf durch gewisse optionale Varianten
  • Diese Schwächen wurden unter dem Schlagwort Efail in der Öffentlichkeit diskutiert
  • Mit RFC 8551 wurden die Änderungsvorschläge aufgegriffen als S/MIME 4.0 und Efail wird auch namentlich im RFC erwähnt
  • 2019 wurden diese Studien um die Fragestellung erweitert, inwieweit sich handelsübliche E-Mail-Software bei der Signaturprüfung auf der Seite des Empfängers austricksen lässt, wenn die Signatur per S/MIME mal als CMS oder mal auf dem Anhang angewendet wird oder eine E-Mail zwei Signaturen enthält
  • Die Forscher haben die Sicherheitslücken vor der Veröffentlichung den Herstellern mitgeteilt, so dass einige bereits Sicherheitsupdates bereitgestellt haben

Alternativen

Als Alternative zu S/MIME kann auch PGP bzw. OpenPGP unter Verwendung einer Public-Key-Infrastruktur (PKI) eingesetzt werden

  • Die beiden Verfahren sind allerdings nicht kompatibel, auch wenn sie teilweise die gleichen Verschlüsselungsverfahren einsetzen, da sie unterschiedliche Datenformate verwenden. Üblich sind hier PGP/INLINE oder PGP/MIME
  • Mit Pretty Easy privacy soll der Einsatz von S/MIME oder PGP automatisiert und somit massiv vereinfacht werden



Anhang

Siehe auch

Sicherheit

Dokumentation

RFC
RFC Titel Staus
8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification aktuell
5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification veraltet
3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification veraltet
2633 S/MIME Version 3 Message Specification veraltet
2311 S/MIME Version 2 Message Specification veraltet


RFC Titel Status
8550 S/MIME 4.0 Certificate Handling aktuell
5750 S/MIME 3.2 Certificate Handling veraltet
3850 S/MIME 3.1 Certificate Handling veraltet
2632 S/MIME 3.0 Certificate Handling veraltet

Links

Projekt
  1. https://datatracker.ietf.org/wg/smime/about/
  2. https://tools.ietf.org/wg/smime/
Weblinks
  1. Quis custodiet custodes? Anleitung zur Nutzung von S/MIME und PGP unter Windows in Mozilla Thunderbird und Microsoft Outlook 2013
  2. Getting an SMIME certificate. MozillaZine Knowledge Base
  3. OpenPGP vs.  S/MIME. openpgp-schulungen.de
  4. Global TrustPoint. Trustcenterunabhängige Metasuchmaschine für PGP und X.509 Zertifikate
Abgerufen von „https://wiki.foxtom.de/index.php?title=Secure_Multipurpose_Internet_Mail_Extensions&oldid=106704“