[foaf-protocols] CA list issue
Bruno.Harbulot at manchester.ac.uk
Sat Apr 11 17:34:26 CEST 2009
As we've discussed before, during the SSL/TLS handshake, the server
sends a list of certification authorities from which it's willing to
accept client certificates.
So far, we've been using an empty list since the client certificate is
self-signed (and the issuer name changes every time). This is explicitly
fine since TLS 1.1 and this was fine in practice before (TLS 1.0 was
silent on this, but the implementations we've used so far worked).
There is a problem with this, especially when users have other
certificates from actual CAs: having an empty list prevents the browser
from making the appropriate choice of certificate automatically.
We've talked about setting up an "open CA" (i.e. a CA for which we would
give out the private key too), but this could be mishandled, I think.
There is an easier workaround, which I've been able to use successfully
with a Java server and Apache Httpd.
What the server sends is only a list of DNs and, although it's
configured by setting up X.509 certificates both in Java's TrustManager
and in Apache Httpd's SSLCADNRequestFile, only the subject DNs of those
certificates are used. Thus, we don't need to have them match the
signature of the client certificate.
I've just tried to create a fake CA cert, used for the accepted issuers,
with subject and issuer DN: "C=FR, O=FOAFSSL, CN=Fake CA" (self-signed).
I've also used a test FOAF+SSL cert, with issuer DN "C=FR, O=FOAFSSL,
CN=Fake CA" and the FOAF+SSL URI in the subjectAltName, self-signed too,
but issuer and subject don't match.
Even if the fake CA isn't actually the issuer of the FOAF+SSL
certificate (it won't verify it since the keys are different), the
browser picks the right certificate and the server accepts it (on the
server, the trust management is still tweaked in the same way as with
the empty list).
The downside of this is that it would break a bit more our compliance
with PKIX (but we've already made a few tweaks anyway).
We'd just need to agree on a common DN for this fake CA.
More information about the foaf-protocols