From: Aaron Kaplan
Date: Thu, 14 Nov 2013 17:07:45 +0000 (+0100)
Subject: reduce reduce reduce. The text on PKIs was way too long .
XGitUrl: https://git.bettercrypto.org/achmaster.git/commitdiff_plain/368855bb2f0427d82096291cd0ccc81fee7f694b
reduce reduce reduce. The text on PKIs was way too long .
We need to focus on actual practical settings. copy & pasteable stuff.
Also make this clear in the abstract.

diff git a/src/PKIs.tex b/src/PKIs.tex
index 6edbe4c..f69bed4 100644
 a/src/PKIs.tex
+++ b/src/PKIs.tex
@@ 1,62 +1,16 @@
\section{Public Key Infrastructures}
PublicKey Infrastructures aim to provide a way to simplify the
verification of a certificate's trustworthiness. In general, if the
authenticity of a given public key is to be established by a user (say,
Alice), it is necessary to contact the owner (say, Bob) of the public key
directly and compare the public key's fingerprint. This, obviously, is
cumbersome and does not scale.

In practice, there are two approaches to address this scaleout problem.
Both solutions are based on the assumption that Alice can delegate the
verification of the authenticity of a given public key to another party
(say, Trent). This requires that Alice have a certain amount of faith in
Trent. In particular, she must trust him to do a proper job when verifying
authenticity.
+PublicKey Infrastructures aim to provide a way to simplify the verification of
+a certificate's trustworthiness. For this, certificate authorities (CAs) are
+used for createing a signature chain down to the server (or client). Accepting
+a CA as a generallytrusted mediator solves the trustscaling problem at the
+cost of introducing an actor that magically is more trustworthy.
The first approach to help the scaleout problem puts a little more work on
Alice's and Bob's shoulders. The idea is that every user can act as a
trusted third party to verify the authenticity of other users' public keys.
If a number of other users have verified and signed off on the authenticity
of Bob's public key, then Alice can be somewhat confident in the
authenticity as well. Obviously, the more users have verified and signed
any given public key, the more trustworthy that key becomes; this concept
is called a ``Web of Trust.'' On the other hand, this means that in order
for a public key to become reasonably trustworthy in practice, it is
necessary that a fairly large number of users need to verify its
authenticity. This is where the additional work for Alice and Bob comes
in: For the entire scheme to work, it is necessary that a sufficiently
large number of users generally participate in crossverification and
signing. The number of signatures needed to obtain a given level of
confidence in the authenticity of a public key also depends on how good a
job participating users on average do when verifying keys. Thus, the more
knowledgeable, experienced and accurate users are expected to be in terms
of key verification, the fewer signatures are necessary. In particular,
there is no practical way to set common standards for verification.
+This section deals with settings related to trusting CAs.
+However, our main recommendations for PKIs is: if you are able to run your own PKI and disable any other CA, do so.
+This is mostly possible in any machine 2 machine communication systems or potentially within a corporate enviroment for specific applications.
The other approach to solve the problem of scaleout introduces a
structured and organized set of trusted third parties called
``Certification Authorities'' (CAs). CAs offer verification services to
all users, adhering to a published set of standard rules and procedures.
Of course, each CA is free to specify its own standard operating
procedures, which generally are referred to as ``Certification Practice
Statement''\footnote{\url{http://en.wikipedia.org/wiki/Certification_Practice_Statement}}
(CPS) and denotes the rules that the CA adheres to when verifying the
authenticity of public keys. When the authenticity of a public key has
been established in accordance to the CA's CPS, it may issue a certificate,
which is essentially the public key, usually combined with some
metainformation about the owner of the key, and the CA's cryptographic
signature by which the CA assures the accuracy of the information contained
in the certificate. Therefore, if Alice is sufficiently convinced that a
given CA is doing a proper job of verification in accordance with its
published CPS and the CPS are sufficiently strict so that Alice feels
comfortable with the level of assurance they provide, then Alice may
consider all public keys that that CA has issued certificates for as
authentic. This reduces the work that Alice has to do to verify $n$~public
keys from $n$~verifications (one per other user) to just one verification
(that to verify the authenticity of the CA's public key). Accepting a CA
as a generallytrusted mediator therefore solves the scaling problem at the
cost of introducing an actor that magically is more trustworthy.
+\todo{write the actual recommendations: certificate pinning, TLSA, ...}
diff git a/src/abstract.tex b/src/abstract.tex
index 35bc73a..2f8f08a 100644
 a/src/abstract.tex
+++ b/src/abstract.tex
@@ 19,4 +19,9 @@ information systems: getting the crypto settings right. Other attacks, as the
above mentioned, require different protection schemes which are not covered in
this whitepaper.

+This whitepaper is \textbf{not} an introduction to cryptography, on how to use
+PGP nor SSL. Its focus is merely to give current best practices with
+configuring complex cipher suites and related parameters in a \textbf{copy \&
+pasteable manner}. For background information on cryptography,
+cryptoanalysis, PGP and SSL we would like to refer the reader to the list of
+books at the end of this document.