Policy-Discussion

[Michael Tänzer <michael.taenzer AT cacert.org>]

Hi,

On 10.11.2011 08:40, 
jcurl AT arcor.de
 wrote:
> 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)

That was also what I was preferring.


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

ACK


> 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.

As I think about it: Postfix doesn't use the client cert for
authentication right? It only establishes a normal unauthenticated
connection to the other server only making sure that the others server
cert is valid but not providing it's own. But I generally agree that
there might be use cases where one server wants to connect to another in
an both-sides-authenticated way, so keep it.


> 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.

nonRepudiation is actually reserved not for normal signatures but things
like time stamping services. If you just want to sign a document the
digitalSignature should be enough. The spec is quite fuzzy around the
use of nonRepudiation thus it's quite easy to misunderstand and the
interpretation space is huge. The presence of the flag is interpreted by
some as the signer is entering into a contract that is legally binding
but you probably don't want that flag on all certs, so either leave it
out generally or make it optional to include on request time (but that
would need some coding that probably has to wait)


> 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!

msEFS is actually included in client certs (hypothetically speaking if
we would comply to the CPS) do you think it would make sense to also
have them on server certs? If so why? The extended key usage is poorly
designed instead of just saying the application decides whether it wants
to allow if the particular usage is not specified it relies on the CA to
specify all cases. There is a fall back when no EKU is present at all
but because of the server gated crypto and some applications actually
requiring the field to be present we need to specify it. What would have
been better: let the CA specify a white and a black list and if
something is not on either of those let the application decide instead
of letting the application decide if no white list is provided and
blacklist all values not on the white list implicitly if one is
specified. But I guess we have no other choice to just deal with it.


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

ACK


Cheers,
-- 
Michael Tänzer
CAcert Support Team Leader

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature