working on Elio's edits and adding the new db info

3 files changed, 931 insertions, 375 deletions

diff --git a/certutil.xml b/certutil.xml
index d0e04e9..9c00cb9 100644
--- a/certutil.xml
+++ b/certutil.xml
@@ -1,18 +1,20 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!--
 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
--->
 <refentry>
 
   <refentryinfo>
-    <date>14 August, 2008</date>
-<!-- this should be one word -->
-	<refentrytitle>certutil</refentrytitle>
-<!-- end  -->
-    <manvolnum>1</manvolnum>
+    <date>august 2010</date>
+    <title>NSS Security Tools</title>
+    <productname>nss-tools</productname>
+    <productnumber>8</productnumber>
   </refentryinfo>
 
+  <refmeta>
+    <refentrytitle>CERTUTIL</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
   <refnamediv>
     <refname>certutil</refname>
     <refpurpose>Manage keys and certificate in the the NSS database.</refpurpose>
@@ -152,12 +154,12 @@ Use the -a argument to specify ASCII output.</para></listitem>
 
       <varlistentry>
         <term>--merge</term>
-        <listitem><para>Merge a source database into the target database.</para></listitem>
+        <listitem><para>Merge a source database into the target database. This is used to merge legacy NSS databases (<filename>cert8.db</filename> and <filename>key3.db</filename>) into the newer SQLite databases (<filename>cert9.db</filename> and <filename>key4.db</filename>).</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term>--upgrade-merge</term>
-        <listitem><para>Upgrade an old database and merge it into a new database.</para></listitem>
+        <listitem><para>Upgrade an old database and merge it into a new database. This is used to migrate legacy NSS databases (<filename>cert8.db</filename> and <filename>key3.db</filename>) into the newer SQLite databases (<filename>cert9.db</filename> and <filename>key4.db</filename>).</para></listitem>
       </varlistentry>
 	</variablelist>
 
@@ -186,13 +188,9 @@ If this option is not used, the validity check defaults to the current system ti
       </varlistentry>
 
       <varlistentry>
-        <term>-d directory</term>
-        <listitem><para>Specify the database directory containing the certificate and key database files. 
-<!--
-        On Unix the Certificate Database Tool defaults to $HOME/.netscape (that is, ~/.netscape). 
-        On Windows NT the default is the current directory.
--->
- The cert8.db and key3.db database files must reside in the same directory. </para></listitem>
+        <term>-d [sql:]directory</term>
+        <listitem><para>Specify the database directory containing the certificate and key database files.</para>
+	<para><command>certutil</command> supports two types of databases: the legacy security databases (<filename>cert8.db</filename>, <filename>key3.db</filename>, and <filename>secmod.db</filename>) and new SQLite databases (<filename>cert9.db</filename>, <filename>key4.db</filename>, and <filename>pkcs11.txt</filename>). If the prefix <command>sql:</command> is not used, then the tool assumes that the given databases are in the old format.</para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -290,27 +288,43 @@ Changing the names of the certificate and key databases is not recommended.</par
         <listitem><para>Specify the trust attributes to modify in an existing certificate or to apply to a certificate when creating it or adding it to a database. There are three available trust categories for each certificate, expressed in the order <emphasis>SSL, email, object signing</emphasis> for each trust setting. In each category position, use none, any, or all
 of the attribute codes: 
 	</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* <command>p</command> - Valid peer
+		<command>p</command> - Valid peer
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>P</command> - Trusted peer (implies p)
+		<command>P</command> - Trusted peer (implies p)
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>c</command> - Valid CA
+		<command>c</command> - Valid CA
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>T</command> - Trusted CA to issue client certificates (implies c)
+		<command>T</command> - Trusted CA to issue client certificates (implies c)
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>C</command> - Trusted CA to issue server certificates (SSL only) (implies c)
+		<command>C</command> - Trusted CA to issue server certificates (SSL only) (implies c)
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>u</command> - Certificate can be used for authentication or signing
+		<command>u</command> - Certificate can be used for authentication or signing
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <command>w</command> - Send warning (use with other attributes to include a warning when the certificate is used in that context)
+		<command>w</command> - Send warning (use with other attributes to include a warning when the certificate is used in that context)
 	</para>
+	</listitem>
+	</itemizedlist>
 	<para>
 		The attribute codes for the categories are separated by commas, and the entire set of attributes enclosed by quotation marks. For example:
 	</para>
@@ -322,12 +336,26 @@ of the attribute codes:
       <varlistentry>
         <term>-u certusage</term>
         <listitem><para>Specify a usage context to apply when validating a certificate with the -V option.</para><para>The contexts are the following:</para>
-<para>* <command>C</command> (as an SSL client)</para>
-<para>* <command>V</command> (as an SSL server)</para>
-<para>* <command>S</command> (as an email signer)</para>
-<para>* <command>R</command> (as an email recipient)</para>
-<para>* <command>O</command> (as an OCSP status responder)</para>
-<para>* <command>J</command> (as an object signer)</para></listitem>
+	<itemizedlist>
+	<listitem>
+<para><command>C</command> (as an SSL client)</para>
+	</listitem>
+	<listitem>
+<para><command>V</command> (as an SSL server)</para>
+	</listitem>
+	<listitem>
+<para><command>S</command> (as an email signer)</para>
+	</listitem>
+	<listitem>
+<para><command>R</command> (as an email recipient)</para>
+	</listitem>
+	<listitem>
+<para><command>O</command> (as an OCSP status responder)</para>
+	</listitem>
+	<listitem>
+<para><command>J</command> (as an object signer)</para>
+	</listitem>
+	</itemizedlist></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -379,30 +407,48 @@ the default and create a validity period of one month.</para></listitem>
       <varlistentry>
         <term>-1 | --keyUsage keyword,keyword</term>
         <listitem><para>Set a Netscape Certificate Type Extension in the certificate. There are several available keywords:</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* digital signature
+		digital signature
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* nonRepudiation
+		nonRepudiation
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* keyEncipherment
+		keyEncipherment
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* dataEncipherment
+		dataEncipherment
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* keyAgreement
+		keyAgreement
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* certSigning
+		certSigning
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* crlSigning
+		crlSigning
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* critical
+		critical
 	</para>
+	</listitem>
+	</itemizedlist>
 </listitem>
       </varlistentry>
 
@@ -427,60 +473,97 @@ the default and create a validity period of one month.</para></listitem>
       <varlistentry>
         <term>-5 | --nsCertType keyword,keyword</term>
         <listitem><para>Add a Netscape certificate type extension to a certificate that is being created or added to the database. There are several available keywords:</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* sslClient
+		sslClient
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* sslServer
+		sslServer
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* smime
+		smime
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* objectSigning
+		objectSigning
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* sslCA
+		sslCA
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* smimeCA
+		smimeCA
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* objectSigningCA
+		objectSigningCA
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* critical
+		critical
 	</para>
+	</listitem>
+	</itemizedlist>
+
 <para>X.509 certificate extensions are described in RFC 5280.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term>-6 | --extKeyUsage keyword,keyword</term>
         <listitem><para>Add an extended key usage extension to a certificate that is being created or added to the database. Several keywords are available:</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* serverAuth
+		serverAuth
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* clientAuth
+		clientAuth
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* codeSigning
+		codeSigning
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* emailProtection
+		emailProtection
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* timeStamp
+		timeStamp
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* ocspResponder
+		ocspResponder
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* stepUp
+		stepUp
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* critical
+		critical
 	</para>
+	</listitem>
+	</itemizedlist>
 <para>X.509 certificate extensions are described in RFC 5280.</para></listitem>
       </varlistentry>
 
@@ -566,47 +649,65 @@ the default and create a validity period of one month.</para></listitem>
 	<para>
 		Certificates, keys, and security modules related to managing certificates are stored in three related databases:
 	</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* cert8.db
+		cert8.db or cert9.db
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* key3.db
+		key3.db or key4.db
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* secmod.db
+		secmod.db or pkcs11.txt
 	</para>
+	</listitem>
+	</itemizedlist>
 	<para>
 		These databases must be created before certificates or keys can be generated.
 	</para>
-<programlisting>certutil -N -d &lt;directory></programlisting>
+<programlisting>certutil -N -d [sql:]directory</programlisting>
 
 	<para><command>Creating a Certificate Request</command></para>
 	<para>
 		A certificate request contains most or all of the information that is used to generate the final certificate. This request is submitted separately to a certificate authority and is then approved by some mechanism (automatically or by human review). Once the request is approved, then the certificate is generated.
 	</para>
-<programlisting language="Bash">$ certutil -R -k key-type-or-id [-q pqgfile|curve-name] -g key-size -s subject [-h tokenname] -d certdir [-p phone] [-o output-file] [-a]</programlisting>
+<programlisting>$ certutil -R -k key-type-or-id [-q pqgfile|curve-name] -g key-size -s subject [-h tokenname] -d [sql:]directory [-p phone] [-o output-file] [-a]</programlisting>
 	<para>
 		The <option>-R</option> command options requires four arguments:
 	</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* <option>-k</option> to specify either the key type to generate or, when renewing a certificate, the existing key pair to use
+		<option>-k</option> to specify either the key type to generate or, when renewing a certificate, the existing key pair to use
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <option>-g</option> to set the keysize of the key to generate
+		<option>-g</option> to set the keysize of the key to generate
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <option>-s</option> to set the subject name of the certificate
+		<option>-s</option> to set the subject name of the certificate
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* <option>-d</option> to give the security database directory
+		<option>-d</option> to give the security database directory
 	</para>
+	</listitem>
+	</itemizedlist>
 	<para>
 		The new certificate request can be output in ASCII format (<option>-a</option>) or can be written to a specified file (<option>-o</option>).
 	</para>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -R -k ec -q nistb409 -g 512 -s "CN=John Smith,O=Example Corp,L=Mountain View,ST=California,C=US" -d . -p 650-555-0123 -a -o cert.
+<programlisting>$ certutil -R -k ec -q nistb409 -g 512 -s "CN=John Smith,O=Example Corp,L=Mountain View,ST=California,C=US" -d sql:/home/my/sharednssdb -p 650-555-0123 -a -o cert.cer
 
 Generating key.  This may take a few moments...
 
@@ -633,45 +734,45 @@ qmtyQNjIi1F8c1Z+TL4uFYlMg8z6LG/J/u1E5t1QqB5e9Q4+BhRbrQjRR1JZx3tB
 	<para>
 		A valid certificate must be issued by a trusted CA. This can be done by specifying a CA certificate (<option>-c</option>) that is stored in the certificate database. If a CA key pair is not available, you can create a self-signed certificate using the <option>-x</option> argument with the <option>-S</option> command option.
 	</para>
-<programlisting language="Bash">$ certutil -S -k rsa|dsa|ec -n certname -s subject [-c issuer |-x] -t trustargs -d directory [-m serial-number] [-v valid-months] [-w offset-months] [-p phone] [-1] [-2] [-3] [-4] [-5 keyword] [-6 keyword] [-7 emailAddress] [-8 dns-names] [--extAIA] [--extSIA] [--extCP] [--extPM] [--extPC] [--extIA] [--extSKID]</programlisting>
+<programlisting>$ certutil -S -k rsa|dsa|ec -n certname -s subject [-c issuer |-x] -t trustargs -d [sql:]directory [-m serial-number] [-v valid-months] [-w offset-months] [-p phone] [-1] [-2] [-3] [-4] [-5 keyword] [-6 keyword] [-7 emailAddress] [-8 dns-names] [--extAIA] [--extSIA] [--extCP] [--extPM] [--extPC] [--extIA] [--extSKID]</programlisting>
 	<para>
 		The series of numbers and <option>--ext*</option> options set certificate extensions that can be added to the certificate when it is generated by the CA.
 	</para>
 	<para>
 		For example, this creates a self-signed certificate:
 	</para>
-<programlisting language="Bash">$ certutil -S -s "CN=Example CA" -n my-ca-cert -x -t "C,C,C" -1 -2 -5 -m 3650</programlisting>
+<programlisting>$ certutil -S -s "CN=Example CA" -n my-ca-cert -x -t "C,C,C" -1 -2 -5 -m 3650</programlisting>
 	<para>
 		From there, new certificates can reference the self-signed certificate:
 	</para>
-<programlisting language="Bash">$ certutil -S -s "CN=My Server Cert" -n my-server-cert -c "my-ca-cert" -t "u,u,u" -1 -5 -6 -8 -m 730</programlisting>
+<programlisting>$ certutil -S -s "CN=My Server Cert" -n my-server-cert -c "my-ca-cert" -t "u,u,u" -1 -5 -6 -8 -m 730</programlisting>
 
 	<para><command>Generating a Certificate from a Certificate Request</command></para>
 	<para>
 		When a certificate request is created, a certificate can be generated by using the request and then referencing a certificate authority signing certificate (the <emphasis>issuer</emphasis> specified in the <option>-c</option> argument). The issuing certificate must be in the <filename>cert8.db</filename> database in the specified directory.
 	</para>
-<programlisting language="Bash">certutil -C -c issuer -i cert-request-file -o output-file [-m serial-number] [-v valid-months] [-w offset-months] -d certdir [-1] [-2] [-3] [-4] [-5 keyword] [-6 keyword] [-7 emailAddress] [-8 dns-names]</programlisting>
+<programlisting>certutil -C -c issuer -i cert-request-file -o output-file [-m serial-number] [-v valid-months] [-w offset-months] -d [sql:]directory [-1] [-2] [-3] [-4] [-5 keyword] [-6 keyword] [-7 emailAddress] [-8 dns-names]</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -C -c "my-ca-cert" -i /home/certs/cert.req -o cert.cer -m 010 -v 12 -w 1 -d . -1 nonRepudiation,dataEncipherment -5 sslClient -6 clientAuth -7 jsmith@example.com</programlisting>
+<programlisting>$ certutil -C -c "my-ca-cert" -i /home/certs/cert.req -o cert.cer -m 010 -v 12 -w 1 -d sql:/home/my/sharednssdb -1 nonRepudiation,dataEncipherment -5 sslClient -6 clientAuth -7 jsmith@example.com</programlisting>
 
 
 	<para><command>Generating Key Pairs</command></para>
 	<para>
 		Key pairs are generated automatically with a certificate request or certificate, but they can also be generated independently using the <option>-G</option> command option. 
 	</para>
-<programlisting language="Bash">certutil -G -d directory | -h tokenname -k key-type -g key-size [-y exponent-value] -q pqgfile|curve-name</programlisting>
+<programlisting>certutil -G -d [sql:]directory | -h tokenname -k key-type -g key-size [-y exponent-value] -q pqgfile|curve-name</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -G -h lunasa -k ec -g 256 -q sect193r2</programlisting>
+<programlisting>$ certutil -G -h lunasa -k ec -g 256 -q sect193r2</programlisting>
 
 	<para><command>Listing Certificates</command></para>
 	<para>
 		The <option>-L</option> command option lists all of the certificates listed in the <filename>cert8.db</filename> database. The path to the directory (<option>-d</option>) is required.
 	</para>
-<programlisting language="Bash">$ certutil -L -d .
+<programlisting>$ certutil -L -d sql:/home/my/sharednssdb
 
 Certificate Nickname                                         Trust Attributes
                                                              SSL,S/MIME,JAR/XPI
@@ -683,7 +784,7 @@ Certificate Authority - Example Domain                       CT,C,C</programlist
 	<para>
 		Using additional arguments with <option>-L</option> can return and print the information for a single, specific certificate. For example, the <option>-n</option> argument passes the certificate name, while the <option>-a</option> argument prints the certificate in ASCII format:
 	</para>
-<programlisting language="Bash">$ certutil -L -d . -a -n "Certificate Authority - Example Domain"
+<programlisting>$ certutil -L -d sql:/home/my/sharednssdb -a -n "Certificate Authority - Example Domain"
 
 -----BEGIN CERTIFICATE-----
 MIIDmTCCAoGgAwIBAgIBATANBgkqhkiG9w0BAQUFADA5MRcwFQYDVQQKEw5FeGFt
@@ -715,7 +816,7 @@ nI7q5n1USM3eWQlVXw==
 	<para>
 		To list all keys in the database, use the <option>-K</option> command option and the (required) <option>-d</option> argument to give the path to the directory.
 	</para>
-<programlisting language="Bash">$ certutil -K -d .
+<programlisting>$ certutil -K -d sql:/home/my/sharednssdb
 certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services                  "
 &lt; 0> rsa      455a6673bde9375c2887ec8bf8016b3f9f35861d   Thawte Freemail Member's Thawte Consulting (Pty) Ltd. ID
 &lt; 1> rsa      40defeeb522ade11090eacebaaf1196a172127df   Example Domain Administrator Cert
@@ -723,21 +824,29 @@ certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and
 	<para>
 		There are ways to narrow the keys listed in the search results:
 	</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* To return a specific key, use the <option>-n</option> <emphasis>name</emphasis> argument with the name of the key.
+		To return a specific key, use the <option>-n</option> <emphasis>name</emphasis> argument with the name of the key.
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* If there are multiple security devices loaded, then the <option>-h</option> <emphasis>tokenname</emphasis> argument can search a specific token or all tokens.
+		If there are multiple security devices loaded, then the <option>-h</option> <emphasis>tokenname</emphasis> argument can search a specific token or all tokens.
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* If there are multiple key types available, then the <option>-k</option> <emphasis>key-type</emphasis> argument can search a specific type of key, like RSA, DSA, or ECC. 
+		If there are multiple key types available, then the <option>-k</option> <emphasis>key-type</emphasis> argument can search a specific type of key, like RSA, DSA, or ECC. 
 	</para>
+	</listitem>
+	</itemizedlist>
 
 	<para><command>Listing Security Modules</command></para>
 	<para>
 		The devices that can be used to store certificates -- both internal databases and external devices like smart cards -- are recognized and used by loading security modules. The <option>-U</option> command option lists all of the security modules listed in the <filename>secmod.db</filename> database. The path to the directory (<option>-d</option>) is required.
 	</para>
-<programlisting language="Bash">$ certutil -U -d .
+<programlisting>$ certutil -U -d sql:/home/my/sharednssdb
 
     slot: NSS User Private Key and Certificate Services                  
    token: NSS Certificate DB
@@ -749,51 +858,51 @@ certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and
 	<para>
 		Existing certificates or certificate requests can be added manually to the <filename>cert8.db</filename> database, even if they were generated elsewhere. This uses the <option>-A</option> command option.
 	</para>
-<programlisting language="Bash">certutil -A -n certname -t trustargs -d certdir [-a] [-i input-file]</programlisting>
+<programlisting>certutil -A -n certname -t trustargs -d [sql:]directory [-a] [-i input-file]</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -A -n "CN=My SSL Certificate" -t "u,u,u" -d . -i /home/example-certs/cert.cer</programlisting>
+<programlisting>$ certutil -A -n "CN=My SSL Certificate" -t "u,u,u" -d sql:/home/my/sharednssdb -i /home/example-certs/cert.cer</programlisting>
 	<para>
 		A related command option, <option>-E</option>, is used specifically to add email certificates to the certificate database. The <option>-E</option> command has the same arguments as the <option>-A</option> command. The trust arguments for certificates have the format <emphasis>SSL,S/MIME,Code-signing</emphasis>, so the middle trust settings relate most to email certificates (though the others can be set). For example:
 	</para>
-<programlisting language="Bash">$ certutil -E -n "CN=John Smith Email Cert" -t ",Pu," -d . -i /home/example-certs/email.cer</programlisting>
+<programlisting>$ certutil -E -n "CN=John Smith Email Cert" -t ",Pu," -d sql:/home/my/sharednssdb -i /home/example-certs/email.cer</programlisting>
 
 	<para><command>Deleting Certificates to the Database</command></para>
 	<para>
 		Certificates can be deleted from a database using the <option>-D</option> option. The only required options are to give the security database directory and to identify the certificate nickname.
 	</para>
-<programlisting language="Bash">certutil -D -d directory -n "nickname"</programlisting>
+<programlisting>certutil -D -d [sql:]directory -n "nickname"</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -D -d . -n "my-ssl-cert"</programlisting>
+<programlisting>$ certutil -D -d sql:/home/my/sharednssdb -n "my-ssl-cert"</programlisting>
 
 	<para><command>Validating Certificates</command></para>
 	<para>
 		A certificate contains an expiration date in itself, and expired certificates are easily rejected. However, certificates can also be revoked before they hit their expiration date. Checking whether a certificate has been revoked requires validating the certificate. Validation can also be used to ensure that the certificate is only used for the purposes it was initially issued for. Validation is carried out by the <option>-V</option> command option.
 	</para>
-<programlisting language="Bash">certutil -V -n certificate-name [-b time] [-e] [-u cert-usage] -d directory</programlisting>
+<programlisting>certutil -V -n certificate-name [-b time] [-e] [-u cert-usage] -d [sql:]directory</programlisting>
 	<para>
 		For example, to validate an email certificate:
 	</para>
-<programlisting language="Bash">$ certutil -V -n "John Smith's Email Cert" -e -u S,R -d .</programlisting>
+<programlisting>$ certutil -V -n "John Smith's Email Cert" -e -u S,R -d sql:/home/my/sharednssdb</programlisting>
 
 	<para><command>Modifying Certificate Trust Settings</command></para>
 	<para>
 		The trust settings (which relate to the operations that a certificate is allowed to be used for) can be changed after a certificate is created or added to the database. This is especially useful for CA certificates, but it can be performed for any type of certificate.
 	</para>
-<programlisting language="Bash">certutil -M -n certificate-name -t trust-args -d directory</programlisting>
+<programlisting>certutil -M -n certificate-name -t trust-args -d [sql:]directory</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil -M -n "My CA Certificate" -d . -t "CTu,CTu,CTu"</programlisting>
+<programlisting>$ certutil -M -n "My CA Certificate" -d sql:/home/my/sharednssdb -t "CTu,CTu,CTu"</programlisting>
 
 	<para><command>Printing the Certificate Chain</command></para>
 	<para>
 		Certificates can be issued in <emphasis>chains</emphasis> because every certificate authority itself has a certificate; when a CA issues a certificate, it essentially stamps that certificate with its own fingerprint. The <option>-O</option> prints the full chain of a certificate, going from the initial CA (the root CA) through ever intermediary CA to the actual certificate. For example, for an email certificate with two CAs in the chain:
 	</para>
-<programlisting language="Bash">$ certutil -d . -O -n "jsmith@example.com"
+<programlisting>$ certutil -d sql:/home/my/sharednssdb -O -n "jsmith@example.com"
 "Builtin Object Token:Thawte Personal Freemail CA" [E=personal-freemail@thawte.com,CN=Thawte Personal Freemail CA,OU=Certification Services Division,O=Thawte Consulting,L=Cape Town,ST=Western Cape,C=ZA]
 
   "Thawte Personal Freemail Issuing CA - Thawte Consulting" [CN=Thawte Personal Freemail Issuing CA,O=Thawte Consulting (Pty) Ltd.,C=ZA]
@@ -804,68 +913,164 @@ certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and
 	<para>
 		The device which stores certificates -- both external hardware devices and internal software databases -- can be blanked and reused. This operation is performed on the device which stores the data, not directly on the security databases, so the location must be referenced through the token name (<option>-h</option>) as well as any directory path. If there is no external token used, the default value is internal.
 	</para>
-<programlisting language="Bash">certutil -T -d directory -h token-name -0 security-officer-password</programlisting>
+<programlisting>certutil -T -d [sql:]directory -h token-name -0 security-officer-password</programlisting>
 	<para>
 		Many networks have dedicated personnel who handle changes to security tokens (the security officer). This person must supply the password to access the specified token. For example:
 	</para>
-<programlisting language="Bash">$ certutil -T -d . -h nethsm -0 secret</programlisting>
+<programlisting>$ certutil -T -d sql:/home/my/sharednssdb -h nethsm -0 secret</programlisting>
 
 	<para><command>Upgrading or Merging the Security Databases</command></para>
 	<para>
-		Some networks or applications may be using older versions of the certificate database, like a <filename>cert7.db</filename> database, or there may be multiple certificate databases in use. Databases can be upgraded to a new version using the <option>--upgrade-merge</option> command option or merged with other databases using the <option>---merge</option> command.
+		Many networks or applications may be using older BerkeleyDB versions of the certificate database (<filename>cert8.db</filename>). Databases can be upgraded to the new SQLite version of the database (<filename>cert9.db</filename>) using the <option>--upgrade-merge</option> command option or existing databases can be merged with the new <filename>cert9.db</filename> databases using the <option>---merge</option> command.
 	</para>
 	<para>
 		The <option>--upgrade-merge</option> command must give information about the original database and then use the standard arguments (like <option>-d</option>) to give the information about the new databases. The command also requires information that the tool uses for the process to upgrade and write over the original database.
 	</para>
-<programlisting language="Bash">certutil --upgrade-merge -d directory [-P dbprefix] --source-dir directory --source-prefix dbprefix --upgrade-id id --upgrade-token-name name [-@ password-file]</programlisting>
+<programlisting>certutil --upgrade-merge -d [sql:]directory [-P dbprefix] --source-dir directory --source-prefix dbprefix --upgrade-id id --upgrade-token-name name [-@ password-file]</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil --upgrade-merge -d . --source-dir /opt/my-app/alias/ --source-prefix serverapp- --upgrade-id 1 --upgrade-token-name internal</programlisting>
+<programlisting>$ certutil --upgrade-merge -d sql:/home/my/sharednssdb --source-dir /opt/my-app/alias/ --source-prefix serverapp- --upgrade-id 1 --upgrade-token-name internal</programlisting>
 	<para>
 		The <option>--merge</option> command only requires information about the location of the original database; since it doesn't change the format of the database, it can write over information without performing interim step.
 	</para>
-<programlisting language="Bash">certutil --merge -d directory [-P dbprefix] --source-dir directory --source-prefix dbprefix [-@ password-file]</programlisting>
+<programlisting>certutil --merge -d [sql:]directory [-P dbprefix] --source-dir directory --source-prefix dbprefix [-@ password-file]</programlisting>
 	<para>
 		For example:
 	</para>
-<programlisting language="Bash">$ certutil --merge -d . --source-dir /opt/my-app/alias/ --source-prefix serverapp-</programlisting>
+<programlisting>$ certutil --merge -d sql:/home/my/sharednssdb --source-dir /opt/my-app/alias/ --source-prefix serverapp-</programlisting>
 
 	<para><command>Running certutil Commands from a Batch File</command></para>
 	<para>
 		A series of commands can be run sequentially from a text file with the <option>-B</option> command option. The only argument for this specifies the input file.
 	</para>
-<programlisting language="Bash">$ certutil -B -i /path/to/batch-file</programlisting>
+<programlisting>$ certutil -B -i /path/to/batch-file</programlisting>
   </refsection>
 
+<refsection id="databases"><title>NSS Database Types</title>
+<para>NSS originally used BerkeleyDB databases to store security information. 
+The last versions of these <emphasis>legacy</emphasis> databases are:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert8.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key3.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			secmod.db for PKCS #11 module information
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>BerkeleyDB has performance limitations, though, which prevent it from being easily used by multiple applications simultaneously. NSS has 
+some flexibility that allows applications to use their own, independent database engine while keeping a shared database and working around the access issues. Still, NSS
+requires more flexibility to provide a truly shared security database.</para>
+
+<para>In 2009, NSS introduced a new set of databases that are SQLite databases rather than 
+BerkleyDB. These new databases provide more accessibility and performance:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert9.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key4.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			pkcs11.txt, which is listing of all of the PKCS #11 modules contained in a new subdirectory in the security databases directory
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>Because the SQLite databases are designed to be shared, these are the <emphasis>shared</emphasis> database type. The shared database type is preferred; the legacy format is included for backward compatibility.</para>
+
+<para>By default, the tools (<command>certutil</command>, <command>pk12util</command>, <command>modutil</command>) assume that the given security databases follow the more common legacy type. 
+Using the SQLite databases must be manually specified by using the <command>sql:</command> prefix with the given security directory. For example:</para>
+
+<programlisting>$ certutil -L -d sql:/home/my/sharednssdb</programlisting>
+
+<para>To set the shared database type as the default type for the tools, set the <envar>NSS_DEFAULT_DB_TYPE</envar> environment variable to <envar>sql</envar>:</para>
+<programlisting>export NSS_DEFAULT_DB_TYPE="sql"</programlisting>
+
+<para>This line can be set added to the <filename>~/.bashrc</filename> file to make the change permanent.</para>
+
+<para>Most applications do not use the shared database by default, but they can be configured to use them. For example, this how-to article covers how to configure Firefox and Thunderbird to use the new shared NSS databases:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+</itemizedlist>
+<para>For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
+</refsection>
+
 
   <refsection id="seealso">
     <title>See Also</title>
+    <para>pk12util (1)</para>
+    <para>modutil (1)</para>
     <para><command>certutil</command> has arguments or operations that use features defined in several IETF RFCs.</para>
+	<itemizedlist>
+	<listitem>
 	<para>
-		* http://tools.ietf.org/html/rfc5280
+		http://tools.ietf.org/html/rfc5280
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* http://tools.ietf.org/html/rfc1113
+		http://tools.ietf.org/html/rfc1113
 	</para>
+	</listitem>
+	<listitem>
 	<para>
-		* http://tools.ietf.org/html/rfc1485
+		http://tools.ietf.org/html/rfc1485
 	</para>
+	</listitem>
+	</itemizedlist>
+
+	<para>The NSS wiki has information on the new database design and how to configure applications to use it.</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
   </refsection>
 
 <!-- don't change -->
   <refsection id="resources">
     <title>Additional Resources</title>
-    <para>NSS is maintained in conjunction with PKI and security-related projects through Mozilla dn Fedora. The most closely-related project is Dogtag PKI, with a project wiki at <ulink url="http://pki.fedoraproject.org/wiki/">http://pki.fedoraproject.org/wiki/</ulink>. </para>
-	<para>For information specifically about NSS, the NSS project wiki is located at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
-	<para>Mailing lists: pki-devel@redhat.com and pki-users@redhat.com</para>
+	<para>For information about NSS and other tools related to NSS (like JSS), check out the NSS project wiki at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
+	<para>Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto</para>
 	<para>IRC: Freenode at #dogtag-pki</para>
   </refsection>
 
 <!-- fill in your name first; keep the other names for reference -->
   <refsection id="authors">
     <title>Authors</title>
-    <para>The NSS tools were written and maintained by developers with Netscape and now with Red Hat.</para>
+    <para>The NSS tools were written and maintained by developers with Netscape, Red Hat, and Sun.</para>
 	<para>
 		Authors: Elio Maldonado &lt;emaldona@redhat.com>, Deon Lackey &lt;dlackey@redhat.com>.
 	</para>
diff --git a/modutil.xml b/modutil.xml
index e274672..cb73210 100644
--- a/modutil.xml
+++ b/modutil.xml
@@ -2,11 +2,6 @@
 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <refentry>
 
-  <refmeta>
-    <refentrytitle>MODUTIL</refentrytitle>
-    <manvolnum>1</manvolnum>
-  </refmeta>
-
   <refentryinfo>
     <date>august 2010</date>
     <title>NSS Security Tools</title>
@@ -14,13 +9,10 @@
     <productnumber>8</productnumber>
   </refentryinfo>
 
-<!-- this should be one word 
-  <refentryinfo>
-    <date>August 2010</date>
-	<refentrytitle>modutil</refentrytitle>
+  <refmeta>
+    <refentrytitle>MODUTIL</refentrytitle>
     <manvolnum>1</manvolnum>
-  </refentryinfo>
-end  -->
+  </refmeta>
 
   <refnamediv>
     <refname>modutil</refname>
@@ -142,17 +134,18 @@ end  -->
 
       <varlistentry>
         <term>-ciphers cipher-enable-list</term>
-	  <listitem><para>Enable specific ciphers in a module that is being added to the database. The cipher-enable-list is a colon-delimited list of cipher names. Enclose this list in quotation marks if it contains spaces.</para></listitem>
+	  <listitem><para>Enable specific ciphers in a module that is being added to the database. The <emphasis>cipher-enable-list</emphasis> is a colon-delimited list of cipher names. Enclose this list in quotation marks if it contains spaces.</para></listitem>
       </varlistentry>
 
       <varlistentry>
-        <term>-dbdir directory</term>
-	  <listitem><para>Specify the database directory in which to access or create security module database files. <command>modutil</command> defaults to the user's <!-- FIX ME --> <filename>.netscape</filename> directory. </para></listitem>
+        <term>-dbdir [sql:]directory</term>
+	  <listitem><para>Specify the database directory in which to access or create security module database files.</para>
+	<para><command>modutil</command> supports two types of databases: the legacy security databases (<filename>cert8.db</filename>, <filename>key3.db</filename>, and <filename>secmod.db</filename>) and new SQLite databases (<filename>cert9.db</filename>, <filename>key4.db</filename>, and <filename>pkcs11.txt</filename>). If the prefix <command>sql:</command> is not used, then the tool assumes that the given databases are in the old format.</para></listitem>
       </varlistentry>
 
       <varlistentry>
         <term>--dbprefix prefix</term>
-	  <listitem><para>Specify the prefix used on the <filename>cert8.db</filename> and <filename>key3.db</filename> files, such as <filename>my_</filename> for <filename>my_cert8.db</filename>. This option is provided as a special case. Changing the names of the certificate and key databases is not recommended.</para></listitem>
+	  <listitem><para>Specify the prefix used on the database files, such as <filename>my_</filename> for <filename>my_cert8.db</filename>. This option is provided as a special case. Changing the names of the certificate and key databases is not recommended.</para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -180,9 +173,17 @@ end  -->
       <varlistentry>
         <term>-nocertdb</term>
 	  <listitem><para>Do not open the certificate or key databases. This has several effects:</para>
-          <para>* With the <option>-create</option> command, only a <filename>secmod.db</filename> file is created; <filename>cert8.db</filename> and <filename>key3.db</filename> are not created.</para>
-          <para>* With the <option>-jar</option> command, signatures on the JAR file are not checked.</para>
-          <para>* With the <option>-changepw</option> command, the password on the NSS internal module cannot be set or changed, since this password is stored in <filename>key3.db</filename>.</para></listitem>
+		<itemizedlist>
+		<listitem>
+          <para>With the <option>-create</option> command, only a <filename>secmod.db</filename> file is created; <filename>cert8.db</filename> and <filename>key3.db</filename> are not created.</para>
+		</listitem>
+		<listitem>
+          <para>With the <option>-jar</option> command, signatures on the JAR file are not checked.</para>
+		</listitem>
+		<listitem>
+          <para>With the <option>-changepw</option> command, the password on the NSS internal module cannot be set or changed, since this password is stored in <filename>key3.db</filename>.</para></listitem>
+		</itemizedlist>
+		</listitem>
       </varlistentry>
 
       <varlistentry>
@@ -217,142 +218,44 @@ end  -->
 
     <para><command>Creating Database Files</command></para>
     <para>Before any operations can be performed, there must be a set of security databases available (<filename>cert8.db</filename>, <filename>key3.db</filename>, and <filename>secmod.db</filename>). <command>modutil</command> can be used to create these files. The only required argument is the database that where the databases will be located.</para>
-<programlisting language="Bash">modutil -create -dbdir directory</programlisting>
-
-	<para><command>Deleting a Module</command></para>
-    <para>A specific PKCS #11 module can be deleted from the <filename>secmod.db</filename> database:</para>
-<programlisting language="Bash">modutil -delete modulename </programlisting>
-
-	<para><command>Displaying Module Information</command></para>
-	<para>The <filename>secmod.db</filename> database 
-    <para>Displaying basic module information or detailed information about the contents of a given module:</para>
-<programlisting language="Bash">modutil -list [modulename] </programlisting>
-
-    <para>Displaying the module specs for any or all loaded modules:</para>
-<programlisting language="Bash">modutil -rawlist [modulename] </programlisting>
-   
-<programlisting language="Bash">modutil -list "Netscape Internal PKCS #11 Module" -dbdir c:\databases 
-
-Using database directory c:\databases...
---------------------------------------------------------
-Name: Netscape Internal PKCS #11 Module
-Library file: **Internal ONLY module**
-Manufacturer: Netscape Communications Corp 
-Description: Communicator Internal Crypto Svc
-PKCS #11 Version 2.0
-Library Version: 4.0
-Cipher Enable Flags: None
-Default Mechanism Flags: RSA:DSA:RC2:RC4:DES:SHA1:MD5:MD2
-
-Slot: Communicator Internal Cryptographic Services Version 4.0
-Manufacturer: Netscape Communications Corp 
-Type: Software
-Version Number: 4.1
-Firmware Version: 0.0
-Status: Enabled
-Token Name: Communicator Generic Crypto Svcs
-Token Manufacturer: Netscape Communications Corp 
-Token Model: Libsec 4.0 
-Token Serial Number: 0000000000000000
-Token Version: 4.0
-Token Firmware Version: 0.0
-Access: Write Protected
-Login Type: Public (no login required)
-User Pin: NOT Initialized
-
-Slot: Communicator User Private Key and Certificate Services
-Manufacturer: Netscape Communications Corp 
-Type: Software
-Version Number: 3.0
-Firmware Version: 0.0
-Status: Enabled
-Token Name: Communicator Certificate DB 
-Token Manufacturer: Netscape Communications Corp 
-Token Model: Libsec 4.0 
-Token Serial Number: 0000000000000000
-Token Version: 7.0
-Token Firmware Version: 0.0
-Access: NOT Write Protected
-Login Type: Login required
-User Pin: NOT Initialized</programlisting>
-
-	<para><command>Setting a Default Provider</command></para>
-
-    <para>Setting the default provider status of various security mechanisms in an existing PKCS #11 module:</para>
-<programlisting language="Bash">modutil -default modulename -mechanisms mechanism-list </programlisting>
-	<para>This example makes the specified module a default provider for the RSA, DSA, and RC2 security mechanisms:</para>
-
-<programlisting language="Bash">modutil -default "Cryptographic Module" -dbdir c:\databases -mechanisms RSA:DSA:RC2 
-
-Using database directory c:\databases...
-
-Successfully changed defaults.</programlisting>
-
-    <para>Clearing the default provider status of various security mechanisms in an existing PKCS #11 module:</para>
-<programlisting language="Bash">modutil -undefault modulename -mechanisms mechanism-list </programlisting>
-
-	<para><command>Enabling a Slot</command></para>
-
-    <para>Enabling a specific slot or all slots within a module:</para>
-<programlisting language="Bash">modutil -enable modulename [-slot slotname] </programlisting>
-
-    <para>Disabling a specific slot or all slots within a module:</para>
-<programlisting language="Bash">modutil -disable modulename [-slot slotname] </programlisting>
-<programlisting language="Bash">modutil -enable "Cryptographic Module" -slot "Cryptographic Reader" -dbdir c:\databases 
-
-Using database directory c:\databases...
-
-Slot "Cryptographic Reader" enabled. </programlisting>
-
-	<para><command>Enabling FIPS Compliance</command></para>
-
-    <para>Enabling or disabling FIPS 140-2 compliance within the Netscape Communicator internal module:</para>
-<programlisting language="Bash">modutil -fips [true | false] </programlisting>
-<programlisting language="Bash">modutil -dbdir "C:\databases" -fips true 
-
-FIPS mode enabled. </programlisting>
+<programlisting>modutil -create -dbdir [sql:]directory</programlisting>
 
 	<para><command>Adding a Cryptographic Module</command></para>
+	<para>Adding a PKCS #11 module means submitting a supporting library file, enabling its ciphers, and setting default provider status for various security mechanisms. This can be done by supplying all of the information through <command>modutil</command> directly or by running a JAR file and install script. For the most basic case, simply upload the library:</para>
+<programlisting>modutil -add modulename -libfile library-file [-ciphers cipher-enable-list] [-mechanisms mechanism-list] </programlisting>
+	<para>For example:
+<programlisting>modutil -dbdir sql:/home/my/sharednssdb -add "Example PKCS #11 Module" -libfile "/tmp/crypto.so" -mechanisms RSA:DSA:RC2:RANDOM 
 
-    <para>Adding a PKCS #11 module, which includes setting a supporting library file, enabling ciphers, and setting default provider status for various security mechanisms:</para>
-<programlisting language="Bash">modutil -add modulename -libfile library-file [-ciphers cipher-enable-list] [-mechanisms mechanism-list] </programlisting>
-<programlisting language="Bash">modutil -dbdir "C:\databases" -add "Cryptorific Module" -libfile "C:\winnt\system32\crypto.dll" -mechanisms RSA:DSA:RC2:RANDOM 
-
-Using database directory C:\databases... 
-Module "Cryptorific Module" added to database.</programlisting>
+Using database directory ... 
+Module "Example PKCS #11 Module" added to database.</programlisting>
 
-<programlisting language="Bash">modutil -rawadd modulespec</programlisting>
 
 	<para><command>Installing a Cryptographic Module from a JAR File</command></para>
-
-    <para>Adding a PKCS #11 module from an existing JAR file:</para>
-<programlisting language="Bash">modutil -jar JAR-file -installdir root-installation-directory [-tempdir temporary-directory] </programlisting>
-	<para>This example installs a cryptographic module from the following sample installation script.</para>
-<programlisting language="Bash">Platforms { 
-   WinNT::x86 { 
-      ModuleName { "Cryptorific Module" } 
-      ModuleFile { crypto.dll } 
+	<para>PKCS #11 modules can also be loaded using a JAR file, which contains all of the required libraries and an installation script that describes how to install the module. The JAR install script is described in more detail in <xref linkend="jar-install-file" />.</para>
+	<para>The JAR installation script defines the setup information for each platform that the module can be installed on. For example:</para>
+<programlisting>Platforms { 
+   Linux:5.4.08:x86 { 
+      ModuleName { "Example PKCS #11 Module" } 
+      ModuleFile { crypto.so } 
       DefaultMechanismFlags{0x0000} 
       CipherEnableFlags{0x0000} 
       Files { 
-         crypto.dll { 
-            RelativePath{ %root%/system32/crypto.dll } 
+         crypto.so { 
+            Path{ /tmp/crypto.so } 
          } 
-         setup.exe { 
+         setup.sh { 
             Executable 
-            RelativePath{ %temp%/setup.exe } 
+            Path{ /tmp/setup.sh } 
          } 
       } 
    } 
-   Win95::x86 { 
-      EquivalentPlatform { Winnt::x86 } 
+   Linux:6.0.0:x86 { 
+      EquivalentPlatform { Linux:5.4.08:x86 } 
    } 
 } </programlisting>
-	<para>To install from the script, use the <option>-jar</option> argument to run the script.</para>
-
-<programlisting language="Bash">modutil -dbdir "c:\databases" -jar install.jar -installdir "C:/winnt" 
+	<para>Both the install script and the required libraries must be bundled in a JAR file, which is specified with the <option>-jar</option> argument.</para>
 
-Using database directory c:\databases... 
+<programlisting>modutil -dbdir sql:/home/mt"jar-install-filey/sharednssdb -jar install.jar -installdir sql:/home/my/sharednssdb
 
 This installation JAR file was signed by: 
 ---------------------------------------------- 
@@ -372,44 +275,170 @@ OU="VeriSign, Inc.", O=VeriSign Trust Network
 Do you wish to continue this installation? (y/n) y 
 Using installer script "installer_script" 
 Successfully parsed installation script 
-Current platform is WINNT::x86 
-Using installation parameters for platform WinNT::x86 
-Installed file crypto.dll to C:/winnt/system32/crypto.dll 
-Installed file setup.exe to ./pk11inst.dir/setup.exe 
-Executing "./pk11inst.dir/setup.exe"... 
-"./pk11inst.dir/setup.exe" executed successfully 
-Installed module "Cryptorific Module" into module database 
+Current platform is Linux:5.4.08:x86 
+Using installation parameters for platform Linux:5.4.08:x86 
+Installed file crypto.so to /tmp/crypto.so
+Installed file setup.sh to ./pk11inst.dir/setup.sh 
+Executing "./pk11inst.dir/setup.sh"... 
+"./pk11inst.dir/setup.sh" executed successfully 
+Installed module "Example PKCS #11 Module" into module database 
 
 Installation completed successfully </programlisting>
 
+	<para><command>Adding Module Spec</command></para>
+	<para>Each module has information stored in the security database about its configuration and parameters. These can be added or edited using the <option>-rawadd</option> command. For the current settings or to see the format of the module spec in the database, use the <option>-rawlist</option> option.</para>
+<programlisting>modutil -rawadd modulespec</programlisting>
+
+
+	<para><command>Deleting a Module</command></para>
+    <para>A specific PKCS #11 module can be deleted from the <filename>secmod.db</filename> database:</para>
+<programlisting>modutil -delete modulename -dbdir [sql:]directory </programlisting>
+
+	<para><command>Displaying Module Information</command></para>
+	<para>The <filename>secmod.db</filename> database contains information about the PKCS #11 modules that are available to an application or server to use. The list of all modules, information about specific modules, and database configuration specs for modules can all be viewed. </para>
+    <para>To simply get a list of modules in the database, use the <option>-list</option> command.</para>
+<programlisting>modutil -list [modulename] -dbdir [sql:]directory </programlisting>
+	<para>Listing the modules shows the module name, their status, and other associated security databases for certificates and keys. For example:</para>
+   
+<programlisting>modutil -list -dbdir sql:/home/my/sharednssdb 
+
+Listing of PKCS #11 Modules
+-----------------------------------------------------------
+  1. NSS Internal PKCS #11 Module
+         slots: 2 slots attached
+        status: loaded
+
+         slot: NSS Internal Cryptographic Services                            
+        token: NSS Generic Crypto Services
+
+         slot: NSS User Private Key and Certificate Services                  
+        token: NSS Certificate DB
+-----------------------------------------------------------</programlisting>
+	<para>Passing a specific module name with the <option>-list</option> returns details information about the module itself, like supported cipher mechanisms, version numbers, serial numbers, and other information about the module and the token it is loaded on. For example:</para>
+<programlisting> modutil -list "NSS Internal PKCS #11 Module" -dbdir sql:/home/my/sharednssdb
+
+-----------------------------------------------------------
+Name: NSS Internal PKCS #11 Module
+Library file: **Internal ONLY module**
+Manufacturer: Mozilla Foundation              
+Description: NSS Internal Crypto Services    
+PKCS #11 Version 2.20
+Library Version: 3.11
+Cipher Enable Flags: None
+Default Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES
+
+  Slot: NSS Internal Cryptographic Services                            
+  Slot Mechanism Flags: RSA:RC2:RC4:DES:DH:SHA1:MD5:MD2:SSL:TLS:AES
+  Manufacturer: Mozilla Foundation              
+  Type: Software
+  Version Number: 3.11
+  Firmware Version: 0.0
+  Status: Enabled
+  Token Name: NSS Generic Crypto Services     
+  Token Manufacturer: Mozilla Foundation              
+  Token Model: NSS 3           
+  Token Serial Number: 0000000000000000
+  Token Version: 4.0
+  Token Firmware Version: 0.0
+  Access: Write Protected
+  Login Type: Public (no login required)
+  User Pin: NOT Initialized
+
+  Slot: NSS User Private Key and Certificate Services                  
+  Slot Mechanism Flags: None
+  Manufacturer: Mozilla Foundation              
+  Type: Software
+  Version Number: 3.11
+  Firmware Version: 0.0
+  Status: Enabled
+  Token Name: NSS Certificate DB              
+  Token Manufacturer: Mozilla Foundation              
+  Token Model: NSS 3           
+  Token Serial Number: 0000000000000000
+  Token Version: 8.3
+  Token Firmware Version: 0.0
+  Access: NOT Write Protected
+  Login Type: Login required
+  User Pin: Initialized</programlisting>
+	<para>A related command, <option>-rawlist</option> returns information about the database configuration for the modules. (This information can be edited by loading new specs using the <option>-rawadd</option> command.)</para>
+<programlisting> modutil -rawlist -dbdir sql:/home/my/sharednssdb
+ name="NSS Internal PKCS #11 Module" parameters="configdir=. certPrefix= keyPrefix= secmod=secmod.db flags=readOnly " NSS="trustOrder=75 cipherOrder=100 slotParams={0x00000001=[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,RANDOM askpw=any timeout=30 ] }  Flags=internal,critical"</programlisting>
+
+	<para><command>Setting a Default Provider for Security Mechanisms</command></para>
+	<para>Multiple security modules may provide support for the same security mechanisms. It is possible to set a specific security module as the default provider for a specific security mechanism (or, conversely, to prohibit a provider from supplying those mechanisms).</para>
+<programlisting>modutil -default modulename -mechanisms mechanism-list </programlisting>
+	<para>To set a module as the default provider for mechanisms, use the <option>-default</option> command with a colon-separated list of mechanisms. The available mechanisms depend on the module; NSS supplies almost all common mechanisms. For example:</para>
+<programlisting>modutil -default "NSS Internal PKCS #11 Module" -dbdir -mechanisms RSA:DSA:RC2 
+
+Using database directory c:\databases...
+
+Successfully changed defaults.</programlisting>
+
+    <para>Clearing the default provider has the same format:</para>
+<programlisting>modutil -undefault "NSS Internal PKCS #11 Module" -dbdir -mechanisms MD2:MD5</programlisting>
+
+	<para><command>Enabling and Disabling Modules and Slots</command></para>
+	<para>Modules, and specific slots on modules, can be selectively enabled or disabled using <command>modutil</command>. Both commands have the same format:</para>
+<programlisting>modutil -enable|-disable modulename [-slot slotname] </programlisting>
+
+    <para>For example:</para>
+<programlisting>modutil -enable "NSS Internal PKCS #11 Module" -slot "NSS Internal Cryptographic Services                            " -dbdir .
+
+Slot "NSS Internal Cryptographic Services                            " enabled.</programlisting>
+	<para>Be sure that the appropriate amount of trailing whitespace is after the slot name. Some slot names have a significant amount of whitespace that must be included, or the operation will fail.</para>
+
+	<para><command>Enabling and Verifying FIPS Compliance</command></para>
+	<para>The NSS modules can have FIPS 140-2 compliance enabled or disabled using <command>modutil</command> with the <option>-fips</option> option. For example:
+<programlisting>modutil -fips true -dbdir sql:/home/my/sharednssdb/
+
+FIPS mode enabled.</programlisting>
+	<para>To verify that status of FIPS mode, run the <option>-chkfips</option> command with either a true or false flag (it doesn't matter which). The tool returns the current FIPS setting.
+<programlisting>modutil -chkfips false -dbdir sql:/home/my/sharednssdb/
+
+FIPS mode enabled.</programlisting>
+
 	<para><command>Changing the Password on a Token</command></para>
 
     <para>Initializing or changing a token's password:</para>
-<programlisting language="Bash">modutil -changepw tokenname [-pwfile old-password-file] [-newpwfile new-password-file] </programlisting>
-<programlisting language="Bash">modutil -dbdir "c:\databases" -changepw "Communicator Certificate DB" 
+<programlisting>modutil -changepw tokenname [-pwfile old-password-file] [-newpwfile new-password-file] </programlisting>
+<programlisting>modutil -dbdir sql:/home/my/sharednssdb -changepw "NSS Certificate DB" 
 
-Using database directory c:\databases... 
 Enter old password: 
 Incorrect password, try again... 
 Enter old password: 
 Enter new password: 
 Re-enter new password: 
 Token "Communicator Certificate DB" password changed successfully.</programlisting>
-<programlisting>% blah blah</programlisting>
   </refsection>
 
   <refsection id="jar-install-file"><title>JAR Installation File Format</title>
-     <para>When a JAR file is run by a server, by the Security Module Database Tool, or by any program that does not interpret JavaScript, a special information file must be included in the format described below. This information file contains special scripting and must be declared in the JAR archive's manifest file. The script can have any name. The metainfo tag for this is Pkcs11_install_script. To declare meta-information in the manifest file, put it in a file that is passed to the Netscape Signing Tool.</para>
+     <para>When a JAR file is run by a server, by <command>modutil</command>, or by any program that does not interpret JavaScript, a special information file must be included to install the libraries. There are several things to keep in mind with this file:</para>
+	<itemizedlist>
+		<listitem>
+			<para>
+				It must be declared in the JAR archive's manifest file. 
+			</para>
+		</listitem>
+		<listitem>
+			<para>
+				The script can have any name. 
+			</para>
+		</listitem>
+		<listitem>
+			<para>
+				The metainfo tag for this is <command>Pkcs11_install_script</command>. To declare meta-information in the manifest file, put it in a file that is passed to <command>signtool</command>.</para>
+		</listitem>
+	</itemizedlist>
 
 	<para><command>Sample Script</command></para>
-	<para>For example, the PKCS #11 installer script could be in the file pk11install. If so, the metainfo file for the Netscape Signing Tool would include a line such as this:</para>
-<programlisting language="Bash">+ Pkcs11_install_script: pk11install</programlisting>
+	<para>For example, the PKCS #11 installer script could be in the file pk11install. If so, the metainfo file for <command>signtool</command> includes a line such as this:</para>
+<programlisting>+ Pkcs11_install_script: pk11install</programlisting>
 
-	<para>The sample script file could contain the following:</para>
-<programlisting language="Bash">ForwardCompatible { IRIX:6.2:mips SUNOS:5.5.1:sparc }
+	<para>The script must define the platform and version number, the module name and file, and any optional information like supported ciphers and mechanisms. Multiple platforms can be defined in a single install file.</para>
+<programlisting>ForwardCompatible { IRIX:6.2:mips SUNOS:5.5.1:sparc }
 Platforms {
    WINNT::x86 {
-      ModuleName { "Fortezza Module" }
+      ModuleName { "Example Module" }
       ModuleFile { win32/fort32.dll }
       DefaultMechanismFlags{0x0001}
       DefaultCipherFlags{0x0001}
@@ -430,7 +459,7 @@ Platforms {
       EquivalentPlatform {WINNT::x86}
    }
    SUNOS:5.5.1:sparc {
-      ModuleName { "Fortezza UNIX Module" }
+      ModuleName { "Example UNIX Module" }
       ModuleFile { unix/fort.so }
       DefaultMechanismFlags{0x0001}
       CipherEnableFlags{0x0001}
@@ -453,7 +482,8 @@ Platforms {
 }</programlisting>
 
 	<para><command>Script Grammar</command></para>
-<programlisting language="Java">--> valuelist
+	<para>The script is basic Java, allowing lists, key-value pairs, strings, and combinations of all of them.</para>
+<programlisting>--> valuelist
 
 valuelist --> value valuelist
                &lt;null>
@@ -469,46 +499,91 @@ string --> simple_string
             "complex_string"
 
 simple_string --> [^ \t\n\""{""}"]+ 
-(No whitespace, quotes, or braces.)
 
-complex_string --> ([^\"\\\r\n]|(\\\")|(\\\\))+ (Quotes and
-backslashes must be escaped with a backslash. A complex string must not
-include newlines or carriage returns.)</programlisting>
+complex_string --> ([^\"\\\r\n]|(\\\")|(\\\\))+ </programlisting>
 
-	<para>Outside of complex strings, all white space (for example, spaces, tabs, and carriage returns) is considered equal and is used only to delimit tokens.</para>
+	<para>Quotes and backslashes must be escaped with a backslash. A complex string must not include newlines or carriage returns.Outside of complex strings, all white space (for example, spaces, tabs, and carriage returns) is considered equal and is used only to delimit tokens.</para>
 
 	<para><command>Keys</command></para>
-	<para>ForwardCompatible Gives a list of platforms that are forward compatible. If the current platform cannot be found in the list of supported platforms, then the ForwardCompatible list is checked for any platforms that have the same OS and architecture in an earlier version. If one is found, its attributes are used for the current platform. Platforms (required) Gives a list of platforms. Each entry in the list is itself a key-value pair: the key is the name of the platform and the value list contains various attributes of the platform. The ModuleName, ModuleFile, and Files attributes must be specified for each platform unless an EquivalentPlatform attribute is specified. The platform string is in the following format: system name:OS release:architecture. The installer obtains these values from NSPR. OS release is an empty string on non-Unix operating systems. The following system names and platforms are currently defined by NSPR:</para>
-
-	<para>* AIX (rs6000)</para>
-	<para>* BSDI (x86)</para>
-	<para>* FREEBSD (x86)</para>
-	<para>* HPUX (hppa1.1)</para>
-	<para>* IRIX (mips)</para>
-	<para>* LINUX (ppc, alpha, x86)</para>
-	<para>* MacOS (PowerPC)</para>
-	<para>* NCR (x86)</para>
-	<para>* NEC (mips)</para>
-	<para>* OS2 (x86)</para>
-	<para>* OSF (alpha)</para>
-	<para>* ReliantUNIX (mips)</para>
-	<para>* SCO (x86)</para>
-	<para>* SOLARIS (sparc)</para>
-	<para>* SONY (mips)</para>
-	<para>* SUNOS (sparc)</para>
-	<para>* UnixWare (x86)</para>
-	<para>* WIN16 (x86)</para>
-	<para>* WIN95 (x86)</para>
-	<para>* WINNT (x86)</para>
-
-	<para>Here are some examples of valid platform strings:</para>
+	<para>The Java install file uses keys to define the platform and module information.</para>
+	<para><command>ForwardCompatible</command> gives a list of platforms that are forward compatible. If the current platform cannot be found in the list of supported platforms, then the <command>ForwardCompatible</command> list is checked for any platforms that have the same OS and architecture in an earlier version. If one is found, its attributes are used for the current platform. </para>
+	<para><command>Platforms</command> (required) Gives a list of platforms. Each entry in the list is itself a key-value pair: the key is the name of the platform and the value list contains various attributes of the platform. The platform string is in the format <emphasis>system name:OS release:architecture</emphasis>. The installer obtains these values from NSPR. OS release is an empty string on non-Unix operating systems. NSPR supports these platforms:</para>
+	<itemizedlist>
+	<listitem>
+	<para>AIX (rs6000)</para>
+	</listitem>
+	<listitem>
+	<para>BSDI (x86)</para>
+	</listitem>
+	<listitem>
+	<para>FREEBSD (x86)</para>
+	</listitem>
+	<listitem>
+	<para>HPUX (hppa1.1)</para>
+	</listitem>
+	<listitem>
+	<para>IRIX (mips)</para>
+	</listitem>
+	<listitem>
+	<para>LINUX (ppc, alpha, x86)</para>
+	</listitem>
+	<listitem>
+	<para>MacOS (PowerPC)</para>
+	</listitem>
+	<listitem>
+	<para>NCR (x86)</para>
+	</listitem>
+	<listitem>
+	<para>NEC (mips)</para>
+	</listitem>
+	<listitem>
+	<para>OS2 (x86)</para>
+	</listitem>
+	<listitem>
+	<para>OSF (alpha)</para>
+	</listitem>
+	<listitem>
+	<para>ReliantUNIX (mips)</para>
+	</listitem>
+	<listitem>
+	<para>SCO (x86)</para>
+	</listitem>
+	<listitem>
+	<para>SOLARIS (sparc)</para>
+	</listitem>
+	<listitem>
+	<para>SONY (mips)</para>
+	</listitem>
+	<listitem>
+	<para>SUNOS (sparc)</para>
+	</listitem>
+	<listitem>
+	<para>UnixWare (x86)</para>
+	</listitem>
+	<listitem>
+	<para>WIN16 (x86)</para>
+	</listitem>
+	<listitem>
+	<para>WIN95 (x86)</para>
+	</listitem>
+	<listitem>
+	<para>WINNT (x86)</para>
+	</listitem>
+	</itemizedlist>
+
+	<para>For example:</para>
 <programlisting>IRIX:6.2:mips
 SUNOS:5.5.1:sparc
 Linux:2.0.32:x86
 WIN95::x86</programlisting>
+	<para>The module information is defined independently for each platform in the <command>ModuleName</command>, <command>ModuleFile</command>, and <command>Files</command> attributes. These attributes must be given unless an <command>EquivalentPlatform</command> attribute is specified. </para>
 
 	<para><command>Per-Platform Keys</command></para>
-	<para>These keys have meaning only within the value list of an entry in the Platforms list. ModuleName (required) Gives the common name for the module. This name will be used to reference the module from Netscape Communicator, the Security Module Database tool (modutil), servers, or any other program that uses the Netscape security module database. ModuleFile (required) Names the PKCS #11 module file (DLL or .so) for this platform. The name is given as the relative path of the file within the JAR archive. Files (required) Lists the files that need to be installed for this module. Each entry in the file list is a key-value pair: the key is the path of the file in the JAR archive, and the value list contains attributes of the file. At least RelativePath or AbsolutePath must be specified for each file. DefaultMechanismFlags Specifies mechanisms for which this module will be a default provider. This key-value pair is a bitstring specified in hexadecimal (0x) format. It is constructed as a bitwise OR of the following constants. If the DefaultMechanismFlags entry is omitted, the value defaults to 0x0.</para>
+	<para>Per-platform keys have meaning only within the value list of an entry in the <command>Platforms</command> list.</para>
+	<para><command>ModuleName</command> (required) gives the common name for the module. This name is used to reference the module by servers and by the <command>modutil</command> tool. </para>
+	<para><command>ModuleFile</command> (required) names the PKCS #11 module file for this platform. The name is given as the relative path of the file within the JAR archive. </para>
+	<para><command>Files</command> (required) lists the files that need to be installed for this module. Each entry in the file list is a key-value pair. The key is the path of the file in the JAR archive, and the value list contains attributes of the file. At least <command>RelativePath</command> or <command>AbsolutePath</command> must be specified for each file.</para>
+	<para><command>DefaultMechanismFlags</command> specifies mechanisms for which this module is the default provider; this is equivalent to the <option>-mechanism</option> option with the <option>-add</option> command. This key-value pair is a bitstring specified in hexadecimal (0x) format. It is constructed as a bitwise OR. If the DefaultMechanismFlags entry is omitted, the value defaults to 0x0.</para>
 
 <programlisting>RSA:                   0x00000001
 DSA:                   0x00000002
@@ -526,14 +601,17 @@ FRIENDLY:              0x10000000
 OWN_PW_DEFAULTS:       0x20000000
 DISABLE:               0x40000000</programlisting>
 
-	<para>CipherEnableFlags Specifies ciphers that this module provides but Netscape Communicator does not, so that Communicator can enable them. This key is a bitstring specified in hexadecimal (0x) format. It is constructed as a bitwise OR of the following constants. If the CipherEnableFlags entry is omitted, the value defaults to 0x0.</para>
-
-<programlisting>FORTEZZA:               0x0000 0001</programlisting>
+	<para><command><command>CipherEnableFlags</command> specifies ciphers that this module provides that NSS does not provide (so that the module enables those ciphers for NSS). This is equivalent to the <option>-cipher</option> argument with the <option>-add</option> command. This key is a bitstring specified in hexadecimal (0x) format. It is constructed as a bitwise OR. If the <command>CipherEnableFlags</command> entry is omitted, the value defaults to 0x0.</para>
 
-	<para>EquivalentPlatform Specifies that the attributes of the named platform should also be used for the current platform. Saves typing when there is more than one platform using the same settings.</para>
+	<para><command>EquivalentPlatform</command> specifies that the attributes of the named platform should also be used for the current platform. This makes it easier when more than one platform uses the same settings.</para>
 
 	<para><command>Per-File Keys</command></para>
-	<para>These keys have meaning only within the value list of an entry in a Files list. At least one of RelativePath and AbsolutePath must be specified. If both are specified, the relative path is tried first, and the absolute path is used only if no relative root directory is provided by the installer program. RelativePath Specifies the destination directory of the file, relative to some directory decided at install time. Two variables can be used in the relative path: "%root%" and "%temp%". "%root%" is replaced at run time with the directory relative to which files should be installed; for example, it may be the server's root directory or the Netscape Communicator root directory. The "%temp%" directory is created at the beginning of the installation and destroyed at the end. The purpose of "%temp%" is to hold executable files (such as setup programs) or files that are used by these programs. For example, a Windows installation might consist of a setup.exe installation program, a help file, and a .cab file containing compressed information. All these files could be installed in the temporary directory. Files destined for the temporary directory are guaranteed to be in place before any executable file is run; they are not deleted until all executable files have finished. AbsolutePath Specifies the destination directory of the file as an absolute path. If both RelativePath and AbsolutePath are specified, the installer attempts to use the relative path; if it is unable to determine a relative path, it uses the absolute path. Executable Specifies that the file is to be executed during the course of the installation. Typically this string would be used for a setup program provided by a module vendor, such as a self-extracting setup.exe. More than one file can be specified as executable, in which case the files are run in the order in which they are specified in the script file. FilePermissions Interpreted as a string of octal digits, according to the standard Unix format. This string is a bitwise OR of the following constants:</para>
+	<para>Some keys have meaning only within the value list of an entry in a <command>Files</command> list.</para>
+	<para>Each file requires a path key the identifies where the file is. Either <command>RelativePath</command> or <command>AbsolutePath</command> must be specified. If both are specified, the relative path is tried first, and the absolute path is used only if no relative root directory is provided by the installer program.</para>
+	<para><command>RelativePath</command> specifies the destination directory of the file, relative to some directory decided at install time. Two variables can be used in the relative path: <command>%root%</command> and <command>%temp%</command>. <command>%root%</command> is replaced at run time with the directory relative to which files should be installed; for example, it may be the server's root directory. The <command>%temp%</command> directory is created at the beginning of the installation and destroyed at the end. The purpose of <command>%temp%</command> is to hold executable files (such as setup programs) or files that are used by these programs. Files destined for the temporary directory are guaranteed to be in place before any executable file is run; they are not deleted until all executable files have finished.</para>
+	<para><command>AbsolutePath</command> specifies the destination directory of the file as an absolute path. </para>
+	<para><command>Executable</command> specifies that the file is to be executed during the course of the installation. Typically, this string is used for a setup program provided by a module vendor, such as a self-extracting setup executable. More than one file can be specified as executable, in which case the files are run in the order in which they are specified in the script file.</para>
+	<para><command>FilePermissions</command> sets permissions on any referenced files in a string of octal digits, according to the standard Unix format. This string is a bitwise OR.</para>
 
 <programlisting>user read:                0400
 user write:               0200
@@ -548,26 +626,112 @@ other execute:       0001</programlisting>
 <para>Some platforms may not understand these permissions. They are applied only insofar as they make sense for the current platform. If this attribute is omitted, a default of 777 is assumed.</para>
   </refsection>
 
+<refsection id="databases"><title>NSS Database Types</title>
+<para>NSS originally used BerkeleyDB databases to store security information. 
+The last versions of these <emphasis>legacy</emphasis> databases are:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert8.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key3.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			secmod.db for PKCS #11 module information
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>BerkeleyDB has performance limitations, though, which prevent it from being easily used by multiple applications simultaneously. NSS has 
+some flexibility that allows applications to use their own, independent database engine while keeping a shared database and working around the access issues. Still, NSS
+requires more flexibility to provide a truly shared security database.</para>
+
+<para>In 2009, NSS introduced a new set of databases that are SQLite databases rather than 
+BerkleyDB. These new databases provide more accessibility and performance:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert9.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key4.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			pkcs11.txt, which is listing of all of the PKCS #11 modules contained in a new subdirectory in the security databases directory
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>Because the SQLite databases are designed to be shared, these are the <emphasis>shared</emphasis> database type. The shared database type is preferred; the legacy format is included for backward compatibility.</para>
+
+<para>By default, the tools (<command>certutil</command>, <command>pk12util</command>, <command>modutil</command>) assume that the given security databases follow the more common legacy type. 
+Using the SQLite databases must be manually specified by using the <command>sql:</command> prefix with the given security directory. For example:</para>
+
+<programlisting>modutil -create -dbdir sql:/home/my/sharednssdb</programlisting>
+
+<para>To set the shared database type as the default type for the tools, set the <envar>NSS_DEFAULT_DB_TYPE</envar> environment variable to <envar>sql</envar>:</para>
+<programlisting>export NSS_DEFAULT_DB_TYPE="sql"</programlisting>
+
+<para>This line can be set added to the <filename>~/.bashrc</filename> file to make the change permanent.</para>
+
+<para>Most applications do not use the shared database by default, but they can be configured to use them. For example, this how-to article covers how to configure Firefox and Thunderbird to use the new shared NSS databases:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+</itemizedlist>
+<para>For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
+</refsection>
+
   <refsection id="seealso">
     <title>See Also</title>
     <para>certutil (1)</para>
     <para>pk12util (1)</para>
     <para>signtool (1)</para>
+
+	<para>The NSS wiki has information on the new database design and how to configure applications to use it.</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
   </refsection>
 
 <!-- don't change -->
   <refsection id="resources">
     <title>Additional Resources</title>
-    <para>NSS is maintained in conjunction with PKI and security-related projects through Mozilla dn Fedora. The most closely-related project is Dogtag PKI, with a project wiki at <ulink url="http://pki.fedoraproject.org/wiki/">http://pki.fedoraproject.org/wiki/</ulink>. </para>
-	<para>For information specifically about NSS, the NSS project wiki is located at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
-	<para>Mailing lists: pki-devel@redhat.com and pki-users@redhat.com</para>
+	<para>For information about NSS and other tools related to NSS (like JSS), check out the NSS project wiki at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
+	<para>Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto</para>
 	<para>IRC: Freenode at #dogtag-pki</para>
   </refsection>
 
 <!-- fill in your name first; keep the other names for reference -->
   <refsection id="authors">
     <title>Authors</title>
-    <para>The NSS tools were written and maintained by developers with Netscape and now with Red Hat.</para>
+    <para>The NSS tools were written and maintained by developers with Netscape, Red Hat, and Sun.</para>
 	<para>
 		Authors: Elio Maldonado &lt;emaldona@redhat.com>, Deon Lackey &lt;dlackey@redhat.com>.
 	</para>
diff --git a/pk12util.xml b/pk12util.xml
index 0f88b9f..db8d78c 100644
--- a/pk12util.xml
+++ b/pk12util.xml
@@ -1,18 +1,19 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!--
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
--->
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 <refentry>
 
   <refentryinfo>
-    <date>August 2010</date>
-<!-- this should be one word -->
-	<refentrytitle>pk12util</refentrytitle>
-    <manvolnum>1</manvolnum>
-<!-- end  -->
+    <date>august 2010</date>
+    <title>NSS Security Tools</title>
+    <productname>nss-tools</productname>
+    <productnumber>8</productnumber>
   </refentryinfo>
 
+  <refmeta>
+    <refentrytitle>PK12UTIL</refentrytitle>
+    <manvolnum>1</manvolnum>
+  </refmeta>
+
   <refnamediv>
     <refname>pk12util</refname>
     <refpurpose>Export and import keys and certificate to or from a PKCS #12 file and the NSS database</refpurpose>
@@ -29,7 +30,7 @@
        <arg>
 
 common-options are:
-[-d dir] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword] 
+[-d [sql:]directory] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword] 
       </arg>
     </cmdsynopsis>
   </refsynopsisdiv>
@@ -68,11 +69,9 @@ common-options are:
       </varlistentry>
 
       <varlistentry>
-        <term>-d dir</term>
-        <listitem><para>Specify the database directory into which to import to or export from certificates and keys. 
-          If not specified the directory defaults to $HOME/.netscape (when $HOME exists in the environment), 
-          or to ./.netscape (when $HOME does not exist in the environment.</para>
-        </listitem>
+        <term>-d [sql:]directory</term>
+        <listitem><para>Specify the database directory into which to import to or export from certificates and keys.</para>
+	<para><command>pk12util</command> supports two types of databases: the legacy security databases (<filename>cert8.db</filename>, <filename>key3.db</filename>, and <filename>secmod.db</filename>) and new SQLite databases (<filename>cert9.db</filename>, <filename>key4.db</filename>, and <filename>pkcs11.txt</filename>). If the prefix <command>sql:</command> is not used, then the tool assumes that the given databases are in the old format.</para></listitem>
       </varlistentry>
 
       <varlistentry>
@@ -141,32 +140,86 @@ common-options are:
 
   <refsection id="return-codes">
     <title>Return Codes</title>
-        <para> * 0 - No error</para>
-        <para> * 1 - User Cancelled</para>
-        <para> * 2 - Usage error</para>
-        <para> * 6 - NLS init error</para>
-        <para> * 8 - Certificate DB open error</para>
-        <para> * 9 - Key DB open error</para>
-        <para> * 10 - File initialization error</para>
-        <para> * 11 - Unicode conversion error</para>
-        <para> * 12 - Temporary file creation error</para>
-        <para> * 13 - PKCS11 get slot error</para>
-        <para> * 14 - PKCS12 decoder start error</para>
-        <para> * 15 - error read from import file</para>
-        <para> * 16 - pkcs12 decode error</para>
-        <para> * 17 - pkcs12 decoder verify error</para>
-        <para> * 18 - pkcs12 decoder validate bags error</para>
-        <para> * 19 - pkcs12 decoder import bags error</para>
-        <para> * 20 - key db conversion version 3 to version 2 error</para>
-        <para> * 21 - cert db conversion version 7 to version 5 error</para>
-        <para> * 22 - cert and key dbs patch error</para>
-        <para> * 23 - get default cert db error</para>
-        <para> * 24 - find cert by nickname error</para>
-        <para> * 25 - create export context error</para>
-        <para> * 26 - PKCS12 add password itegrity error</para>
-        <para> * 27 - cert and key Safes creation error</para>
-        <para> * 28 - PKCS12 add cert and key error</para>
-        <para> * 29 - PKCS12 encode error</para>
+	<itemizedlist>
+	<listitem>
+        <para> 0 - No error</para>
+	</listitem>
+	<listitem>
+        <para> 1 - User Cancelled</para>
+	</listitem>
+	<listitem>
+        <para> 2 - Usage error</para>
+	</listitem>
+	<listitem>
+        <para> 6 - NLS init error</para>
+	</listitem>
+	<listitem>
+        <para> 8 - Certificate DB open error</para>
+	</listitem>
+	<listitem>
+        <para> 9 - Key DB open error</para>
+	</listitem>
+	<listitem>
+        <para> 10 - File initialization error</para>
+	</listitem>
+	<listitem>
+        <para> 11 - Unicode conversion error</para>
+	</listitem>
+	<listitem>
+        <para> 12 - Temporary file creation error</para>
+	</listitem>
+	<listitem>
+        <para> 13 - PKCS11 get slot error</para>
+	</listitem>
+	<listitem>
+        <para> 14 - PKCS12 decoder start error</para>
+	</listitem>
+	<listitem>
+        <para> 15 - error read from import file</para>
+	</listitem>
+	<listitem>
+        <para> 16 - pkcs12 decode error</para>
+	</listitem>
+	<listitem>
+        <para> 17 - pkcs12 decoder verify error</para>
+	</listitem>
+	<listitem>
+        <para> 18 - pkcs12 decoder validate bags error</para>
+	</listitem>
+	<listitem>
+        <para> 19 - pkcs12 decoder import bags error</para>
+	</listitem>
+	<listitem>
+        <para> 20 - key db conversion version 3 to version 2 error</para>
+	</listitem>
+	<listitem>
+        <para> 21 - cert db conversion version 7 to version 5 error</para>
+	</listitem>
+	<listitem>
+        <para> 22 - cert and key dbs patch error</para>
+	</listitem>
+	<listitem>
+        <para> 23 - get default cert db error</para>
+	</listitem>
+	<listitem>
+        <para> 24 - find cert by nickname error</para>
+	</listitem>
+	<listitem>
+        <para> 25 - create export context error</para>
+	</listitem>
+	<listitem>
+        <para> 26 - PKCS12 add password itegrity error</para>
+	</listitem>
+	<listitem>
+        <para> 27 - cert and key Safes creation error</para>
+	</listitem>
+	<listitem>
+        <para> 28 - PKCS12 add cert and key error</para>
+	</listitem>
+	<listitem>
+        <para> 29 - PKCS12 encode error</para>
+	</listitem>
+	</itemizedlist>
   </refsection>
 
   <refsection id="examples">
@@ -174,9 +227,9 @@ common-options are:
     <para><command>Importing Keys and Certificates</command></para>
     <para>The most basic usage of <command>pk12util</command> for importing a certificate or key is the PKCS#12 input file (<option>-i</option>) and some way to specify the security database being accessed (either <option>-d</option> for a directory or <option>-h</option> for a token).
     </para>
-<programlisting language="Bash">pk12util -i p12File [-h tokenname] [-v] [-d dir] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
+<programlisting>pk12util -i p12File [-h tokenname] [-v] [-d [sql:]directory] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
     <para>For example:</para>
-<programlisting language="Bash"># pk12util -i /tmp/cert-files/users.p12 -d /etc/pki/nssdb/
+<programlisting># pk12util -i /tmp/cert-files/users.p12 -d sql:/home/my/sharednssdb
 
 Enter a password which will be used to encrypt your keys.
 The password should be at least 8 characters long,
@@ -190,18 +243,18 @@ pk12util: PKCS12 IMPORT SUCCESSFUL</programlisting>
     <para><command>Exporting Keys and Certificates</command></para>
     <para>Using the <command>pk12util</command> command to export certificates and keys requires both the name of the certificate to extract from the database (<option>-n</option>) and the PKCS#12-formatted output file to write to. There are optional parameters that can be used to encrypt the file to protect the certificate material.
     </para>
-<programlisting>pk12util -o p12File -n certname [-c keyCipher] [-C certCipher] [-m|--key_len keyLen] [-n|--cert_key_len certKeyLen] [-d dir] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
+<programlisting>pk12util -o p12File -n certname [-c keyCipher] [-C certCipher] [-m|--key_len keyLen] [-n|--cert_key_len certKeyLen] [-d [sql:]directory] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
     <para>For example:</para>
-<programlisting language="Bash"># pk12util -o certs.p12 -n Server-Cert -d /etc/pki/nssdb/
+<programlisting># pk12util -o certs.p12 -n Server-Cert -d sql:/home/my/sharednssdb
 Enter password for PKCS12 file: 
 Re-enter password: </programlisting>
 
     <para><command>Listing Keys and Certificates</command></para>
-    <para>The information in a <filename>.p12</filename> file are not human-readable. The certificates and keys in the file can be printed (listed) in a human-readable pretty-print format that shows information for every certificate and any public keys in the <filename>.p12</filename> file. Alternatively, the <option>-r</option> is used to print the certificates and then export them into separate DER binary files, with one certificate in each file. This allows the certificates to be fed to another application, like OpenSSL.
+    <para>The information in a <filename>.p12</filename> file are not human-readable. The certificates and keys in the file can be printed (listed) in a human-readable pretty-print format that shows information for every certificate and any public keys in the <filename>.p12</filename> file.
     </para>
-<programlisting>pk12util -l p12File [-h tokenname] [-r] [-d dir] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
+<programlisting>pk12util -l p12File [-h tokenname] [-r] [-d [sql:]directory] [-P dbprefix] [-k slotPasswordFile|-K slotPassword] [-w p12filePasswordFile|-W p12filePassword]</programlisting>
     <para>For example, this prints the default ASCII output:</para>
-<programlisting language="Bash"># pk12util -l certs.p12
+<programlisting># pk12util -l certs.p12
 
 Enter password for PKCS12 file: 
 Key(shrouded):
@@ -221,8 +274,8 @@ Certificate:
             A,OU=Certification Services Division,O=Thawte Consulting,L=Cape T
             own,ST=Western Cape,C=ZA"
 ....</programlisting>
-    <para>For example, this uses the <option>-r</option> argument to output the DER information. Each certificate is also written to a sequentially-number file, beginning with <filename>file0001.der</filename> and continuing through <filename>file000N.der</filename>, incrementing the number for every certificate:</para>
-<programlisting language="Bash"># pk12util -l test.p12 -r
+    <para>Alternatively, the <option>-r</option> prints the certificates and then exports them into separate DER binary files. This allows the certificates to be fed to another application that supports <filename>.p12</filename> files. Each certificate is written to a sequentially-number file, beginning with <filename>file0001.der</filename> and continuing through <filename>file000N.der</filename>, incrementing the number for every certificate:</para>
+<programlisting># pk12util -l test.p12 -r
 Enter password for PKCS12 file: 
 Key(shrouded):
     Friendly Name: Thawte Freemail Member's Thawte Consulting (Pty) Ltd. ID
@@ -246,62 +299,196 @@ Certificate    Friendly Name: Thawte Freemail Member's Thawte Consulting (Pty) L
     
       <varlistentry>
         <term>Symmetric CBC ciphers for PKCS#5 V2</term>
-        <listitem><para>* DES_CBC</para>
-        <para>* RC2-CBC</para>
-        <para>* RC5-CBCPad</para>
-        <para>* DES-EDE3-CBC (the default for key encryption)</para>
-        <para>* AES-128-CBC</para>
-        <para>* AES-192-CBC</para>
-        <para>* AES-256-CBC</para>
-        <para>* CAMELLIA-128-CBC</para>
-        <para>* CAMELLIA-192-CBC</para>
-        <para>* CAMELLIA-256-CBC</para></listitem>
+        <listitem><para>DES_CBC</para>
+	<itemizedlist>
+	<listitem>
+        <para>RC2-CBC</para>
+	</listitem>
+	<listitem>
+        <para>RC5-CBCPad</para>
+	</listitem>
+	<listitem>
+        <para>DES-EDE3-CBC (the default for key encryption)</para>
+	</listitem>
+	<listitem>
+        <para>AES-128-CBC</para>
+	</listitem>
+	<listitem>
+        <para>AES-192-CBC</para>
+	</listitem>
+	<listitem>
+        <para>AES-256-CBC</para>
+	</listitem>
+	<listitem>
+        <para>CAMELLIA-128-CBC</para>
+	</listitem>
+	<listitem>
+        <para>CAMELLIA-192-CBC</para>
+	</listitem>
+	<listitem>
+        <para>CAMELLIA-256-CBC</para></listitem>
+	</itemizedlist>
+	</listitem>
       </varlistentry>
 
       <varlistentry>
         <term>PKCS#12 PBE ciphers</term>
-        <listitem><para>* PKCS #12 PBE with Sha1 and 128 Bit RC4</para>
-        <para>* PKCS #12 PBE with Sha1 and 40 Bit RC4</para>
-        <para>* PKCS #12 PBE with Sha1 and Triple DES CBC</para>
-        <para>* PKCS #12 PBE with Sha1 and 128 Bit RC2 CBC</para>
-        <para>* PKCS #12 PBE with Sha1 and 40 Bit RC2 CBC</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 128 Bit RC4</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 40 Bit RC4 (the default for non-FIPS mode)</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 3KEY Triple DES-cbc</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 2KEY Triple DES-cbc</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 128 Bit RC2 CBC</para>
-        <para>* PKCS12 V2 PBE with SHA1 and 40 Bit RC2 CBC</para></listitem>
+        <listitem><para>PKCS #12 PBE with Sha1 and 128 Bit RC4</para>
+	<itemizedlist>
+	<listitem>
+        <para>PKCS #12 PBE with Sha1 and 40 Bit RC4</para>
+	</listitem>
+	<listitem>
+        <para>PKCS #12 PBE with Sha1 and Triple DES CBC</para>
+	</listitem>
+	<listitem>
+        <para>PKCS #12 PBE with Sha1 and 128 Bit RC2 CBC</para>
+	</listitem>
+	<listitem>
+        <para>PKCS #12 PBE with Sha1 and 40 Bit RC2 CBC</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 128 Bit RC4</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 40 Bit RC4 (the default for non-FIPS mode)</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 3KEY Triple DES-cbc</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 2KEY Triple DES-cbc</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 128 Bit RC2 CBC</para>
+	</listitem>
+	<listitem>
+        <para>PKCS12 V2 PBE with SHA1 and 40 Bit RC2 CBC</para></listitem>
+	</itemizedlist>
+	</listitem>
       </varlistentry>
 
       <varlistentry>
         <term>PKCS#5 PBE ciphers</term>
-        <listitem><para>* PKCS #5 Password Based Encryption with MD2 and DES CBC</para>
-        <para>* PKCS #5 Password Based Encryption with MD5 and DES CBC</para>
-        <para>* PKCS #5 Password Based Encryption with SHA1 and DES CBC</para></listitem>
+        <listitem><para>PKCS #5 Password Based Encryption with MD2 and DES CBC</para>
+	<itemizedlist>
+	<listitem>
+        <para>PKCS #5 Password Based Encryption with MD5 and DES CBC</para>
+	</listitem>
+	<listitem>
+        <para>PKCS #5 Password Based Encryption with SHA1 and DES CBC</para></listitem>
+	</iteimzedlist>
+	</listitem>
       </varlistentry>
     </variablelist>
     <para>With PKCS#12, the crypto provider may be the soft token module or an external hardware module. If the cryptographic module does not support the requested algorithm, then the next best fit will be selected (usually the default). If no suitable replacement for the desired algorithm can be found, the tool returns the error <emphasis>no security module can perform the requested operation</emphasis>.</para>
   </refsection>
 
+<refsection id="databases"><title>NSS Database Types</title>
+<para>NSS originally used BerkeleyDB databases to store security information. 
+The last versions of these <emphasis>legacy</emphasis> databases are:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert8.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key3.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			secmod.db for PKCS #11 module information
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>BerkeleyDB has performance limitations, though, which prevent it from being easily used by multiple applications simultaneously. NSS has 
+some flexibility that allows applications to use their own, independent database engine while keeping a shared database and working around the access issues. Still, NSS
+requires more flexibility to provide a truly shared security database.</para>
+
+<para>In 2009, NSS introduced a new set of databases that are SQLite databases rather than 
+BerkleyDB. These new databases provide more accessibility and performance:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			cert9.db for certificates
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			key4.db for keys
+		</para>
+	</listitem>
+	<listitem>
+		<para>
+			pkcs11.txt, which is listing of all of the PKCS #11 modules contained in a new subdirectory in the security databases directory
+		</para>
+	</listitem>
+</itemizedlist>
+
+<para>Because the SQLite databases are designed to be shared, these are the <emphasis>shared</emphasis> database type. The shared database type is preferred; the legacy format is included for backward compatibility.</para>
+
+<para>By default, the tools (<command>certutil</command>, <command>pk12util</command>, <command>modutil</command>) assume that the given security databases follow the more common legacy type. 
+Using the SQLite databases must be manually specified by using the <command>sql:</command> prefix with the given security directory. For example:</para>
+
+<programlisting># pk12util -i /tmp/cert-files/users.p12 -d sql:/home/my/sharednssdb
+
+<para>To set the shared database type as the default type for the tools, set the <envar>NSS_DEFAULT_DB_TYPE</envar> environment variable to <envar>sql</envar>:</para>
+<programlisting>export NSS_DEFAULT_DB_TYPE="sql"</programlisting>
+
+<para>This line can be set added to the <filename>~/.bashrc</filename> file to make the change permanent.</para>
+
+<para>Most applications do not use the shared database by default, but they can be configured to use them. For example, this how-to article covers how to configure Firefox and Thunderbird to use the new shared NSS databases:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+</itemizedlist>
+<para>For an engineering draft on the changes in the shared NSS databases, see the NSS project wiki:</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
+</refsection>
+
   <refsection id="seealso">
     <title>See Also</title>
     <para>certutil (1)</para>
     <para>modutil (1)</para>
+
+	<para>The NSS wiki has information on the new database design and how to configure applications to use it.</para>
+<itemizedlist>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB_Howto</para>
+	</listitem>
+	<listitem>
+		<para>
+			https://wiki.mozilla.org/NSS_Shared_DB
+		</para>
+	</listitem>
+</itemizedlist>
   </refsection>
 
 <!-- don't change -->
   <refsection id="resources">
     <title>Additional Resources</title>
-    <para>NSS is maintained in conjunction with PKI and security-related projects through Mozilla dn Fedora. The most closely-related project is Dogtag PKI, with a project wiki at <ulink url="http://pki.fedoraproject.org/wiki/">http://pki.fedoraproject.org/wiki/</ulink>. </para>
-	<para>For information specifically about NSS, the NSS project wiki is located at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
-	<para>Mailing lists: pki-devel@redhat.com and pki-users@redhat.com</para>
+	<para>For information about NSS and other tools related to NSS (like JSS), check out the NSS project wiki at <ulink url="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</ulink>. The NSS site relates directly to NSS code changes and releases.</para>
+	<para>Mailing lists: https://lists.mozilla.org/listinfo/dev-tech-crypto</para>
 	<para>IRC: Freenode at #dogtag-pki</para>
   </refsection>
 
 <!-- fill in your name first; keep the other names for reference -->
   <refsection id="authors">
     <title>Authors</title>
-    <para>The NSS tools were written and maintained by developers with Netscape and now with Red Hat.</para>
+    <para>The NSS tools were written and maintained by developers with Netscape, Red Hat, and Sun.</para>
 	<para>
 		Authors: Elio Maldonado &lt;emaldona@redhat.com>, Deon Lackey &lt;dlackey@redhat.com>.
 	</para>