<commit_before>% vim: set tw=160:

\glsreset{wot}
\glsreset{cot}
\glsreset{ht}

\chapter{Anwendbare Signaturverfahren}
\index{Signaturverfahren}
\label{chap:Signaturverfahren}
Wie in \fref{sec:GrundlagenDefinitionen:DigitaleSignaturen:Verfahren} bereits vorgestellt, bieten sich \gls{openpgp} und \gls{x509} für den Einsatz in
\gls{xml-dsig} an. Um solche Signaturen in \gls{xhtml} für den Besucher einer \gls{website} nutzbar zu machen, müssen die dafür nötigen Komponenten in einem
\gls{webbrowser} vorhanden sein oder über eine Erweiterung nachrüstbar sein. Dazu wird der \gls{webbrowser}
\index{Firefox}Firefox\footnote{\url{http://www.mozilla.com/firefox/}} wegen seiner umfangreichen Möglichkeiten zur Erweiterung mittels sogenannter
\glspl{firefox-addon} auf die Integration von \gls{openpgp} und \gls{x509} untersucht. Auch die zunehmende Verbreitung von \gls{firefox} im europäischen Raum
von über $50\%$ \cite{firefox-verbreitung} positioniert diesen \gls{webbrowser} als bevorzugtes Ziel für eine solche Erweiterung.

\section{\glsentrytext{openpgp}}
\index{OpenPGP}
\label{sec:Signaturverfahren:OpenPGP}
Da \gls{openpgp} seine Verbreitung hauptsächlich im E-Mail-Verkehr \cite{2719799020071101} und zur kryptografischen Absicherung von Code und Programmen erfährt,
existiert in \gls{firefox} so wie auch in anderen, mit Stand Januar 2011, gängigen \gls{webbrowser}n keine direkte Schnittstelle zu einer
\gls{openpgp}-Implementierung.

\subsection{Verbreitung}
\gls{firefox} bietet in seinem Auslieferungszustand keine Unterstützung für \gls{openpgp}. Mit Stand Januar 2011 existieren jedoch zwei \glspl{firefox-addon},
\index{Firefox!FireGPG}FireGPG\footnote{\url{http://getfiregpg.org/s/home}} und
\index{Firefox!Monkeysphere}Monkeysphere\footnote{\url{http://web.monkeysphere.info/}}, welche \gls{gpg}, eine \gls{foss}-Implementierung von \gls{openpgp},
nutzen, um digitale Signaturen in \gls{firefox} zu verwenden. Im weiteren Sinne ist auch die Erweiterung Enigmail ein \gls{firefox-addon}, da es die selbe
Erweiterungsschnittstelle nutzt, es jedoch eine \gls{openpgp}-Erweiterung für das E-Mail-Programm \gls{thunderbird} ist.

FireGPG bietet eine einfache Erkennung und Prüfung von \gls{openpgp}-Signaturen, die als normaler Text im \gls{ascii} Armor Format \cite{openpgp:ietf} in
\glspl{webseite} eingebettet sind. Diese Textstellen werden dann in der Darstellung im Browser farblich hervorgehoben und Informationen zur Gültigkeit der
Signatur werden, beim Überfahren des Textes mit der Maus, angezeigt.

Monkeysphere dehnt, als \gls{firefox-addon}, das in \fref{sec:GrundlagenDefinitionen:Vertrauen:WOT} beschriebene \gls{wot} auf die \gls{pki}-Infrastruktur von
\gls{https} aus. Dabei bietet es sich als Option zur Validierung der Gültigkeit von Schlüsseln an, wenn keine \gls{cot} bis zu einem in \gls{firefox}
hinterlegten Root-\gls{ca}-Zertifikat für eine \gls{https}-Verbindung gefunden werden kann. Der Betreiber einer, über \gls{https} erreichbaren, \gls{website} kann
dafür den \gls{rsa}-Schlüssel seines \gls{x509}-Zertifikats in ein \gls{openpgp}-Zertifikat importieren. Für die ID dieses Zertifikats wird der
\gls{uri} des \gls{https}-Webservers verwendet. Das Zertifikat wird dann auf einen öffentlichen \gls{openpgp}-Schlüssel-Server geladen und kann dann später
automatisch vom Monkeysphere-AddOn gefunden werden, wenn keine gültige \gls{cot} von \gls{firefox} gefunden wird. Für das veröffentlichte
\gls{openpgp}-Zertifikat können die Benutzer dann dem \gls{wot} entsprechend ihr Vertrauen festlegen, welches dann von Monkeysphere auch innerhalb von
\gls{firefox} angezeigt wird.

Enigmail deckt den wichtigsten Verbreitungsraum für \gls{openpgp}, die Kommunikation über E-Mail, ab, indem es gleich wie die beiden zuvor genannten
Erweiterungen eine Schnittstelle zu \gls{gpg} anbietet, jedoch nicht für \gls{firefox} sondern nur für \gls{thunderbird}. Es eignet sich zum Signieren,
Verifizieren, Ver- und Entschlüsseln von E-Mails, sowie der Verwaltung der benutzten \gls{openpgp}-Zertifikate über eine grafische Oberfläche.

Für alle drei Erweiterungen gilt, dass sie eine Infrastruktur aus öffentlichen Schlüsselservern nutzen, um die Verteilung und das Auffinden von
\gls{openpgp}-Zertifikaten zu ermöglichen.

\subsection{Anwendung}
FireGPG und Monkeysphere benutzen beide eine, am System des Benutzers installierte, Instanz von \gls{gpg} und rufen das darin enthaltene, ausführbare Programm
\texttt{gpg} mit Parametern auf. Es wird keine Programm-Bibliothek zur Verarbeitung von \gls{openpgp}-Funktionen direkt in \gls{firefox} geladen. Dies ist dadurch
begründet, dass das Programm \texttt{gpg} seine Speicherbereiche, die auch sensitive Informationen wie Passwörter und private Schlüssel enthalten, besonders
gegen externe Zugriffe schützt \cite{pgp}. Alle Informationen, die der Browser für seine \gls{openpgp}-Funktionalität benötigt, laufen somit über Aufrufe von
\texttt{gpg}.

Für ein eigenes \gls{firefox-addon} für \gls{xml-dsig} wäre somit eine Anlehnung an diese Anbindung von \gls{gpg} von Vorteil da sie bereits in zwei Projekten
erprobt wurde und es auch den Intentionen der \gls{gpg}-Entwicklern entspricht \cite{pgp}.

\section{\glsentrytext{x509}}
\index{X.509v3}
\label{sec:Signaturverfahren:x509}
Die Unterstützung für die kryptografisch abgesicherte Netzwerkverbindungen mittels \gls{https} ist in jedem \gls{webbrowser} integriert. Dazu gehört auch die
Unterstützung für das Verarbeiten von \gls{x509}-Zertifikaten. Abhängig vom \gls{webbrowser} werden die Zertifikate der Root-\glspl{ca} intern oder vom
Betriebssystem verwaltet.

Für \gls{firefox} existiert das AddOn Key Manager Tool, das \gls{x509}-Informationen außerhalb des Kontextes von \gls{https} verwendet. Es bietet Funktionen zur
Erstellung, Signierung und Verwaltung von \gls{x509}-Zertifikaten, ähnlich der Arbeitsweise einer \gls{ca}. 

Das \gls{firefox-addon} Key  Manager Tool verwendet die in \gls{firefox} integrierten Programmierschnittstellen für \gls{x509} die unter dem Namen \gls{psm}
und \gls{nss} verfügbar sind \cite{key-manager-tool}. 

\section{Evaluierung der Verfahren}
Die Verwendung eines \gls{wot} zur Verteilung der Schlüssel-Informationen und der Vertrauensbeziehungen zwischen ihnen hätte gegenüber einem \gls{ht} mit
\gls{x509} den Vorteil, dass die Erstellung und Veröffentlichung eines \gls{openpgp}-Zertifikats einfach und ohne die Inanspruchnahme einer \gls{ca}
durchgeführt werden kann. Dies könnte die Akzeptanz in einer heterogenen Benutzergruppe steigern, da bei \gls{x509} in der Regel Gebühren von den \glspl{ca}
eingehoben werden und auch individuelle Vertrauensstellungen nicht möglich sind. Gegen den Einsatz eines \gls{wot} spricht die geringe Akzeptanz eines solchen
Ansatzes im betrieblichen Umfeld, was auf das Fehlen einer zentralen Autorität zurückzuführen ist \cite{krypto-pki-internet}.

Beobachtungen der im Internet eingesetzten \gls{x509}-Zertifikate für \gls{https} haben gezeigt, dass auch der Ansatz der zentralen Autoritäten wie \glspl{ca}
nicht vor Fehlern und unsachgemäßen Daten in den Zertifikaten schützt. Von 33916 Zertifikaten, die nach den strikt formulierten \gls{x509-ev} Richtlinien
\cite{ev-ssl} signiert wurden, wiesen 38 Mängel auf, wie zum Beispiel schwache Schlüssel, \gls{ip}-Adressen aus dem Bereich von RFC-1918 oder "`localhost"' als
Wert für den \gls{dns}-Hostnamen des \gls{https}-Webservers \cite{ssliverse:27c3}.

\begin{table}
    \centering
    \begin{tabularx}{\textwidth}{ l X X }
        Anforderung  & \gls{openpgp} & \gls{x509} \\
        \hline
        \hline
        Verfügbarkeit auf mehr als einer Plattform & \CheckedBox & \CheckedBox \\
        \hline
        Programmierschnittstelle in \gls{firefox} & \Square & \CheckedBox \\
        \hline
        Dezentrale Verwaltung der Zertifikate& \CheckedBox & \Square \\
        \hline
        Mehrere Schlüssel je Zertifikat& \CheckedBox & \Square \\
        \hline
        Fehlertolerante Vertrauensbeziehungen& \CheckedBox & \Square \\
        \hline
        Institutionalisierte Prüfung der Zertifikatsdaten& \Square & \CheckedBox \\
        \hline
        Zurückziehen des Zertifikats durch den Inhaber& \CheckedBox & \Square \\
        \hline
    \end{tabularx}
    \caption{Gegenüberstellung der Signaturverfahren nach \cite{pki-comparison}}
    \label{tab:gegenüberstellung}
\end{table}

Um eine möglichst großflächige Verbreitung eines potentiellen \glspl{firefox-addon} bei Internet-Nutzer zu erreichen, sollten vorrangig Merkmale bei der Auswahl
eines Verfahrens zur Zertifikatsverteilungs und Signaturerstellung gewählt werden, die die sozialen Strukturen und Beziehungen dieses Personenkreises
widerspiegelt. Die sogenannten sozialen Netzwerke des Web 2.0 basieren hauptsächlich auf der Verknüpfung von Personen mit Inhalten, dem Finden von Pfaden zu Personen über
bereits vorhandene Kontakte und der Interaktion mit Inhalten, die von anderen Benutzern einer \gls{website} generiert wurden.

Neben technischen Anforderungen werden deshalb mehrheitlich soziale Aspekte in der Gegenüberstellung der beiden Verfahren \gls{openpgp} und \gls{x509} in
\fref{tab:gegenüberstellung} bewertet. \gls{x509} bietet in einem \gls{webbrowser} den großen Vorteil, dass die nötigen kryptografischen Methoden bereits
integriert sind und über Programmierschnittstellen benutzt werden können. Die institutionalisierte Prüfung der Zertifikatsdaten wäre ein Vorteil von \gls{x509},
der jedoch zu einem zentralen Schwachpunkt werden kann, wenn die Richtlinien der Prüfung von einzelnen \glspl{ca} nicht eingehalten werden. 
Weiters muss im Fall eines \glspl{webbrowser} dem Hersteller vertraut werden, dass dieser einen dokumentierten Prozess zur Auswahl der inkludierten
\gls{x509}-Zertifikate eingesetzt hat, da eine nachträgliche Prüfung durch den Benutzer nicht vorgeschrieben werden kann.
Daraus lässt sich auch das Problem ableiten, dass unterschiedliche \gls{webbrowser} nicht der selben Menge von \glspl{ca} vertrauen.

Die Abbildung der sozialen Strukturen in einem, von privaten Anwendern dominierten, Internet ist mit \gls{openpgp} besser möglich, da das \gls{wot} in
seiner Struktur mit der der sozialen Netzwerke identisch ist. Ähnlich wie in einem sozialen Netzwerk des Web 2.0 beginnt jeder Benutzer im \gls{wot} ohne
vorgegebene Vertrauensbeziehungen. Diese werden erst im Lauf der Zeit vom Benutzer aktiv gesammelt \cite{pki:perlman}. Dies würde die Probleme, die \gls{x509}
durch inkorrekt arbeitende, vorinstallierte \glspl{ca} hat, an die Benutzer verlagern, die für das von ihnen vergebene Vertrauen selbst verantwortlich sind.
Damit steigen für die Benutzer jedoch auch die Anforderungen dahingehend, dass ein grundlegendes Verständnis für die Arbeitsweise eines \gls{wot} nötig wird.

Für den Einsatz in einem unternehmerischen Umfeld, in welchem hauptsächlich hierarchische Strukturen vorzufinden sind, wäre \gls{x509} besser geeignet,
diese Strukturen auch in einem \gls{ht} abzubilden. Auch kann in einem solchen Umfeld die Erzeugung und Verteilung von Zertifikaten durch Prozesse geregelt und,
von geschultem Personal, durchgeführt werden. Somit wären auch für \gls{x509} die Anforderungen beim Einstieg für die Benutzer deutlich niedriger.

Ein Unterschied zwischen \gls{openpgp} und \gls{x509} besteht in den Auswirkungen eines kompromitierten Zertifikats. Wird bei \gls{x509} eine \gls{ca} aus
dem \gls{cot} kompromitiert, wirkt sich das auf alle Zertifikate, die sich unterhalb dieser \gls{ca} befinden, aus. Dies kann dazu führen, dass ein gesamter Ast
eines solchen \gls{ht}-Baumes neu signiert werden muss. Bei \gls{openpgp} kann bei Bekanntwerden der Kompromitierung eines Zertifikats das Vertrauen nachträglich
herabgestuft werden\cite{pgp}. Dadurch wäre \gls{openpgp} toleranter gegen eine Kompromitierung einzelner Zertifikate und den damit verbundenen
Vertrauensbeziehungen. Das Problem bei \gls{openpgp} liegt hier viel mehr in der Benachrichtung über die Kompromitierung an jene Benutzer, die dem Zertifikat
vertrauen sowie der Fähigkeit der Inhaber von Zertifikaten, ihr Vertrauen  in die von ihnen signierten Zertifikate einzuschätzen. Mit \gls{openpgp} besteht die
Gefahr, dass ein einzelner, fahrlässiger Inhaber eines Zertifikats in der \gls{cot} diese schwächt \cite{pki:perlman}.

Ähnlich verhält sich das auch für das Zurückziehen eines Zertifikats. Bei \gls{x509} kann das Zertifikat nur über einen, von der \gls{ca} vorgegebenen, Prozess
bei der \gls{ca} selbst zurückgezogen und somit ungültig gemacht werden. Wird ein Zertifikat von der \gls{ca} zurückgezogen, so setzt sie es auf eine
\gls{crl}. Mit dieser können nun Benutzer prüfen, ob ein Zertifikat gültig ist, indem sie die \gls{crl} von der \gls{ca} abrufen und überprüfen, ob das
Zertifikat darin aufgelistet wird. Die Verwendung von \glspl{crl} bringt jedoch weitere Probleme mit sich wie zum Beispiel hohe Netzwerk-Last auf den Servern
der \glspl{ca} sowie die Verzögerung durch die auf Intervallen basierende Aktualisierung der \gls{crl} durch die \gls{ca} \cite{10.1109/MC.2002.1023787}. 

Im Gegensatz dazu ist bei \gls{openpgp} nur der Inhaber des Zertifikats nötig um es zurückzuziehen. Da es bei \gls{openpgp} für diese Tätigkeit genau einen
Prozess gibt, könnte dieser, zur Erleichterung der Bedienung, auch innerhalb des \glspl{firefox-addon} automatisiert werden. Für \gls{x509} existieren zwar auch
Automatismen für das Zurückziehen von Zertifikaten, diese variieren jedoch zwischen den einzelnen \glspl{ca}.

<commit_msg>Fix citation.<commit_after>% vim: set tw=160:

\glsreset{wot}
\glsreset{cot}
\glsreset{ht}

\chapter{Anwendbare Signaturverfahren}
\index{Signaturverfahren}
\label{chap:Signaturverfahren}
Wie in \fref{sec:GrundlagenDefinitionen:DigitaleSignaturen:Verfahren} bereits vorgestellt, bieten sich \gls{openpgp} und \gls{x509} für den Einsatz in
\gls{xml-dsig} an. Um solche Signaturen in \gls{xhtml} für den Besucher einer \gls{website} nutzbar zu machen, müssen die dafür nötigen Komponenten in einem
\gls{webbrowser} vorhanden sein oder über eine Erweiterung nachrüstbar sein. Dazu wird der \gls{webbrowser}
\index{Firefox}Firefox\footnote{\url{http://www.mozilla.com/firefox/}} wegen seiner umfangreichen Möglichkeiten zur Erweiterung mittels sogenannter
\glspl{firefox-addon} auf die Integration von \gls{openpgp} und \gls{x509} untersucht. Auch die zunehmende Verbreitung von \gls{firefox} im europäischen Raum
von über $50\%$ \cite{firefox-verbreitung} positioniert diesen \gls{webbrowser} als bevorzugtes Ziel für eine solche Erweiterung.

\section{\glsentrytext{openpgp}}
\index{OpenPGP}
\label{sec:Signaturverfahren:OpenPGP}
Da \gls{openpgp} seine Verbreitung hauptsächlich im E-Mail-Verkehr \cite{Garfinkel:2003:EEC:1123196.1123244} und zur kryptografischen Absicherung von Code und
Programmen erfährt, existiert in \gls{firefox} so wie auch in anderen, mit Stand Januar 2011, gängigen \gls{webbrowser}n keine direkte Schnittstelle zu einer
\gls{openpgp}-Implementierung.

\subsection{Verbreitung}
\gls{firefox} bietet in seinem Auslieferungszustand keine Unterstützung für \gls{openpgp}. Mit Stand Januar 2011 existieren jedoch zwei \glspl{firefox-addon},
\index{Firefox!FireGPG}FireGPG\footnote{\url{http://getfiregpg.org/s/home}} und
\index{Firefox!Monkeysphere}Monkeysphere\footnote{\url{http://web.monkeysphere.info/}}, welche \gls{gpg}, eine \gls{foss}-Implementierung von \gls{openpgp},
nutzen, um digitale Signaturen in \gls{firefox} zu verwenden. Im weiteren Sinne ist auch die Erweiterung Enigmail ein \gls{firefox-addon}, da es die selbe
Erweiterungsschnittstelle nutzt, es jedoch eine \gls{openpgp}-Erweiterung für das E-Mail-Programm \gls{thunderbird} ist.

FireGPG bietet eine einfache Erkennung und Prüfung von \gls{openpgp}-Signaturen, die als normaler Text im \gls{ascii} Armor Format \cite{openpgp:ietf} in
\glspl{webseite} eingebettet sind. Diese Textstellen werden dann in der Darstellung im Browser farblich hervorgehoben und Informationen zur Gültigkeit der
Signatur werden, beim Überfahren des Textes mit der Maus, angezeigt.

Monkeysphere dehnt, als \gls{firefox-addon}, das in \fref{sec:GrundlagenDefinitionen:Vertrauen:WOT} beschriebene \gls{wot} auf die \gls{pki}-Infrastruktur von
\gls{https} aus. Dabei bietet es sich als Option zur Validierung der Gültigkeit von Schlüsseln an, wenn keine \gls{cot} bis zu einem in \gls{firefox}
hinterlegten Root-\gls{ca}-Zertifikat für eine \gls{https}-Verbindung gefunden werden kann. Der Betreiber einer, über \gls{https} erreichbaren, \gls{website} kann
dafür den \gls{rsa}-Schlüssel seines \gls{x509}-Zertifikats in ein \gls{openpgp}-Zertifikat importieren. Für die ID dieses Zertifikats wird der
\gls{uri} des \gls{https}-Webservers verwendet. Das Zertifikat wird dann auf einen öffentlichen \gls{openpgp}-Schlüssel-Server geladen und kann dann später
automatisch vom Monkeysphere-AddOn gefunden werden, wenn keine gültige \gls{cot} von \gls{firefox} gefunden wird. Für das veröffentlichte
\gls{openpgp}-Zertifikat können die Benutzer dann dem \gls{wot} entsprechend ihr Vertrauen festlegen, welches dann von Monkeysphere auch innerhalb von
\gls{firefox} angezeigt wird.

Enigmail deckt den wichtigsten Verbreitungsraum für \gls{openpgp}, die Kommunikation über E-Mail, ab, indem es gleich wie die beiden zuvor genannten
Erweiterungen eine Schnittstelle zu \gls{gpg} anbietet, jedoch nicht für \gls{firefox} sondern nur für \gls{thunderbird}. Es eignet sich zum Signieren,
Verifizieren, Ver- und Entschlüsseln von E-Mails, sowie der Verwaltung der benutzten \gls{openpgp}-Zertifikate über eine grafische Oberfläche.

Für alle drei Erweiterungen gilt, dass sie eine Infrastruktur aus öffentlichen Schlüsselservern nutzen, um die Verteilung und das Auffinden von
\gls{openpgp}-Zertifikaten zu ermöglichen.

\subsection{Anwendung}
FireGPG und Monkeysphere benutzen beide eine, am System des Benutzers installierte, Instanz von \gls{gpg} und rufen das darin enthaltene, ausführbare Programm
\texttt{gpg} mit Parametern auf. Es wird keine Programm-Bibliothek zur Verarbeitung von \gls{openpgp}-Funktionen direkt in \gls{firefox} geladen. Dies ist dadurch
begründet, dass das Programm \texttt{gpg} seine Speicherbereiche, die auch sensitive Informationen wie Passwörter und private Schlüssel enthalten, besonders
gegen externe Zugriffe schützt \cite{pgp}. Alle Informationen, die der Browser für seine \gls{openpgp}-Funktionalität benötigt, laufen somit über Aufrufe von
\texttt{gpg}.

Für ein eigenes \gls{firefox-addon} für \gls{xml-dsig} wäre somit eine Anlehnung an diese Anbindung von \gls{gpg} von Vorteil da sie bereits in zwei Projekten
erprobt wurde und es auch den Intentionen der \gls{gpg}-Entwicklern entspricht \cite{pgp}.

\section{\glsentrytext{x509}}
\index{X.509v3}
\label{sec:Signaturverfahren:x509}
Die Unterstützung für die kryptografisch abgesicherte Netzwerkverbindungen mittels \gls{https} ist in jedem \gls{webbrowser} integriert. Dazu gehört auch die
Unterstützung für das Verarbeiten von \gls{x509}-Zertifikaten. Abhängig vom \gls{webbrowser} werden die Zertifikate der Root-\glspl{ca} intern oder vom
Betriebssystem verwaltet.

Für \gls{firefox} existiert das AddOn Key Manager Tool, das \gls{x509}-Informationen außerhalb des Kontextes von \gls{https} verwendet. Es bietet Funktionen zur
Erstellung, Signierung und Verwaltung von \gls{x509}-Zertifikaten, ähnlich der Arbeitsweise einer \gls{ca}. 

Das \gls{firefox-addon} Key  Manager Tool verwendet die in \gls{firefox} integrierten Programmierschnittstellen für \gls{x509} die unter dem Namen \gls{psm}
und \gls{nss} verfügbar sind \cite{key-manager-tool}. 

\section{Evaluierung der Verfahren}
Die Verwendung eines \gls{wot} zur Verteilung der Schlüssel-Informationen und der Vertrauensbeziehungen zwischen ihnen hätte gegenüber einem \gls{ht} mit
\gls{x509} den Vorteil, dass die Erstellung und Veröffentlichung eines \gls{openpgp}-Zertifikats einfach und ohne die Inanspruchnahme einer \gls{ca}
durchgeführt werden kann. Dies könnte die Akzeptanz in einer heterogenen Benutzergruppe steigern, da bei \gls{x509} in der Regel Gebühren von den \glspl{ca}
eingehoben werden und auch individuelle Vertrauensstellungen nicht möglich sind. Gegen den Einsatz eines \gls{wot} spricht die geringe Akzeptanz eines solchen
Ansatzes im betrieblichen Umfeld, was auf das Fehlen einer zentralen Autorität zurückzuführen ist \cite{krypto-pki-internet}.

Beobachtungen der im Internet eingesetzten \gls{x509}-Zertifikate für \gls{https} haben gezeigt, dass auch der Ansatz der zentralen Autoritäten wie \glspl{ca}
nicht vor Fehlern und unsachgemäßen Daten in den Zertifikaten schützt. Von 33916 Zertifikaten, die nach den strikt formulierten \gls{x509-ev} Richtlinien
\cite{ev-ssl} signiert wurden, wiesen 38 Mängel auf, wie zum Beispiel schwache Schlüssel, \gls{ip}-Adressen aus dem Bereich von RFC-1918 oder "`localhost"' als
Wert für den \gls{dns}-Hostnamen des \gls{https}-Webservers \cite{ssliverse:27c3}.

\begin{table}
    \centering
    \begin{tabularx}{\textwidth}{ l X X }
        Anforderung  & \gls{openpgp} & \gls{x509} \\
        \hline
        \hline
        Verfügbarkeit auf mehr als einer Plattform & \CheckedBox & \CheckedBox \\
        \hline
        Programmierschnittstelle in \gls{firefox} & \Square & \CheckedBox \\
        \hline
        Dezentrale Verwaltung der Zertifikate& \CheckedBox & \Square \\
        \hline
        Mehrere Schlüssel je Zertifikat& \CheckedBox & \Square \\
        \hline
        Fehlertolerante Vertrauensbeziehungen& \CheckedBox & \Square \\
        \hline
        Institutionalisierte Prüfung der Zertifikatsdaten& \Square & \CheckedBox \\
        \hline
        Zurückziehen des Zertifikats durch den Inhaber& \CheckedBox & \Square \\
        \hline
    \end{tabularx}
    \caption{Gegenüberstellung der Signaturverfahren nach \cite{pki-comparison}}
    \label{tab:gegenüberstellung}
\end{table}

Um eine möglichst großflächige Verbreitung eines potentiellen \glspl{firefox-addon} bei Internet-Nutzer zu erreichen, sollten vorrangig Merkmale bei der Auswahl
eines Verfahrens zur Zertifikatsverteilungs und Signaturerstellung gewählt werden, die die sozialen Strukturen und Beziehungen dieses Personenkreises
widerspiegelt. Die sogenannten sozialen Netzwerke des Web 2.0 basieren hauptsächlich auf der Verknüpfung von Personen mit Inhalten, dem Finden von Pfaden zu Personen über
bereits vorhandene Kontakte und der Interaktion mit Inhalten, die von anderen Benutzern einer \gls{website} generiert wurden.

Neben technischen Anforderungen werden deshalb mehrheitlich soziale Aspekte in der Gegenüberstellung der beiden Verfahren \gls{openpgp} und \gls{x509} in
\fref{tab:gegenüberstellung} bewertet. \gls{x509} bietet in einem \gls{webbrowser} den großen Vorteil, dass die nötigen kryptografischen Methoden bereits
integriert sind und über Programmierschnittstellen benutzt werden können. Die institutionalisierte Prüfung der Zertifikatsdaten wäre ein Vorteil von \gls{x509},
der jedoch zu einem zentralen Schwachpunkt werden kann, wenn die Richtlinien der Prüfung von einzelnen \glspl{ca} nicht eingehalten werden. 
Weiters muss im Fall eines \glspl{webbrowser} dem Hersteller vertraut werden, dass dieser einen dokumentierten Prozess zur Auswahl der inkludierten
\gls{x509}-Zertifikate eingesetzt hat, da eine nachträgliche Prüfung durch den Benutzer nicht vorgeschrieben werden kann.
Daraus lässt sich auch das Problem ableiten, dass unterschiedliche \gls{webbrowser} nicht der selben Menge von \glspl{ca} vertrauen.

Die Abbildung der sozialen Strukturen in einem, von privaten Anwendern dominierten, Internet ist mit \gls{openpgp} besser möglich, da das \gls{wot} in
seiner Struktur mit der der sozialen Netzwerke identisch ist. Ähnlich wie in einem sozialen Netzwerk des Web 2.0 beginnt jeder Benutzer im \gls{wot} ohne
vorgegebene Vertrauensbeziehungen. Diese werden erst im Lauf der Zeit vom Benutzer aktiv gesammelt \cite{pki:perlman}. Dies würde die Probleme, die \gls{x509}
durch inkorrekt arbeitende, vorinstallierte \glspl{ca} hat, an die Benutzer verlagern, die für das von ihnen vergebene Vertrauen selbst verantwortlich sind.
Damit steigen für die Benutzer jedoch auch die Anforderungen dahingehend, dass ein grundlegendes Verständnis für die Arbeitsweise eines \gls{wot} nötig wird.

Für den Einsatz in einem unternehmerischen Umfeld, in welchem hauptsächlich hierarchische Strukturen vorzufinden sind, wäre \gls{x509} besser geeignet,
diese Strukturen auch in einem \gls{ht} abzubilden. Auch kann in einem solchen Umfeld die Erzeugung und Verteilung von Zertifikaten durch Prozesse geregelt und,
von geschultem Personal, durchgeführt werden. Somit wären auch für \gls{x509} die Anforderungen beim Einstieg für die Benutzer deutlich niedriger.

Ein Unterschied zwischen \gls{openpgp} und \gls{x509} besteht in den Auswirkungen eines kompromitierten Zertifikats. Wird bei \gls{x509} eine \gls{ca} aus
dem \gls{cot} kompromitiert, wirkt sich das auf alle Zertifikate, die sich unterhalb dieser \gls{ca} befinden, aus. Dies kann dazu führen, dass ein gesamter Ast
eines solchen \gls{ht}-Baumes neu signiert werden muss. Bei \gls{openpgp} kann bei Bekanntwerden der Kompromitierung eines Zertifikats das Vertrauen nachträglich
herabgestuft werden\cite{pgp}. Dadurch wäre \gls{openpgp} toleranter gegen eine Kompromitierung einzelner Zertifikate und den damit verbundenen
Vertrauensbeziehungen. Das Problem bei \gls{openpgp} liegt hier viel mehr in der Benachrichtung über die Kompromitierung an jene Benutzer, die dem Zertifikat
vertrauen sowie der Fähigkeit der Inhaber von Zertifikaten, ihr Vertrauen  in die von ihnen signierten Zertifikate einzuschätzen. Mit \gls{openpgp} besteht die
Gefahr, dass ein einzelner, fahrlässiger Inhaber eines Zertifikats in der \gls{cot} diese schwächt \cite{pki:perlman}.

Ähnlich verhält sich das auch für das Zurückziehen eines Zertifikats. Bei \gls{x509} kann das Zertifikat nur über einen, von der \gls{ca} vorgegebenen, Prozess
bei der \gls{ca} selbst zurückgezogen und somit ungültig gemacht werden. Wird ein Zertifikat von der \gls{ca} zurückgezogen, so setzt sie es auf eine
\gls{crl}. Mit dieser können nun Benutzer prüfen, ob ein Zertifikat gültig ist, indem sie die \gls{crl} von der \gls{ca} abrufen und überprüfen, ob das
Zertifikat darin aufgelistet wird. Die Verwendung von \glspl{crl} bringt jedoch weitere Probleme mit sich wie zum Beispiel hohe Netzwerk-Last auf den Servern
der \glspl{ca} sowie die Verzögerung durch die auf Intervallen basierende Aktualisierung der \gls{crl} durch die \gls{ca} \cite{10.1109/MC.2002.1023787}. 

Im Gegensatz dazu ist bei \gls{openpgp} nur der Inhaber des Zertifikats nötig um es zurückzuziehen. Da es bei \gls{openpgp} für diese Tätigkeit genau einen
Prozess gibt, könnte dieser, zur Erleichterung der Bedienung, auch innerhalb des \glspl{firefox-addon} automatisiert werden. Für \gls{x509} existieren zwar auch
Automatismen für das Zurückziehen von Zertifikaten, diese variieren jedoch zwischen den einzelnen \glspl{ca}.


{'fraction_non_alphanumeric': 0.06927064050351722, 'fraction_numerical': 0.01066271751203258, 'mean_word_length': 5.2992070895522385, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2992162', 'n_tokens_mistral': 9558, 'n_tokens_neox': 9852, 'n_words': 3091}