Remove an extra space char in PKIs.tex
[ach-master.git] / src / theory / PKIs.tex
index b8ad25d..abd5fb8 100644 (file)
@@ -5,17 +5,17 @@ Public-Key Infrastructures try to solve the problem of verifying
 whether a public key belongs to a given entity, so as to prevent Man
 In The Middle attacks.
 
 whether a public key belongs to a given entity, so as to prevent Man
 In The Middle attacks.
 
-There are two approaches to achieve that: {\it Certificate Authorities}
-and the {\it Web of Trust}.
+There are two approaches to achieve that: \emph{Certificate Authorities}
+and the \emph{Web of Trust}.
 
 Certificate Authorities (CAs) sign end-entities' certificates, thereby
 associating some kind of identity (e.g. a domain name or an email
 address) with a public key. CAs are used with TLS and S/MIME
 certificates, and the CA system has a big list of possible and real
 
 Certificate Authorities (CAs) sign end-entities' certificates, thereby
 associating some kind of identity (e.g. a domain name or an email
 address) with a public key. CAs are used with TLS and S/MIME
 certificates, and the CA system has a big list of possible and real
-problems which are summarized in \cite{https13}.
+problems which are summarized in section \ref{sec:hardeningpki} and~\cite{https13}.
 
 The Web of Trust is a decentralized system where people sign each
 
 The Web of Trust is a decentralized system where people sign each
-others keys, so that there is a high chance that there is a ``trust
+other's keys, so that there is a high chance that there is a ``trust
 path'' from one key to another. This is used with PGP keys, and while
 it avoids most of the problems of the CA system, it is more
 cumbersome.
 path'' from one key to another. This is used with PGP keys, and while
 it avoids most of the problems of the CA system, it is more
 cumbersome.
@@ -48,6 +48,11 @@ for issuing certificates.  Finally, in the research and education field, a
 number of CAs exist that are generally well-known and well-accepted within
 the higher-education community.
 
 number of CAs exist that are generally well-known and well-accepted within
 the higher-education community.
 
+A large number of CAs is pre-installed in client software's or
+operating system's``trust stores''; depending on your application, you
+have to select your CA according to this, or have a mechanism to
+distribute the chosen CA's root certificate to the clients.
+
 When requesting a certificate from a CA, it is vital that you generate the
 key pair yourself.  In particular, the private key should never be known to
 the CA.  If a CA offers to generate the key pair for you, you should not
 When requesting a certificate from a CA, it is vital that you generate the
 key pair yourself.  In particular, the private key should never be known to
 the CA.  If a CA offers to generate the key pair for you, you should not
@@ -58,8 +63,8 @@ tools.  On Unix-like systems, it is likely that the OpenSSL suite is available
 to you.  In this case, you can generate a private key and a corresponding
 certificate request as follows:
 
 to you.  In this case, you can generate a private key and a corresponding
 certificate request as follows:
 
-\begin{lstlisting}[breaklines]
-% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize>
+\begin{lstlisting}
+% openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
 Country Name (2 letter code) [AU]:DE
 State or Province Name (full name) [Some-State]:Bavaria
 Locality Name (eg, city) []:Munich
 Country Name (2 letter code) [AU]:DE
 State or Province Name (full name) [Some-State]:Bavaria
 Locality Name (eg, city) []:Munich
@@ -91,7 +96,7 @@ following commands on a Debian system:
 % sudo ./CA.pl -newca
 \end{lstlisting}
 
 % sudo ./CA.pl -newca
 \end{lstlisting}
 
-Answer the questions according to your setup. Now that you have configured your basic settings and 
+Answer the questions according to your setup. Now that you have configured your basic settings and
 issued a new root certificate, you can issue new certificates as follows:
 
 \begin{lstlisting}
 issued a new root certificate, you can issue new certificates as follows:
 
 \begin{lstlisting}
@@ -99,6 +104,10 @@ issued a new root certificate, you can issue new certificates as follows:
 % sudo ./CA.pl -newreq
 \end{lstlisting}
 
 % sudo ./CA.pl -newreq
 \end{lstlisting}
 
+Alternatively, software such as TinyCA~\cite{Wikipedia:TinyCA} that
+acts as a ``wrapper'' around OpenSSL and tries to make life easier is
+available.
+
 \subsubsection{Creating a Self-Signed Certificate}
 \label{sec:pki:selfsignedcert}
 If the desired trust level is very high and the number of systems involved
 \subsubsection{Creating a Self-Signed Certificate}
 \label{sec:pki:selfsignedcert}
 If the desired trust level is very high and the number of systems involved
@@ -108,12 +117,17 @@ CA at all, but is signed by the entity that it is issued to.  Thus, the
 organizational overhead of running a CA is eliminated at the expense of
 having to establish all trust relationships between entities manually.
 
 organizational overhead of running a CA is eliminated at the expense of
 having to establish all trust relationships between entities manually.
 
-With OpenSSL, a self-signed certificate may be created with this command:
+With OpenSSL, you can self-sign a previously created certificate with this command:
 
 \begin{lstlisting}
 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
 \end{lstlisting}
 
 
 \begin{lstlisting}
 % openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
 \end{lstlisting}
 
+You can also create a self-signed certificate in just one command:
+\begin{lstlisting}
+openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
+\end{lstlisting}
+
 The resulting certificate will by default not be trusted by anyone at all,
 so in order to be useful, the certificate will have to be made known a
 priori to all parties that may encounter it.
 The resulting certificate will by default not be trusted by anyone at all,
 so in order to be useful, the certificate will have to be made known a
 priori to all parties that may encounter it.
@@ -135,7 +149,7 @@ Therefore several security enhancements were introduced by different
 organizations and vendors~\cite{tschofenig-webpki}. Currently two
 methods are used, DANE~\cite{rfc6698} and Certificate
 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
 organizations and vendors~\cite{tschofenig-webpki}. Currently two
 methods are used, DANE~\cite{rfc6698} and Certificate
 Pinning~\cite{draft-ietf-websec-key-pinning}. Google recently proposed
-a new system to detect malicious CAs and certificates  called Certificate 
+a new system to detect malicious CAs and certificates called Certificate
 Transparency~\cite{certtransparency}.
 
 % \subsubsection{DANE}
 Transparency~\cite{certtransparency}.
 
 % \subsubsection{DANE}
@@ -158,7 +172,7 @@ Transparency~\cite{certtransparency}.
 % A good background on PKIs can be found in
 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
 % A good background on PKIs can be found in
 % \footnote{\url{https://developer.mozilla.org/en/docs/Introduction_to_Public-Key_Cryptography}}
 % \footnote{\url{http://cacr.uwaterloo.ca/hac/about/chap8.pdf}}
-% \footnote{\url{http://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
+% \footnote{\url{https://www.verisign.com.au/repository/tutorial/cryptography/intro1.shtml}}
 % .
 
 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
 % .
 
 % \todo{ts: Background and Configuration (EMET) of Certificate Pinning,
@@ -169,4 +183,4 @@ Transparency~\cite{certtransparency}.
 %   plugins: CipherFox, Conspiracy, Perspectives.}
 
 
 %   plugins: CipherFox, Conspiracy, Perspectives.}
 
 
-% ``Certificate Policy''\cite{Wikipedia:Certificate_Policy} (CA)
+% ``Certificate Policy''~\cite{Wikipedia:Certificate_Policy} (CA)