X-Git-Url: https://git.bettercrypto.org/ach-master.git/blobdiff_plain/c0e6903f7c0330044fe82987bcd7cde3dc5c1c4e..5a3ae028c621c4143287bfe6e463da00661e8e1f:/src/theory/PKIs.tex/ach-master.git/blobdiff_plain/c0e6903f7c0330044fe82987bcd7cde3dc5c1c4e..5a3ae028c621c4143287bfe6e463da00661e8e1f:/src/theory/PKIs.tex

diff --git a/src/theory/PKIs.tex b/src/theory/PKIs.tex
index bc963c5..87ab65c 100644
--- a/src/theory/PKIs.tex
+++ b/src/theory/PKIs.tex
@@ -1,15 +1,33 @@
 \section{Public Key Infrastructures}
 \label{section:PKIs}
 
-Public-Key Infrastructures aim to provide a way to simplify the verification of
-a certificate's trustworthiness.  For this, certificate authorities (CAs) are
-used to create a signature chain from the root CA down to the server (or client).
-Accepting a CA as a generally-trusted mediator solves the trust-scaling problem
-at the cost of introducing an actor that magically is more trustworthy.
-
-The first part of this section addresses how to obtain a certificate.  The
-second part offers recommendations on how to improve the security of your
-PKI.
+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.
+
+There are two approaches to achieve that: {\it Certificate Authorities}
+and the {\it 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
+problems which are summarized in section \ref{sec:hardeningpki} and
+\cite{https13}.
+
+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
+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.
+
+As alternatives to these public systems, there are two more choices:
+running a private CA, and manually trusting keys (as it is used with
+SSH keys or manually trusted keys in web browsers).
+
+The first part of this section addresses how to obtain a certificate
+in the CA system. The second part offers recommendations on how to
+improve the security of your PKI.
 
 \subsection{Certificate Authorities}
 \label{sec:cas}
@@ -31,6 +49,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.
 
+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
@@ -82,6 +105,10 @@ issued a new root certificate, you can issue new certificates as follows:
 % 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