--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/help/client/techn-referenz.rst	Mon Sep 22 13:02:11 2014 +0200
@@ -0,0 +1,170 @@
+===================
+Technische Referenz
+===================
+
+
+Welche Zertifikatsspeicher werden verwendet?
+============================================
+
+Damit Zertifikaten in Anwendungen (wie z.B. Browser oder E-Mail-Klient)
+vertraut werden kann, müssen die zugehörigen Wurzelzertifikate in den passenden
+Zertifikatsspeichern des Systems installiert werden.
+TrustBridge übernimmt diesen Zugriff auf die Zertifikatsspeicher.
+
+Es gibt zwei gängige Zertifikatsspeicher, die von TrustBridge und den meisten
+Anwendungen unterstützt werden:
+
+* der Mozilla NSS-Zertifikatsspeicher ("Network Security Services") und 
+* der Windows-System-Zertifikatsspeicher.
+
+
+Chrome bzw. Chromium verwendet unter Windows den Windows-System-Speicher und unter
+Ubuntu den NSS-Zertifikatsspeicher. Die nachfolgende Abbildung veranschaulicht 
+die verwendeten Zertifikatsspeicher unter Windows und GNU/Linux.
+
+.. figure:: _static/stores.png
+   :width: 100%
+   :alt: Übersicht der Zertifikatsspeicher
+
+   *Abbildung 1: Übersicht der Zertifikatsspeicher*
+
+Windows-Zertifikatsspeicher
+---------------------------
+
+Der Windows 7 und 8 Zertifikatsspeicher kann in drei große Gruppen aufgeteilt werden:
+
+#. Zertifikate des aktuellen Benutzers
+#. Zertifikate für alle Benutzer (Lokaler Computer)
+#. Zertifikate für Systemdienste
+
+Diese Gruppen unterteilen sich wieder in eine Reihe von logischen Speichern.
+
+Für die Installation von vertrauenswürdigen Wurzelzertifikaten ist der
+logische *Root*-Speicher relevant. Nur dort eingetragene Zertifikate
+werden als *Trust Anchor* (Vertrauensanker) angesehen und zur
+Validierung des Vertrauenspfads zu den weiteren Zertifikaten
+verwendet.
+
+Der logische *Disallowed*-Speicher hat immer Vorrang. Befindet sich ein Zertifikat
+sowohl im *Root* als auch im *Disallowed*-Speicher, gilt es als nicht vertrauenswürdig.
+
+
+**Einschränkungen:** 
+Um unbefugte Manipulationen am Zertifikatsspeicher zu verhindern, werden von Microsoft
+seit Windows XP SP2 folgende Schutzmaßnahmen vorgesehen:
+
+#. Um Zertifikate für alle Benutzer des lokalen Computers zu
+   bearbeiten, sind erhöhte Privilegien (Administrationsrechte)
+   erforderlich.
+#. Änderungen (Löschen / Hinzufügen von Zertifikaten) am
+   *Root*-Speicher des aktuellen Nutzers erfordern die explizite
+   Einwilligung des Nutzers (siehe nachfolgende Abbildung), sofern der
+   Prozess keine erhöhten Privilegien besitzt.
+
+
+.. figure:: _static/sicherheitswarnung.png
+   :alt: Windows-Sicherheitswarnung 
+
+   *Abbildung 2: Sicherheitswarnung beim Hinzufügen eines Wurzelzertifikats ohne Administrator-Rechte*
+
+
+
+Mozilla NSS-Zertifikatsspeicher
+-------------------------------
+Die Mozilla-Anwendungen Thunderbird und Firefox, sowie Chromium unter
+Ubuntu, verwenden die Mozilla "Network Security
+Services" (NSS) Zertifikatsspeicher. 
+
+Mozilla liefert den NSS-Zertifikatsspeicher mit einer Auswahl von
+voreingesetllten vertrauenswürdigen bzw. nicht
+vertrauenswürdigen Zertifikaten aus.
+
+**Einschränkungen:**
+
+* Anwendungen, die den NSS-Zertifikatsspeicher verwenden, sollten vor dem Zugriff geschlossen
+  werden.
+* Um den NSS-Speicher anderer Nutzer zu manipulieren, sind erhöhte Rechte nötig.
+* Um den NSS-Standard für neue Profile vorzugeben, sind abhängig vom Installationsort 
+  ggf. erhöhte Rechte nötig.
+
+
+
+Wie wird der Transport abgesichert?
+===================================
+TrustBridge sucht regelmäßig (alle 24 Stunden) auf dem offiziellen TrustBridge-Update-Server
+nach aktualisierten Zertifikatslisten und neuen Softwareversionen. 
+
+Sämtliche Transportprozesse sind kryptografisch nach aktuellem Stand
+der Technik gegen unbefugte Manipulationen (Authentizität und
+Integrität) gesichert. Es gibt drei Transportwege, die abgesichert
+werden müssen:
+
+#. Verfügbarkeit von Aktualisierungen prüfen:
+   Die regelmäßige Übertragung der Information, ob neue Aktualisierungen
+   von Zertifikatsliste oder Software verfügbar sind, wird über eine
+   HTTPS-Verbindung per TLS 1.2 (mit ECDSA brainpoolP256r1) durchgeführt.
+#. Zertifikatslisten-Update durchführen:
+   Ist eine neue Zertifikatsliste verfügbar, wird die ganze Liste
+   gebündelt übertragen. Die Zertifikatslistendatei ist signiert (RSA 3076). 
+   Vor einem Zertifikatslisten-Update wird sichergestellt, dass TrustBridge bereits in der
+   neusten Version installiert ist.
+#. Software-Update durchführen:
+   Ist eine neue TrustBridge-Version verfügbar, kann diese mit einem
+   Klick auf eine entsprechende Meldung heruntergeladen und installiert
+   werden. Es wird eine vollständige TrustBridge-Installationsdatei übertragen 
+   und im Hintergrund ausgeführt. Jede Software-Installationsdatei ist signiert.
+   Bei Fehlschlagen der Signaturprüfung (z.B. durch fehlerhaftes
+   Herunterladen) wird TrustBridge nicht aktualisiert. 
+
+
+
+Wie sieht das Datenformat einer Zertifikatsliste aus?
+=====================================================
+
+Die Zertifikatsliste ist eine einzelne Text-Datei, welche von der
+TrustBridge-Verwaltungsanwendung erzeugt wird. Diese Datei enthält
+alle benötigten Informationen und basiert auf einer zeilenbasierten
+Textformat. Dabei bleibt die Struktur für Menschen lesbar und die
+meisten Inhalte können mit Standardwerkzeugen sowohl de- als auch
+enkodiert werden.
+
+In der ersten Zeile der Datei ist die Base64-kodierte, kryptografische
+Signatur über alle folgenden Zeilen (inklusive der Zeilenenden)
+angegeben. So wird die Integrität und Authentizität dieser Daten vor
+der Verarbeitung gesichert.
+
+Einzelne Zeilen haben das Format ``<Buchstabe>:<Wert><CR><LF>``, wobei
+der Buchstabe angibt, welche Art von Wert folgt. Die Länge der Zeilen
+ist (für Version 1) auf 9999 Zeichen begrenzt, inklusive der beiden
+Zeichen für Zeilenenden.  Die Anzahl der Zeilen ist auf 1000
+beschränkt, was einer Dateigröße von maximal 10 Megabyte entspricht.
+(In der Praxis wird die Dateigröße aber deutlich unter 100 Kilobyte
+liegen.) Der Text wird in 7Bit-ASCII kodiert.
+
+Die Zertifikate selbst werden als Base64- und DER-kodierte Daten
+aufgeführt. Dies entspricht dem Inhalt gängiger .pem-Dateien - jedoch
+ohne den umschließenden BEGIN CERTIFICATE und END CERTIFICATE sowie
+ohne den Zeilenumbrüchen.
+
+Jede Zeile muss mit einem der folgenden gültigen Buchstaben beginnen:
+
+* ``S:`` Die Signatur der Zertifikatsliste.
+* ``F:`` Format-Version
+* ``D:`` Zeitpunkt der Listenerstellen (UTC)
+* ``I:`` Zu installierendes Zertifikat
+* ``R:`` Zu entfernendes Zertifikat
+
+
+Im Folgenden ein Beispiel für den Aufbau der Zertifikatslisten-Datei
+mit zwei zu installierenden Zertifikaten und einem zu löschenden
+Zertifikat. Die Signatur- und Zertifikatszeilen sind, aus Gründen der
+Übersichtlichkeit, in diesem Beispiel gekürzt:
+
+.. parsed-literal::
+    S:EjzX0sTkstnnGbPIC7n1a5WlYCFsthPl8OYplLyihR1RdqcUsSnikrVowFo8QgpMutcz0...
+    F:1
+    D:2014-01-03T12:30Z
+    I:MIIEiTCCA3GgAwIBAgIDAWn+MA0GCSqGSIb3DQBQUAMEAxCzAJBVBAYTAlVTMRcwFQYDV...
+    I:MIIHojCCBoqgAwIBAgIDAW96MA0GCSqGSIb3DQEBBQUAGMMQswCDVQQGEwJJTDEWMBQGA...
+    R:MIIGUjCCBTqgAwIBAgIODocAAQACqS54FrSbGvYwDQKoZIhvcNAQBQAwfDELMAkGA1UEB...
+