Re: [gtk-vnc-devel] PATCH: Support for x509 credentials

["Daniel P. Berrange" <berrange redhat com>]

On Tue, Jul 31, 2007 at 08:42:03PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >When authenticating with TLS+x509, the GTK Widget needs 1-to-4 files
> >
> >  - A CA certificate (compulsory)
> >  - A CA revocation list (optional)
> >  - A client certificate (compulsory IFF the server does client 
> >  verification)
> >  - A client key (compulsory IFF the server does client verification)
> >
> >For the latter two case, the client has no way of knowing if it needs to
> >provde them or not. The server, may or may not be doing client certificate
> >validation, and it may or may not fail auth if it does. So, if the client
> >has its own cert & key it should use them, if it doesn't then it may get
> >a auth rejection from the server later.
> >
> >This is all a little complex and not nice to expose to application 
> >developers really. So I think I want to provide a simplified interface
> >to apps. For this purposes I am introducing a single credential type.
> >It is called 'VNC_CREDENTIAL_CLIENTNAME'.  The application should set
> >this to its short logical name - eg, 'gvncviewer'. When this is set the
> >vncdisplay class will lookup the certificate data in the following
> >locations
> >
> >  - A CA certificate in:
> >
> >     $HOME/.pki/CA/cacert.pem
> >     /etc/pki/CA/cacert.pem
> >
> >  - A CA revocation list in:
> >
> >     $HOME/.pki/CA/cacrl.pem
> >     /etc/pki/CA/cacrl.pem
> >
> >  - A client key in
> >
> >     $HOME/.pki/<CLIENTNAME>/private/clientkey.pem
> >     /etc/pki/<CLIENTNAME>/private/clientkey.pem
> >
> >  - A client certificate in
> >
> >     $HOME/.pki/<CLIENTNAME>/clientcert.pem
> >     /etc/pki/<CLIENTNAME>/clientcert.pem
> >
> >In the future I'll probably also make it look for
> >
> >     $HOME/.pki/<CLIENTNAME>/clientcert-[hostname].pem
> >     /etc/pki/<CLIENTNAME>/clientcert-[hostname].pem
> >     $HOME/.pki/<CLIENTNAME>/clientcert-[domainname].pem
> >     /etc/pki/<CLIENTNAME>/clientcert-[domainname].pem
> >
> >To allow it to give different certs based on the server it is connecting
> >to. For now though the code is assuming all a user's server are under
> >the same CA realm.
> >  
> 
> I agree with you that it would be better not to expose all the gory 
> details of this.  Is this is how other applications deal with this?  My 
> only experience with TLS required that the user supplied locations of 
> the certificates (with a single default location).  I'm not aware of how 
> client applications that may be run by multiple users deal with this.  
> Any ideas?

There's very few end user applications which directly use client x509 
certificates. Mostly users just need to provide one or more CA certificates.
The web browser is pretty much only app where the user may also provide
client certificates. With mozilla you simply upload the certificate into
one of its many config dialog boxes.

The scheme I described above is modelled on the naming that libvirt uses
at the moment for locating certificates, except libvirt currently does
not provide a way to change the <CLIENTNAME> bit, simply defaulting to
'libvirt' (eg /etc/pki/libvirt/clientcert.pem). In the context of using
GTK-VNC in virt-manager, I was expecting that a common scenario is that
the libvirt daemon, and the VNC server would be configured to use the
same CA & server certificate. So virt-manager would have a single cert
usable for both the libvirt API & the VNC viewer. In this scenario when
using GTK-VNC, virt-manager would set the CLIENTNAME to 'libvirt' too.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|