Re: [mosquitto-dev] Accepting connection based on client's certificate

[Greg Troxel <gdt@xxxxxxxxxx>]

Jan Lukavský <je.ik@xxxxxxxxx> writes:

> Actually, all of this is applicable only to cases, where CA's private
> key is compromised.
>
>> Actually there is only one sound option, which is to revoke the CA 
>> certificate.
>
> Yes, that is what I meant by revoking client certificates, I was meant
> to say "revoke client certificates along with the CA".

But if you revoke the CA certificate, you don't need to revoke the
client's certs.   And there could be false client certs, so anything
that relies on the real CA doing revocations is unsound.

>> There is also the situation where the CA's private key is compromised
>> but you don't know that.
>
> This is actually another supporting argument, because if certificates
> are checked as being generated by CA, then when there appears a
> certificate that is not, then it actually implies that private key of
> CA was compromised. Moreover, with the check, there is no harm the
> attacker could do, by the attempt to connect with unknown (but valid)
> client certificate he would just bring attention to the fact of
> compromised CA.

It seems like you do not believe in the entire concept of a CA
functioning properly.   I wonder why you are using a CA in the first
place :-)

>> Sort of, but what you're really saying is that you are no longer
>> using a CA, but instead are placing certificates directly in the
>> configured trust anchor set.
>
> Generally I understand your point. What I want to say is that - if I
> have a way to add additional layer of "security" (and I'm emphasizing
> the quotes, I'm aware that has nothing to do with true security) -
> then I can somehow relax the strict requirements of CA private key
> security. I can now afford to trust "somehow" less the CA. And when I
> detect breach I can react and restore full security without disrupting
> the service.

It's good you realize that the quoted words are a sign of fuzzy
thinking.  But seriously, dealing with compromise and revocation is
truly difficult.

> I think this requirement arises naturally in environments where
> authentication is ensured using client certificates and update of
> these certificates is costly or even nearly impossible (which is the
> worst case, but possible!).

Perhaps you should have each device have a self-signed certificate, and
then have a configuration management system to have relying parties have
those specific certificates configured as acceptable.  That's almost
like a CA, except with the plus thatt the client doesn't have to obtain
a certificate signed by the CA and the minus that each relying party has
to obtain the list of certificates.