bit
0   client - SSL client - this cert is certified for SSL client authentication use
1   server - SSL server - this cert is certified for SSL server authentication use
2   email  - S/MIME - this cert is certified for use by clients (New in PR3)
3   objsign- Object Signing - this cert is certified for signing objects such as
             Java applets and plugins (New in PR3)
4   reserved- Reserved - this bit is reserved for future use
5   sslCA  - SSL CA - this cert is certified for issuing certs for SSL use
6   emailCA- S/MIME CA - this cert is certified for issuing certs for S/MIME (New in PR3)
7   objCA  - Object Signing CA - this cert is certified for issuing certs for 
             Object Signing (New in PR3)

So: 
                               76543210
CA     = Bits 3,5,6,7 = 0xE8 = 11101000
Server = Bits 1,3     = 0x0A = 00001010
Client = Bits 0,2,3   = 0x0D = 00001101
DCA    = Bits 0,1,2,3 = 0X0F = 00001111
 
> I don't think that setting the object signing bit in CA and Server certs
make much sense. The CA never signs code directly. And why signing automatically 
(= on the fly) some objects? I'm sure you have a static bunch of objects which you 
could well sign and pack beforehand.

>Another point: Object signing gives you non-repudiation! The server certs
as it works doesn't has this functionality since they only do authentication.

nsCertType (netscape certificate type) takes the flags: 
client, server, email,objsign, reserved, sslCA, emailCA, objCA.


keyUsage
 need  digitalSignature, keyEncipherment, nonRepudiation
 maybe dataEncipherment
 not   keyAgreement