Policy-Discussion

[jcurl AT arcor.de]

Hi,

My comments so far.

Code Signing:
I would like to avoid reducing the capabilities for code signing certificates.
I believe it should be able to do everything that a normal client certificate
does. The price to pay is small and this is already the case. I would 
certainly
prefer one certificate at 4096-bit for all (Class 3 root, email signing and
code signing) and I don't produce enough software to code sign for it to be an
attack vector (yes, larger projects, teams would likely want to separate in
this case)

User Certificates:
We don't need TLS server auth here. And CAcert doesn't generate this EKU at 
the
moment.

Server Certificates:
Do we gain anything by removing TLS Client Auth? Postfix might need to connect
as well as serve. But I have less experience with server side certificates and
I currently generate my own snake-oil certs because I don't have an email for
my home network.

Key Usage:
Why not all four Key Usages?
* digitalSignature
* nonRepudiation
* keyEncipherment
* dataEncipherment
This should allow me to use it for email; place a digital signature like on
Adobe docs; tell the user I am who the certificate says (nonRepudiation); Key
exchange (keyEncipherment); encryption (dataEncipherment). I have a need for
all four.

Don't forget about EFS and Smartcard Login. Smartcard login is a cool feature
and technologies are becoming cheaper and easier to implement. Windows 8 will
implement more authentication and also make it easier for other things than
just passwords. Let's be future proof!

cRLSigning isn't needed at all as far as I can tell for normal users.

Thanks,
Jason.