2011/8/2 Howard Chu hyc@symas.com:
David Hawes wrote:
[...]
What is gained is that the server can be explicit about what client certificates it will accept. This is useful if you want to use a separate CA for client auth and do not want to accept certs from the CA that signed the server's cert.
Suppose my server has a Verisign cert. If I add the Verisign CA chain to TLSCACertificateFile, I have just allowed all certs signed by any CA in that chain to do TLS client auth. If I want to allow clients signed by my own CA and not those signed by Verisign, I'm out of luck.
Again, Apache does this by having separate directives for assembling the certificate chain and specifying which CAs to trust for clients.
Irrelevant. You're taking a mechanism designed for authentication and trying to use it for authorization, which is clearly a misuse of the technology.
Who's talking about authorization? Here, the pointed problem is that you cannot have a CA used to prove the server's identity to clients, and a different CA so that clients can prove their identity. In your scheme, all the CAs are of equal value/trust.
The clients trust a set of CAs, your server needs to have a certificate signed by one of them. If your server accepts clients authenticated by a CA, they have to get a certificate delivered by that CA. Who decided that the CA used to identify the server must be the very same CA used to identify the clients?
A certificate is merely an assertion that an entity is the user they claim to be, nothing more. If you trust a given CA to issue certs at all, then you must trust users presenting certs issued by that CA are who they claim to be. That says nothing about whether they have any privileges on a system, only that their identity has been proven.
Again, nowhere in the message you're replying to is mentioned "authorization". Everything we're talking about is authentication. I can have a server identified by a Comodo/VeriSign/GoDaddy certificate, while in the same time accept only clients authenticated by my own CA. The X.509 model doesn't prevent this. Your construction does. And as a side effect, even if I use the same CA for both uses, OpenLDAP will send the root CA to clients in the TLS negociation phase, and this is absolutely useless (some milliseconds lost for each TLS (re)negociation).