--- a/Makefile Mon Mar 30 14:00:40 2015 +0200
+++ b/Makefile Mon Mar 30 14:17:23 2015 +0200
@@ -1,4 +1,4 @@
-doc = sichere-email
+doc = dane
txt = ${doc}.txt
html = out.html/${doc}.html
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dane.txt Mon Mar 30 14:17:23 2015 +0200
@@ -0,0 +1,267 @@
+Sichere E-Mail
+==============
+:Author: Heiko Schlittermann
+:Email: hs@schlittermann.de
+:toc:
+
+Übersicht
+---------
+
+Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von
+E-Mail. In diesem kurzen Paper möchte ich aufklären über das derzeit
+technisch Umsetzbare.
+
+== E-Mail-Übertragung
+
+Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die
+Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine
+Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim
+Internet-Provider oder, meistens bei größeren Firmen, in einer internen
+Infrastruktur. Die Adresse bzw. der Name des Submission-Servers sind im
+MUA per Konfiguration fest hinterlegt.
+
+Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis
+zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt.
+Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt.
+
+Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen
+greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen
+Webmail-Client zu.
+
+image::dia/transport.png[Transport der Mail]
+
+== Angriffspunkte
+
+Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt
+für die Anmeldung am Submission-Server, für den Transport der Mails, für
+die DNS-Information und auch für das Abrufen der Nachrichten.
+
+Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig,
+auch Überwachungsmaßnahmen werden schnell zu Angriffen.
+
+=== Übertragung der Mails
+
+Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der
+Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen
+können.
+
+Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das
+Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die
+Verbindung zu entführen und sich für das Zielsystem auszugeben.
+
+=== Namensauflösung
+
+Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing,
+oder durch die Manipulation der DNS-Daten, aus denen der Client die
+IP-Adresse des Zielsystems erfährt.
+
+
+== Stand der Technik
+
+Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt
+übertragen.
+
+=== Übertragung der Mails
+
+TLS ist schon sehr lange Stand der Technik für verschlüsselte
+Datenübertragung. Die Authentizität der Kommunikationspartner wird über
+X509-Zertifikate (SSL-Zertifikate) festgestellt. Üblicherweise weist
+sich der Server in einer Verbindung mit seinem Zertifikat aus. Der
+Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem
+richtigen Server verbunden ist.
+
+Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit
+dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats
+zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm
+bekannten und vertrauenswürdigen CA unterschrieben ist.
+
+Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des
+Übertragungsweges aushandeln. Jeoch werden hier sehr oft
+Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese
+Zertifikate sind entweder selbst signiert oder von lokalen CAs
+bestätigt.
+
+Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA
+mit Smarthost) ist es möglich, die Information über das
+Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen.
+Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß
+ist.
+
+=== Namensauflösung
+
+DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll
+ist sehr anfällig für Angriffe.
+
+Bei DNS-Informationen geht es *immer* um öffentlich verfügbare
+Information, hier geht es also nicht die Vertraulichkeit, sondern die
+Authentizität der Daten.
+
+Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der
+Domaindaten), können die Daten mit TSIG geschützt werden. Dieses
+Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten
+Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die
+eine große Zahl von DNS-Servern fragen.
+
+Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls
+und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren.
+Damit kann der Client die erhaltene Antwort validieren.
+
+== Das technisch Machbare - Absicherung
+
+Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend.
+Verbindungen können entführt werden, DNS-Antworten sind nur selten mit
+DNSSec geschützt.
+
+=== Übertragung der Mails
+
+Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines
+Kommunikationspartners prüfen! Jedoch ist die Konvention von HTTPS
+(Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation
+übertragbar.
+
+Der Client benötigt also einen zweiten Kanal, über den er die
+Information erhält, die er zum Validieren des Server-Zertifikats
+benötigt. DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec.
+
+=== Namensauflösung
+
+Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert
+werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das
+gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu
+validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit
+auch die Informationen über die Adresse des nächsten Mailhosts
+validierbar und auch die Information zum Überprüfen des
+Server-Zertifikats des nächsten Mailhosts.
+
+== Umsetzung
+
+Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen
+kombiniert werden - TLS, Zertifikate und Überprüfung von
+DNS-Informationen.
+
+Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie
+Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz
+(CA) geprüft werden kann: die notwendige Information wird im DNS
+(gesichert über DNSSec) abgelegt.
+
+Die Initiative liegt in erster Linie beim Empfänger der Mail, *er* muss
+Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst
+dann *kann* der Client die beschriebenen Mechanismen nutzen.
+
+Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu
+unterstützen, sowohl auf der Server- als auch auf der Clientseite.
+
+=== Übertragung
+
+==== Client
+
+Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen.
+Mailclients *müssen* Zertifate der Server prüfen. MTA können das am
+einfachsten mit DANE.
+
+==== Server
+
+Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen
+Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese
+Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie
+selbstsigniert sind. Die Serverdienste müssen den Clients die
+Möglichkeit der Verschlüsselung anzeigen.
+
+=== Namensauflösung
+
+==== Client
+
+Auf der Clientseite müssen validierende Resolver verwendet werden, als
+Software, die in der Lage ist, neben der eigentlichen Namensauflösung
+auch die Gültigkeit der Antwort zu überprüfen.
+
+==== Server
+
+Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone
+muss signiert sein und die Schlüssel müssen an die Elternzone
+weitergegeben werden. Normalerweise ist dafür der Registrar der Domain
+verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt
+bisher über die erforderlichen Schnittstellen.
+
+Im DNS muss für die Zielserver ein Datensatz eingetragen sein,
+dieser enthält die Information über das Server-Zertifikat.
+
+== Schlussfolgerung
+
+Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS
+*und* DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist
+bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind
+und Fachwissen über diese Bereiche vorhanden.
+
+Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung
+(S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit
+zwischen den einzelnen Mailhosts gewährleisten.
+
+
+
+[glossary]
+== Glossary
+
+[glossary]
+
+CA::
+ Certificate Authority - eine vertrauenswürdige Organisation, die
+ sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden.
+ Dazu überprüft sie die Identität des Antragsstellers.
+
+DNS::
+ Domain Name System - eine verteilte Datenbank, die Informationen über
+ Domains, IP-Adressen, verantwortliche Mailserver bereitstellt.
+
+IMAP::
+ Internet Message Access Protocol - mit diesem Protokoll können MUAs auf
+ Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501
+ u.a.)
+
+MDA::
+ Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und
+ in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline)
+
+MTA::
+ Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“
+ nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP)
+
+MUA::
+ Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das
+ ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,…
+ Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail
+ damit machen können. (Protokolle: SMTP, IMAP, POP3)
+
+POP3::
+ Post Office Protocol - mit diesem Protokoll können MUAs auf Mails
+ zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC
+ 1939)
+
+SMTP::
+ Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails
+ übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC
+ 5321)
+
+TLS/SSL::
+ Transport Layer Security, Secure Socket Layer - ein Protokoll, mit
+ dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei
+ Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS,
+ ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0)
+
+TSIG::
+ Transaction Signature - bei der Übertragung von DNS-Information ein
+ Verfahren zur Authentifizierung und Integritätsprüfung
+
+Zertifikat | X509-Zertifikat::
+ Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten
+ Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer
+ CA unterzeichnet, die damit bestätigt, die im Zertifikat
+ festgehaltenen Eigenschaften überprüft zu haben.
+
+
+== Disclaimer
+
+Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht,
+nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran
+darüber, dass jeder eine andere Sichtweise auf _unwichtig_ hat.
+
--- a/sichere-email.txt Mon Mar 30 14:00:40 2015 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,267 +0,0 @@
-Sichere E-Mail
-==============
-:Author: Heiko Schlittermann
-:Email: hs@schlittermann.de
-:toc:
-
-Übersicht
----------
-
-Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von
-E-Mail. In diesem kurzen Paper möchte ich aufklären über das derzeit
-technisch Umsetzbare.
-
-== E-Mail-Übertragung
-
-Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die
-Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine
-Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim
-Internet-Provider oder, meistens bei größeren Firmen, in einer internen
-Infrastruktur. Die Adresse bzw. der Name des Submission-Servers sind im
-MUA per Konfiguration fest hinterlegt.
-
-Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis
-zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt.
-Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt.
-
-Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen
-greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen
-Webmail-Client zu.
-
-image::dia/transport.png[Transport der Mail]
-
-== Angriffspunkte
-
-Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt
-für die Anmeldung am Submission-Server, für den Transport der Mails, für
-die DNS-Information und auch für das Abrufen der Nachrichten.
-
-Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig,
-auch Überwachungsmaßnahmen werden schnell zu Angriffen.
-
-=== Übertragung der Mails
-
-Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der
-Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen
-können.
-
-Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das
-Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die
-Verbindung zu entführen und sich für das Zielsystem auszugeben.
-
-=== Namensauflösung
-
-Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing,
-oder durch die Manipulation der DNS-Daten, aus denen der Client die
-IP-Adresse des Zielsystems erfährt.
-
-
-== Stand der Technik
-
-Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt
-übertragen.
-
-=== Übertragung der Mails
-
-TLS ist schon sehr lange Stand der Technik für verschlüsselte
-Datenübertragung. Die Authentizität der Kommunikationspartner wird über
-X509-Zertifikate (SSL-Zertifikate) festgestellt. Üblicherweise weist
-sich der Server in einer Verbindung mit seinem Zertifikat aus. Der
-Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem
-richtigen Server verbunden ist.
-
-Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit
-dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats
-zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm
-bekannten und vertrauenswürdigen CA unterschrieben ist.
-
-Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des
-Übertragungsweges aushandeln. Jeoch werden hier sehr oft
-Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese
-Zertifikate sind entweder selbst signiert oder von lokalen CAs
-bestätigt.
-
-Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA
-mit Smarthost) ist es möglich, die Information über das
-Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen.
-Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß
-ist.
-
-=== Namensauflösung
-
-DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll
-ist sehr anfällig für Angriffe.
-
-Bei DNS-Informationen geht es *immer* um öffentlich verfügbare
-Information, hier geht es also nicht die Vertraulichkeit, sondern die
-Authentizität der Daten.
-
-Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der
-Domaindaten), können die Daten mit TSIG geschützt werden. Dieses
-Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten
-Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die
-eine große Zahl von DNS-Servern fragen.
-
-Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls
-und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren.
-Damit kann der Client die erhaltene Antwort validieren.
-
-== Das technisch Machbare - Absicherung
-
-Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend.
-Verbindungen können entführt werden, DNS-Antworten sind nur selten mit
-DNSSec geschützt.
-
-=== Übertragung der Mails
-
-Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines
-Kommunikationspartners prüfen! Jedoch ist die Konvention von HTTPS
-(Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation
-übertragbar.
-
-Der Client benötigt also einen zweiten Kanal, über den er die
-Information erhält, die er zum Validieren des Server-Zertifikats
-benötigt. DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec.
-
-=== Namensauflösung
-
-Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert
-werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das
-gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu
-validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit
-auch die Informationen über die Adresse des nächsten Mailhosts
-validierbar und auch die Information zum Überprüfen des
-Server-Zertifikats des nächsten Mailhosts.
-
-== Umsetzung
-
-Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen
-kombiniert werden - TLS, Zertifikate und Überprüfung von
-DNS-Informationen.
-
-Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie
-Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz
-(CA) geprüft werden kann: die notwendige Information wird im DNS
-(gesichert über DNSSec) abgelegt.
-
-Die Initiative liegt in erster Linie beim Empfänger der Mail, *er* muss
-Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst
-dann *kann* der Client die beschriebenen Mechanismen nutzen.
-
-Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu
-unterstützen, sowohl auf der Server- als auch auf der Clientseite.
-
-=== Übertragung
-
-==== Client
-
-Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen.
-Mailclients *müssen* Zertifate der Server prüfen. MTA können das am
-einfachsten mit DANE.
-
-==== Server
-
-Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen
-Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese
-Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie
-selbstsigniert sind. Die Serverdienste müssen den Clients die
-Möglichkeit der Verschlüsselung anzeigen.
-
-=== Namensauflösung
-
-==== Client
-
-Auf der Clientseite müssen validierende Resolver verwendet werden, als
-Software, die in der Lage ist, neben der eigentlichen Namensauflösung
-auch die Gültigkeit der Antwort zu überprüfen.
-
-==== Server
-
-Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone
-muss signiert sein und die Schlüssel müssen an die Elternzone
-weitergegeben werden. Normalerweise ist dafür der Registrar der Domain
-verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt
-bisher über die erforderlichen Schnittstellen.
-
-Im DNS muss für die Zielserver ein Datensatz eingetragen sein,
-dieser enthält die Information über das Server-Zertifikat.
-
-== Schlussfolgerung
-
-Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS
-*und* DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist
-bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind
-und Fachwissen über diese Bereiche vorhanden.
-
-Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung
-(S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit
-zwischen den einzelnen Mailhosts gewährleisten.
-
-
-
-[glossary]
-== Glossary
-
-[glossary]
-
-CA::
- Certificate Authority - eine vertrauenswürdige Organisation, die
- sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden.
- Dazu überprüft sie die Identität des Antragsstellers.
-
-DNS::
- Domain Name System - eine verteilte Datenbank, die Informationen über
- Domains, IP-Adressen, verantwortliche Mailserver bereitstellt.
-
-IMAP::
- Internet Message Access Protocol - mit diesem Protokoll können MUAs auf
- Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501
- u.a.)
-
-MDA::
- Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und
- in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline)
-
-MTA::
- Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“
- nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP)
-
-MUA::
- Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das
- ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,…
- Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail
- damit machen können. (Protokolle: SMTP, IMAP, POP3)
-
-POP3::
- Post Office Protocol - mit diesem Protokoll können MUAs auf Mails
- zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC
- 1939)
-
-SMTP::
- Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails
- übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC
- 5321)
-
-TLS/SSL::
- Transport Layer Security, Secure Socket Layer - ein Protokoll, mit
- dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei
- Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS,
- ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0)
-
-TSIG::
- Transaction Signature - bei der Übertragung von DNS-Information ein
- Verfahren zur Authentifizierung und Integritätsprüfung
-
-Zertifikat | X509-Zertifikat::
- Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten
- Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer
- CA unterzeichnet, die damit bestätigt, die im Zertifikat
- festgehaltenen Eigenschaften überprüft zu haben.
-
-
-== Disclaimer
-
-Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht,
-nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran
-darüber, dass jeder eine andere Sichtweise auf _unwichtig_ hat.
-