reduce reduce reduce. The text on PKIs was way too long .
authorAaron Kaplan <aaron@lo-res.org>
Thu, 14 Nov 2013 17:07:45 +0000 (18:07 +0100)
committerAaron Kaplan <aaron@lo-res.org>
Thu, 14 Nov 2013 17:07:45 +0000 (18:07 +0100)
We need to focus on actual practical settings. copy & pasteable stuff.
Also make this clear in the abstract.

src/PKIs.tex
src/abstract.tex

index 6edbe4c..f69bed4 100644 (file)
@@ -1,62 +1,16 @@
 \section{Public Key Infrastructures}
 
-Public-Key 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 scale-out 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.
+Public-Key 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 generally-trusted mediator solves the trust-scaling problem at the
+cost of introducing an actor that magically is more trustworthy.
 
-The first approach to help the scale-out 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 cross-verification 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 scale-out 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
-meta-information 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 generally-trusted 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, ...}
 
 
 
index 35bc73a..2f8f08a 100644 (file)
@@ -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 \&
+paste-able 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.