diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex
index 405f413..783df74 100644
--- a/MA-Inhalt.tex
+++ b/MA-Inhalt.tex
@@ -359,6 +359,14 @@ Aufgrund des Installationsprozess und den in EasyRSA Version~3.0.5 enthaltenen V
 Bevor mit EasyRSA~3.0.5 eine CA aufgebaut werden kann, muss die Konfiguration von EasyRSA an die Bedürfnisse der CA angepasst werden.
 Die anzupassenden Parameter werden in diesem Abschnitt beschrieben und die dazu getroffenen Entscheidungen erläutert.
 
+\paragraph{Vorgaben}
+Die folgenden Vorgaben für die CA wurden in Absprache mit dem Auftraggeber und Erstprüfer dieser Arbeit festgelegt:
+Das Wurzelzertifikat soll für 20 Jahre gültig sein.
+Ausgestellte Clientzertifikate sollen für Beschäftigte 5 Jahre lang gültig sein, für Studierende 2 Jahre lang.
+Ausgestellte Serverzertifikate sollen 5 Jahre lang gültig sein.
+In den ausgestellten Benutzerzertifikaten soll der volle Name und die Hochschul-E-Mail-Adresse des Benutzers abgelegt werden.
+Die Serverzertifikate sollen den voll qualifizierten Domainnamen (FQDN) enthalten.
+
 \paragraph{Auswahl des Kryptosystems}
 EasyRSA unterstützt sowohl RSA-Schlüsselpaare als auch Schlüsselpaare auf Basis der \textit{Elliptische-Kurven-Kryptografie} (EKK).
 Somit stehen RSA und EKK als Kryptosystems zur Auswahl, mit denen die CA aufgebaut werden kann.
@@ -382,41 +390,17 @@ Auch auf die im Vergleich zu RSA effizienteren Verfahren in EKK zum Signieren un
 
 Da das BSI in seinen technischen Richtlinien keine Bedenken gegen den Einsatz von RSA über 2023 hinaus äußert\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}, steht dem Einsatz von RSA für den Aufbau der CA nichts im Weg.
 
-\paragraph{Wahl der RSA-Schlüssellänge}
+\paragraph{Festlegen der Schlüssellänge}
+Im nächsten Schritt wird die Länge der RSA-Schlüssel festgelegt, auf Basis derer die CA Zertifikate ausstellen soll.
+OpenVPN empfiehlt RSA mit Schlüsseln länger als 2048 Bit: \enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}\cite[][Option \texttt{--tls-cert-profile}]{man:openvpn}
+Das BSI empfiehlt den Betrieb mit Schlüsseln länger als 3000 Bit über das Jahr 2023 hinaus\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
 
+\paragraph{Eingebettete Informationen}
+Voller Name und die Hochschul-E-Mail-Adresse von Benutzern soll enthalten sein. Das geht nur mit dem vollen Schema.
+Der volle Name wird als \texttt{Common Name} abgelegt, die E-Mail-Adresse in \texttt{Email Address}.
 
-\begin{itemize}
-\item OpenVPN empfiehlt RSA mit Schlüsseln länger als 2048 Bit: \enquote{OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply.}\cite[][Option \texttt{--tls-cert-profile}]{man:openvpn}
-\item Das BSI empfiehlt den Betrieb mit Schlüsseln länger als 3000 Bit über das Jahr 2023 hinaus\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
-\end{itemize}
-
-\paragraph{asd}
-Organisatorische Frage: Zertifikate nur mit CN oder volles Schema?
-Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas. Es gibt keine nennenswerten Vorteile oder Nachteile. Mehr Informationen können helfen, wenn man einen Eimer voller Zertifikate findet.
-
-Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen? 
-\begin{itemize}
-\item Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
-\item Voller Name: Konflikte selten aber möglich, personenbezogene Daten
-\item E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
-\item Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
-\item Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
-\end{itemize}
-Benutzername wäre eine eindeutige Angabe, ist garantiert eindeutig.
-Gleichzeitig kann man argumentieren, dass diese häufig pseudonym sind und die Zuordnung von Benutzername zu Person nicht immer trivial ist.
-Datenschutzrechtlich sollte das gerade so okay sein.
-
-Veto von Herrn Wohlfeil: Voller Name und Hochschul-E-Mail-Adresse werden in die Zertifikate geschrieben.
-
-Laufzeit für Serverzertifikate? 5 Jahre
-Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
-Studenten bekommen 2 Jahre (4 Semester)
-Mitarbeiter bekommen 5 Jahre
-
-Laufzeit der CA - sinnvolle Werte?
-20 Jahre. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.
-Von der CA ausgestellte Zertifikate können nicht länger gültig sein als das Wurzelzertifikat der CA selbst.
-
+\paragraph{Gültigkeitsdauer der CRL}
+Hat eher symbolischen Gehalt, da sie eh automatisiert aktualisiert werden sollte.
 Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (Cronjob oder so)