Policy-Discussion

[Jan Dittberner <jandd AT cacert.org>]

On Thu, Nov 10, 2011 at 05:59:37PM +0100, Michael Tänzer wrote:
> > 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.

I don't know any software product using the same keypair/certificate
for server and client authentication. If you have some specialized
requirements you should select the proper certificate for each
purpose. There is a X509CertSelector in Java for exactly that
purpose. I assume there are similar solutions for other programming
languages/frameworks.

As long as it is not possible to opt-out from the clientAuthentication
option for server certificates I would like to drop it
entirely. Creating client certificates for a hostname instead of an
email address is useful though.
 
> > 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)

ACK

It would be great to better support CSRs containing X.509 extensions
that would mean some (or a lot more) coding to not create sub CAs or
other undesired use cases though.


Kind regards,
Jan

-- 
Jan Dittberner - CAcert Infrastructure Team
Software Architect, Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
         B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://www.dittberner.info/

Attachment: smime.p7s
Description: S/MIME cryptographic signature