Re: SSL server certificate that has an intermediary certificate in the chain

[Erwann ABALEA <eabalea@gmail.com>]

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

-- 
Erwann.