Policy-Discussion

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

Hi,

On 10.11.2011 18:41, Jan Dittberner wrote:
> 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.

If we drop it, client certificates with hostnames would be a must IMHO.
But still I'm not sure if we even gain anything by dropping it. I can't
think of any real attack if we keep it in. Maybe attack a server which
is not up-to-date security patch-wise and use that cert to authenticate
on a site that accepts any client cert at all. But then you could just
generate your own and the attack is not much more complicated if you
have two certs instead of one, while the implementations might get far
more complicated. What remains is the feeling that dropping the
extension might be more secure but nothing you can explicitly specify.


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

Maybe it would be more convenient but it is also quite a lot more error
prone because you have quite some amount of possible paths through the
program and a lot of parsing. Also there is some existing hardware (I
think it was a switch or gateway or something) that does not allow you
to configure what is included in the request and doesn't allow you to
export the private key which would be needed to adjust the request as it
is signed. So maybe only parsing the request for the key and having some
options explicitly specified on submission would be better (less
complicated to code as only a few well-defined variation points and more
convenient because you don't have to go through the hassle of writing an
extensive OpenSSL config file).



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

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