Added PKI stuff, added Tobias Dussa to the list of authors.
authorTobias Dussa <tobias.dussa@kit.edu>
Wed, 13 Nov 2013 00:25:46 +0000 (01:25 +0100)
committerTobias Dussa <tobias.dussa@kit.edu>
Wed, 13 Nov 2013 09:48:11 +0000 (10:48 +0100)
src/PKIs.tex
src/applied-crypto-hardening.tex

index 48517bd..6edbe4c 100644 (file)
@@ -1 +1,65 @@
 \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.
+
+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.
+
+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.
+
+
+
+%``Certification
+%Policy''\footnote{\url{http://en.wikipedia.org/wiki/Certificate_Policy}}
+%(CA)
index 9d118a8..a8185aa 100644 (file)
@@ -92,7 +92,9 @@
 \preauthor{\begin{flushleft}
                                        \large \lineskip 0.5em \usefont{OT1}{phv}{b}{sl} \color{DarkRed}}
 
-\author{ L. Aaron Kaplan, Manuel Koschuch, Adi Kriegisch, Ramin Sabet, Aaron Zauner, Pepi Zawodsky}
+                                       \author{Tobias Dussa, L. Aaron
+                                       Kaplan, Manuel Koschuch, Adi
+                               Kriegisch, Ramin Sabet, Aaron Zauner, Pepi Zawodsky}
 %\institute{
 %FH Campus Wien
 %\and
 %}
 
 \postauthor{\footnotesize \usefont{OT1}{phv}{m}{sl} \color{Black} 
-\\ \vskip 0.5em  ( CERT.at, FH Campus Wien, VRVis, A-Trust, azet.org, maclemon.at)
+\\ \vskip 0.5em  (KIT-CERT, CERT.at, FH Campus Wien, VRVis, A-Trust, azet.org, maclemon.at)
                                        \par\end{flushleft}\HorRule}
 
 \date{2013-11-04}