API changes for client cert auth
lucas.fisher at gmail.com
Wed Feb 9 22:38:36 EST 2011
I'm going to need to make some purple API changes in order to enable client
certificate authentication. We now have private keys that we need to manage and
protect. I see three general strategies on how to do this:
1. Have the x509 scheme include the private key in PurpleCertificate.
The key would be another field in the x509 scheme's private data. Certificates
that don't have an assoicated key would just set this field to null.
This allows resuse of much of the existing certificate code, but some of the
existing API is inadequate. First the private keys must be protected on disk
which means encrypted with a password. The existing PurpleCertificateScheme and
PurpleCertificatePool offer no means of specifying a password when
importing/exporting or getting/putting a certificate with a key. New
functions would need to be added to both APIs to allow passing of a password.
This can probably be done by just using up some of the reserved slots in
PurpleCertificateScheme and PurpleCertificatePool.
2. Create a completely separate API for private keys.
This would replicate most of the Certificate API and tailor it for private
keys. Basically creating PurplePrivateKeyScheme and PurplePrivateKeyPool that
allow passing a password to the relevant key import/export and pool get/put
functions. The libpurple user would then be responsible for ensuring they can
correlate a certificate with a private key which should be easy if you just use
the same id. I think it would also avoid making any API changes that would
break binary compatibility, but I'm not sure of this.
I would also have to stick a PKCS12 import/export function in here somewhere
since that is how most people would have their certs and keys available
outside of libpurple.
3. Create a completely separate API for client credentials.
This would be another scheme and pool that would replicate the Certificate API
but handle both certificates and private keys. So it would be simliar to
strategy 1 but a separate API. Basically, the existing Certificate API but with
means to pass passwords. So it would be simliar to strategy 1 but a separate
API. This would probably be backed by PKCS12 files in most implmentations. It
could also eliminate the need to have a separate PKCS12 API that would be
needed in 1 & 2.
Feedback on any issues that I missed, alternative solutions, or preferences
from the project are appreciated.
More information about the Devel