[Secure Coding] master: Packaging: Add section on delayed certificate generation (dc0ff1a)

[fweimer at fedoraproject.org]

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git

On branch  : master

>---------------------------------------------------------------

commit dc0ff1a16e89bdd14cf0f157bacc40a15367702f
Author: Florian Weimer <fweimer at redhat.com>
Date:   Fri Jun 6 13:26:37 2014 +0200

    Packaging: Add section on delayed certificate generation


>---------------------------------------------------------------

 defensive-coding/en-US/Tasks-Packaging.xml |   37 +++++++++++++++++++++++++++-
 1 files changed, 36 insertions(+), 1 deletions(-)

diff --git a/defensive-coding/en-US/Tasks-Packaging.xml b/defensive-coding/en-US/Tasks-Packaging.xml
index 95bfbc6..07ee072 100644
--- a/defensive-coding/en-US/Tasks-Packaging.xml
+++ b/defensive-coding/en-US/Tasks-Packaging.xml
@@ -20,7 +20,8 @@
       such use, generating the key pair at package installation time
       when preparing system images for use in the cluster is
       reasonable.  For other use cases, it is necessary to generate
-      the key pair before the service is started for the first time.
+      the key pair before the service is started for the first time,
+      see <xref linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service"/>.
     </para>
     <important>
       <para>
@@ -128,4 +129,38 @@ fi
       <application>chmod</application> invocation.
     </para>
   </section>
+  <section id="sect-Defensive_Coding-Tasks-Packaging-Certificates-Service">
+    <title>Generating X.509 self-signed certificates before service
+    start</title>
+    <para>
+      An alternative way to automatically provide an X.509 key pair is
+      to create it just before the service is started for the first
+      time.  This ensures that installation images which are created
+      from installed RPM packages receive different key material.
+      Creating the key pair at package installation time (see <xref
+      linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>)
+      would put the key into the image, which may or may not make
+      sense.
+    </para>
+    <important>
+      <para>
+	The caveats about the way the key is generated in <xref
+	linkend="sect-Defensive_Coding-Tasks-Packaging-Certificates"/>
+	apply to this procedure as well.
+    </para>
+    </important>
+    <para>
+      Generating key material before service start may happen very
+      early during boot, when the kernel randomness pool has not yet
+      been initialized.  Currently, the only way to check for the
+      initialization is to look for the kernel message
+      <literal>random: nonblocking pool is initialized</literal>.  In
+      theory, it is also possible to read from
+      <filename>/dev/random</filename> while generating the key
+      material (instead of <filename>/dev/urandom</filename>), but
+      this can block not just during the boot process, but also much
+      later at run time, and generally results in a poor user
+      experience.
+    </para>
+  </section>
 </chapter>