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

[Anthony Liguori <anthony codemonkey ws>]

Daniel P. Berrange wrote:
> 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.
>   

That seems pretty reasonable then.

Regards,

Anthony Liguori

> Dan.
>