File:  [mozdev] / certs / www / cadraft.html
Revision 1.6: download - view: text, annotated - select for diffs - revision graph
Tue Oct 15 02:33:27 2002 UTC (15 years ago) by eric
Branches: MAIN
CVS tags: HEAD
no message

<html>
<head>
<title>cadraft</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>

<body bgcolor="#FFFFFF" text="#000000">
<table width="600" border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td valign="top"> 
      <p><font face="Verdana, Arial, Helvetica, sans-serif"><a name="77079"></a><b>Certificate 
        Authorities and Digital Signatures</b></font></p>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Instead of 
        changing the Universal XPConnect privileges (see "<a href="#77070">Setting 
        Up XPFE for Remote Applications</a>" earlier in this chapter), you could 
        create signed remote applications that can be granted access to users' 
        computers. A signed application means that the application has a digital 
        signature, which verifies that a file or group of files was created by 
        the person or organization from which you download and that they are trustworthy. 
        In essence, if you trust the person or organization signing the files, 
        then you trust the files themselves.</font></p>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Digital signatures 
        originate from a certificate authority (CA), an organization that claims 
        responsibility for any digital signature it creates. CAs act as gatekeepers 
        by allowing only people who the organization trusts to create digital 
        signatures. Large CAs like Verisign, whose certificates come preinstalled 
        in many web browsers, enforce validity through large fees. For example, 
        if you can afford $600, then you are an organization with whom the CA 
        would be glad to associate. That $600 then also buys your application 
        respectability with user's web browsers. You can see the CAs that come 
        with the Mozilla browser by going to Privacy &amp; Security &gt; Certificates 
        in your preferences panel and then by selecting the Manage Certificates 
        option. Of the different types of CAs-there's a type for SSL connections, 
        for example, and another one for S/MIME-the Netscape Object Signing certificate 
        is what matters for signed applications. </font></p>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Fortunately, 
        to get your remote applications signed by a CA, you don't have to pay 
        for a Verisign Netscape Object Signing CA because other options are available. 
        You can use the MozDev CA, for example, and even create your own. The 
        next section tells you how use Mozilla tools to become your own certificate 
        authority so you can sign your own applications and those of other Mozilla 
        developers. The <a href="#77088">"Creating Signed Remote Applications</a>" 
        section later in this chapter uses the MozDev CA to discuss both avenues. 
        </font></p>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif"><a name="77080"></a> 
        <b>Mozilla Network Security Services (NSS)</b></font></p>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">The Mozilla 
        Network Security Services tools, which are described in detail at <i><a href="http://www.mozilla.org/projects/security/pki/nss/">http://www.mozilla.org/projects/security/pki/nss/</a></i>, 
        allow you to become your own Netscape Object Signing CA. By becoming your 
        own Netscape Signing CA, you can distribute signing certificates to Mozilla 
        application developers. You can obtain the tools via a simplified distribution 
        of NSS for Windows and Linux at <i><a href="http://certs.mozdev.org/">http://certs.mozdev.org</a></i>. 
        These tools allow you to become a CA and to package signed remote Mozilla 
        applications. Finally, the commands for CertUtil work the same way on 
        Windows, Linux, and any other OS on which you run CertUtil.</font></p>
      <p>&nbsp;</p>
      <font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada:</font><br>
      <pre>C:\NSS\bin&gt;certutil -N -d CA</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada.</font></p>
      <font size="2"></font> <i>Example 12-9: </i> <i>Creating a root certificate</i> 
      <pre>C:\NSS\bin>certutil -d CA -S -s "CN=mozdev.org root CA, O=mozdev.org" -n "mozdev.org" -t ",,C" -v 96 -x -1 -2 -5

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.  Press enter to continue:

Enter Password or Pin for "NSS Certificate DB":


Generating key.  This may take a few moments...

                          0 - Digital Signature
                          1 - Non-repudiation
                          2 - Key encipherment
                          3 - Data encipherment
                          4 - Key agreement
                          5 - Cert signing key
                          6 - CRL signing key
                          Other to finish
5
                          0 - Digital Signature
                          1 - Non-repudiation
                          2 - Key encipherment
                          3 - Data encipherment
                          4 - Key agreement
                          5 - Cert signing key
                          6 - CRL signing key
                          Other to finish
9
Is this a critical extension [y/n]?
y
Is this a CA certificate [y/n]?
y
Enter the path length constraint, enter to skip [<0 for unlimited path]:
3
Is this a critical extension [y/n]?
y
                          0 - SSL Client
                          1 - SSL Server
                          2 - S/MIME
                          3 - Object Signing
                          4 - Reserved for futuer use
                          5 - SSL CA
                          6 - S/MIME CA
                          7 - Object Signing CA
                          Other to finish
7
                          0 - SSL Client
                          1 - SSL Server
                          2 - S/MIME
                          3 - Object Signing
                          4 - Reserved for futuer use
                          5 - SSL CA
                          6 - S/MIME CA
                          7 - Object Signing CA
                          Other to finish
9
Is this a critical extension [y/n]?
y</pre>
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Yada</font></p>
      <pre>C:\NSS\bin&gt;certutil -d CA -L
mozdev.org                                                   u,u,Cu</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font><font size="2">:<br>
        </font> </p>
      <pre>C:\NSS\bin&gt;certutil -L -d CA -n &quot;mozdev.org&quot; -a -o CA/mozdev.cacert</pre>
      <font size="2" face="Verdana, Arial, Helvetica, sans-serif">Yada</font><font size="2"></font><font size="2"><br>
      </font> 
      <pre>C:\NSS\bin&gt;pp -t certificate -a -i  CA/mozdev.cacert
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1545620512 (0x5c204c20)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer: CN=mozdev.org root CA, O=mozdev.org
        Validity:
            Not Before: Tue Oct 15 00:53:31 2002
            Not After: Sat Jan 15 00:53:31 2011
        Subject: CN=mozdev.org root CA, O=mozdev.org
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    00:d1:d8:77:66:79:96:e9:30:e6:89:15:7b:d0:bd:
                    c7:97:5e:ba:52:68:f1:cc:7d:38:b6:f3:49:a3:35:
                    a8:8b:25:e8:74:db:0b:1e:a8:98:9d:8c:d3:ec:c3:
                    54:19:db:e9:f3:4a:c3:f4:e2:76:54:3d:bd:4d:ae:
                    9b:54:f1:02:21:82:8f:54:40:69:f8:16:46:59:12:
                    2e:e7:2f:19:09:8c:e7:19:4a:e3:10:6e:9c:94:07:
                    70:9f:d6:26:2b:ae:c8:81:ff:d7:94:d4:10:63:10:
                    de:f5:89:4f:6c:43:50:ad:85:22:82:af:22:f9:20:
                    1c:4b:66:81:bb:ed:45:3e:07
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name:
                Certificate Type
            Critical:
                True
            Data: <ObjectSigning CA>

            Name:
                Certificate Basic Constraints
            Critical:
                True
            Data: Is a CA with a maximum path length of 3.

            Name:
                Certificate Key Usage
            Critical:
                True
            Data:
                03:02:02:04

    Fingerprint (MD5):
        D4:1D:8C:D9:8F:00:B2:04:E9:80:09:98:EC:F8:42:7E
    Fingerprint (SHA1):
        DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09

    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        7b:7b:76:34:b5:4b:7f:f2:81:81:49:76:4f:43:a4:3f:1e:ef:
        72:5d:64:7e:5f:74:7a:68:dc:26:e3:c3:fc:60:3e:dd:62:0f:
        9a:c1:74:8f:0f:19:52:00:70:f3:2b:e5:7a:50:23:7f:1a:16:
        69:bb:31:a8:14:c2:c0:12:6f:a8:26:dc:87:66:c3:71:d0:e5:
        3f:d8:f4:b8:57:51:2c:ba:b2:51:50:29:4a:94:8f:ae:22:99:
        6e:8e:ad:97:bf:99:a8:1e:3c:4b:18:78:5e:c3:c5:0b:3a:08:
        35:81:58:8d:b7:fd:cb:af:8f:e7:b0:89:b1:77:9f:97:d1:4a:
        03:46
</pre>
      <font size="2" face="Verdana, Arial, Helvetica, sans-serif">Yada</font><font size="2"></font><font size="2">:<br>
      </font> 
      <pre>C:\NSS\bin&gt;certutil -d JAR -A -n &quot;mozdev.org&quot; -t &quot;,,C&quot; -i CA/mozdev.cacert
Enter Password or Pin for "NSS Certificate DB":</pre>
      <font size="2"></font> 
      <p><font size="2" face="Verdana, Arial, Helvetica, sans-serif">Yada:</font></p>
      <pre>C:\NSS\bin>certutil -L -d JAR
mozdev.org                                                   ,,C</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font></p>
      <pre>C:\NSS\bin>certutil -d JAR -R -o JAR/req.txt -a -s "CN=nelsons object signing cert, O=mozdev.org" -v 95

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.  Press enter to continue:

Enter Password or Pin for "NSS Certificate DB":


Generating key.  This may take a few moments...</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font></p>
      <pre>C:\NSS\bin>certutil -d CA -C -c "mozdev.org"
 -i JAR/req.txt -a -o JAR/cert.txt -1 -2 -5
                          0 - Digital Signature
                          1 - Non-repudiation
                          2 - Key encipherment
                          3 - Data encipherment
                          4 - Key agreement
                          5 - Cert signing key
                          6 - CRL signing key
                          Other to finish
0
                          0 - Digital Signature
                          1 - Non-repudiation
                          2 - Key encipherment
                          3 - Data encipherment
                          4 - Key agreement
                          5 - Cert signing key
                          6 - CRL signing key
                          Other to finish
9
Is this a critical extension [y/n]?
y
Is this a CA certificate [y/n]?
n
Enter the path length constraint, enter to skip [<0 for unlimited path]:
-1
Is this a critical extension [y/n]?
y
                          0 - SSL Client
                          1 - SSL Server
                          2 - S/MIME
                          3 - Object Signing
                          4 - Reserved for futuer use
                          5 - SSL CA
                          6 - S/MIME CA
                          7 - Object Signing CA
                          Other to finish
3
                          0 - SSL Client
                          1 - SSL Server
                          2 - S/MIME
                          3 - Object Signing
                          4 - Reserved for futuer use
                          5 - SSL CA
                          6 - S/MIME CA
                          7 - Object Signing CA
                          Other to finish
9
Is this a critical extension [y/n]?
y
Enter Password or Pin for "NSS Certificate DB":</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font></p>
      <pre>C:\NSS\bin>pp -t certificate -a -i JAR/cert.txt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1272441488 (0x4bd7ea90)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer: CN=mozdev.org root CA, O=mozdev.org
        Validity:
            Not Before: Tue Oct 15 01:40:09 2002
            Not After: Wed Jan 15 01:40:09 2003
        Subject: CN=nelsons object signing cert, O=mozdev.org
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    00:b2:98:55:fb:2a:08:60:06:8c:af:68:bf:c8:a2:
                    d7:7e:80:f3:11:fe:6d:3c:9c:50:20:d2:ad:84:7d:
                    c7:3e:ed:77:08:db:f6:82:ea:bf:98:7a:a1:00:24:
                    21:f9:3d:00:1e:5f:2d:52:31:d7:92:4b:1b:b3:c4:
                    a4:b6:65:34:64:82:ee:c1:f7:56:bc:1f:0c:fd:57:
                    0f:c8:a7:d7:63:47:7e:9e:e8:8b:9d:7f:f0:c1:79:
                    cf:d1:27:99:7c:23:16:7e:ed:fc:61:30:52:8f:b7:
                    07:49:4c:b3:ef:df:ce:d9:19:7f:7a:f1:3b:f9:82:
                    4c:e9:6c:be:47:27:c0:57:d1
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name:
                Certificate Type
            Critical:
                True
            Data: &lt;Object Signing&gt;

            Name:
                Certificate Basic Constraints
            Critical:
                True
            Data: Is not a CA.

            Name:
                Certificate Key Usage
            Critical:
                True
            Data:
                03:02:07:80

    Fingerprint (MD5):
        D4:1D:8C:D9:8F:00:B2:04:E9:80:09:98:EC:F8:42:7E
    Fingerprint (SHA1):
        DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09

    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        0d:fb:97:05:5b:de:71:83:8e:6d:6e:31:ac:82:44:3f:99:24:
        95:5e:03:dc:a4:9c:28:76:d6:64:37:2a:77:7e:6c:a4:25:62:
        41:79:53:50:c4:3a:96:c3:9e:0e:c8:62:6d:3a:fe:9f:69:ee:
        d6:8e:7d:a8:a8:e8:e6:14:95:af:57:1c:ef:22:c6:17:19:1e:
        2f:6a:ca:c8:d9:71:d2:9a:fb:ca:fd:d4:d1:5c:c0:f1:59:04:
        a7:f2:49:4a:0a:83:eb:ea:8a:c4:67:3a:ac:ce:8d:31:17:d3:
        61:eb:a5:03:33:5f:bf:82:7c:e6:a5:f1:61:b4:2e:fc:b8:09:
        e4:8d</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font></p>
      <pre><font size="2">C:\NSS\bin>certutil -d JAR -A -n "object signer" -i JAR/cert.txt -a -t "u,u,u"
Enter Password or Pin for "NSS Certificate DB":</font></pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada</font></p>
      <pre>C:\NSS\bin>certutil -L -d JAR -n "object signer"
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1272441488 (0x4bd7ea90)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer: CN=mozdev.org root CA, O=mozdev.org
        Validity:
            Not Before: Tue Oct 15 01:40:09 2002
            Not After: Wed Jan 15 01:40:09 2003
        Subject: CN=nelsons object signing cert, O=mozdev.org
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    00:b2:98:55:fb:2a:08:60:06:8c:af:68:bf:c8:a2:
                    d7:7e:80:f3:11:fe:6d:3c:9c:50:20:d2:ad:84:7d:
                    c7:3e:ed:77:08:db:f6:82:ea:bf:98:7a:a1:00:24:
                    21:f9:3d:00:1e:5f:2d:52:31:d7:92:4b:1b:b3:c4:
                    a4:b6:65:34:64:82:ee:c1:f7:56:bc:1f:0c:fd:57:
                    0f:c8:a7:d7:63:47:7e:9e:e8:8b:9d:7f:f0:c1:79:
                    cf:d1:27:99:7c:23:16:7e:ed:fc:61:30:52:8f:b7:
                    07:49:4c:b3:ef:df:ce:d9:19:7f:7a:f1:3b:f9:82:
                    4c:e9:6c:be:47:27:c0:57:d1
                Exponent: 65537 (0x10001)
        Signed Extensions:
            Name:
                Certificate Type
            Critical:
                True
            Data: &lt;Object Signing&gt;

            Name:
                Certificate Basic Constraints
            Critical:
                True
            Data: Is not a CA.

            Name:
                Certificate Key Usage
            Critical:
                True
            Data:
                03:02:07:80

    Fingerprint (MD5):
        D4:1D:8C:D9:8F:00:B2:04:E9:80:09:98:EC:F8:42:7E
    Fingerprint (SHA1):
        DA:39:A3:EE:5E:6B:4B:0D:32:55:BF:EF:95:60:18:90:AF:D8:07:09

    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        0d:fb:97:05:5b:de:71:83:8e:6d:6e:31:ac:82:44:3f:99:24:
        95:5e:03:dc:a4:9c:28:76:d6:64:37:2a:77:7e:6c:a4:25:62:
        41:79:53:50:c4:3a:96:c3:9e:0e:c8:62:6d:3a:fe:9f:69:ee:
        d6:8e:7d:a8:a8:e8:e6:14:95:af:57:1c:ef:22:c6:17:19:1e:
        2f:6a:ca:c8:d9:71:d2:9a:fb:ca:fd:d4:d1:5c:c0:f1:59:04:
        a7:f2:49:4a:0a:83:eb:ea:8a:c4:67:3a:ac:ce:8d:31:17:d3:
        61:eb:a5:03:33:5f:bf:82:7c:e6:a5:f1:61:b4:2e:fc:b8:09:
        e4:8d
    Certificate Trust Flags:
        SSL Flags:
            User
        Email Flags:
            User
        Object Signing Flags:
            User</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Yada:</font></p>
      <pre>C:\NSS\bin&gt;signtool -d JAR -k&quot;object signer&quot; -p&quot;password_of_database&quot; -Z&quot;myapp.jar&quot; myappfiles/</pre>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2"><a name="77088"></a><font size="3"><b> 
        C</b></font></font><b><font face="Verdana, Arial, Helvetica, sans-serif" size="3">reating 
        Signed Remote Applications</font></b></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Security 
        in Mozilla's web browser is designed to meet today's advanced scripting 
        needs in a secure manner. Mozilla is a much more secure browser than past 
        Netscape 4.x and Internet Explorer releases because it has a better sense 
        of what remote scripts can and cannot do.</font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">Because of 
        Mozilla's approach toward potentially insecure applications, if you decide 
        to serve up your own application remotely, remember that you will not 
        have automatic access to the chrome in the way you do when you have a 
        registered, locally installed Mozilla application. Unless you sign your 
        application or have the user turn on a special preference (see <a href="#77070">"Setting 
        Up XPFE for Remote Applications</a>"), services like XPConnect will not 
        be available. </font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">In Mozilla, 
        you can bundle any number of files into a JAR archive (which, you'll recall 
        from <a href="http://books.mozdev.org/chapters/ch06.html#77063">Chapter 
        6</a>, is just a zip file with a JAR suffix) and designate the archive 
        as an object that can be signed. This designation makes it very easy to 
        produce an entire signed and secure remote Mozilla application because 
        it stores your application in a single file type that Mozilla already 
        treats as a separate package.</font></p>
      <p><font face="Verdana, Arial, Helvetica, sans-serif" size="2">This section 
        provides an overview of the signed script technology and shows you how 
        to create signed applications that live on the server but take full advantage 
        of the user's local chrome, including Mozilla components.</font> </p>
      <pre>



Since you're telling readers how to be a CA, there are lots of important<br>things about being a reasonably good CA that should be explained.  Here <br>are a few:</pre>
      <p>1. A good CA will NEVER issue two certs with the same serial number and<br>
        issuer name. Put another way, a good CA will NEVER issue a cert with a 
        <br>
        serial number that has been previously put into another of that CA's <br>
        certs. </p>
      <p>To do that properly, the CA really should control the serial numbers 
        in<br>
        the certs, rather than letting certutil generate the serial number <br>
        automatically. That is done with the -m option. E.g. to make a cert be<br>
        serial number 1,000,001, you'd add &quot;-m 1000001&quot; (without the 
        quotes) to <br>
        the certutil -S or certutil -C command line.</p>
      <p>Most people who want to be a CA decide at some point to start over and 
        <br>
        reissue all certs, starting with their root CA cert, and they start<br>
        their serial numbers over too. Most of them make the root CA be <br>
        serial number zero or 1, and when they remake the cert, that use that<br>
        same serial number over again. That is a BIG mistake. </p>
      <p>Another common mistake is this. A person reformats his hard drive, or 
      </p>
      <p>buys a new drive when the old one crashed. So he starts his CA over<br>
        from scratch and starts with serial number 1 or 0 again. </p>
      <p>I suggest starting your serial numbers with, say 10,000 at first, and 
        <br>
        then, if you ever need to start over for some reason, start with 20,000<br>
        the second time, 30,000 the third time, and so on. Keep written records 
        <br>
        of the serial numbers, or use a script of some kind that records the <br>
        numbers in a file. </p>
      <p>2. A good CA will not issue a cert with the same subject name as the 
        subject<br>
        name in an existing one of his CA certs. The CN= value should be different 
        <br>
        in each one. The only exception is when reissuing a CA cert because the 
        old <br>
        one expired. Then the new cert can have the same name as the old one, 
        <br>
        provided that the two certs' validity periods do not overlap, or that 
        the<br>
        two certs' public keys are the the same.</p>
      <p>3. A good CA will attempt to ensure that the person to whom the cert 
        is <br>
        being issued is the person named in the cert itself. This is really the<br>
        chief value of a CA. Without the assurance that the CA has verified the 
        <br>
        cert owner's identity, the user who downloads some signed code doesn't<br>
        really know who it came from. </p>
      <p>When a user downloads your root CA cert and trusts it, he's really <br>
        trusting you equally with Verisign, Thawte, and the other commercial CAs.<br>
        He's trusting that you will never issue, say, a cert that claims to <br>
        have come from Netscape or Microsoft but didn't really. A CA that issues<br>
        dishonest certs is a &quot;rogue CA&quot;. A user who trusts even one 
        rogue CA <br>
        has lost most of the security that he would otherwise get from encryption,<br>
        because he never knows if he's really communicating with (and downloading<br>
        a program from) the party named in the cert, or some attacker who is <br>
        masquerading as the named party with help from the rogue CA. </p>
      <p>This is why it is VERY bad practice to download and trust CA certs from 
        <br>
        relatively unknown CAs, whose trustworthyness is also relatively unknown.</p>
      <p>The security of https, SSL, Secure MIME email, etc. is based on trust 
        in<br>
        a relatively small number of CAs. If end users widely begin to practice<br>
        downloading and trusting CA certs from unknown entities, just so they 
        can <br>
        run some new java or javascript application, then rogue CAs will flourish<br>
        and people's trust in https, SSL, Secure email, etc. will diminish, <br>
        killing e-commerce. </p>
      <p>So, you see, being a CA is about a lot more than collecting a few hundred<br>
        bucks for a cert. It's about developing and keeping the public's trust.<br>
        It's about doing the work to verify the identity of the people to whom 
        <br>
        you issue certs, and never issuing rogue certs. </p>
      <p>4. A good CA will put (or require) something in the subject name of each 
        <br>
        cert he issues that identifies the cert as coming from his CA, so that 
        it<br>
        cannot be easily mistaken for a cert from another CA. Likewise, a good<br>
        CA will not issue certs that look like they could have come from another<br>
        CA. </p>
      <p>In your case, simply making sure that each cert's subject name contains<br>
        O=mozdev.org is enough, I think.</p>
      <p>5. As I mentioned in an earlier email (I think), a good CA doesn't issue<br>
        certs that expire later than the expiration date of the CA's own cert. 
        <br>
        So, if the CA's own cert was made with -v 96, then for the first month,<br>
        any certs issued by that CA should be made with -v 95, and in the <br>
        second month any certs should be issued with -v 94, and so on.</p>
      <p>6. A cert must be valid on the date that it is used to create a signature.<br>
        However, with Netscape/Mozilla programs, the signature does not become<br>
        invalid when the signer's cert expires. When verifying a signature, the<br>
        question is &quot;was the signer's cert (and the signer's issuer's cert) 
        valid<br>
        when the signature was created?&quot;, not &quot;are those certs valid 
        now?&quot;. </p>
      <p>7. A good CA has a way of revoking certs when needed. A good CA maintains<br>
        a document called a &quot;Certificate Revocation List&quot; or CRL, that 
        lists the<br>
        serial numbers of the certs he has revoked. A good CA makes that CRL <br>
        available for download from his web site or another CRL server specifically<br>
        designated. A good CA puts extensions in all his certificates that tell<br>
        any user where/how to get the latest CRL from that CA. However, this is 
        <br>
        presently beyond the capability of the certutil program.</p>
    </td>
  </tr>
</table>
</body>
</html>

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>