Diff for /certs/www/cadraft.html between versions 1.5 and 1.6

version 1.5, 2002/10/15 01:54:38 version 1.6, 2002/10/15 02:33:27
Line 439  Certificate: Line 439  Certificate:
         provides an overview of the signed script technology and shows you how           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           to create signed applications that live on the server but take full advantage 
         of the user's local chrome, including Mozilla components.</font> </p>          of the user's local chrome, including Mozilla components.</font> </p>
      <pre>&nbsp;</pre>      <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>      </td>
   </tr>    </tr>
 </table>  </table>

Removed from v.1.5  
changed lines
  Added in v.1.6


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