On 11/27/06, Joe Orton <[EMAIL PROTECTED]> wrote:
Hi Alon,
I'm definitely interested in seeing the neon SSL API extended to be able
to handle hardware tokens. The intent is that new interfaces could be
added to support this stuff, certainly.
I am glad!
BTW: Something wrong with the list, I cannot subscribe.
How would this work at OpenSSL level? (i.e. what is the interface to
OpenSSL to do this; a callback is registered?)
pkcs11-helper can extract the X509 certificate and RSA of private key.
It registers the RSA callbacks and perform private key operations.
Something like:
certid = pkcs11h_certificate_deserializeCertificateId (string)
cert = pkcs11h_certificate_create (certid)
sess = pkcs11h_openssl_createSession (cert)
rsa = pkcs11h_openssl_getRSA (sess)
x509 = pkcs11h_openssl_getX509 (sess)
SSL_CTX_use_RSAPrivateKey (ctx, rsa)
SSL_CTX_use_certificate (ctx, x509)
> Also if you remove token and key-renegotiation time arrives, the user
> should be prompted to insert his card.
>
> Selecting the right key is based on an a serialized id, so a new
> method can be added, something like:
How would the user select such an ID? Is this something which would
specified in the application configuration?
Yes.
And if you wish to be nice to users, you can enumerate existing
certificates, I don't know how much you wish the API to be flexible...
In order to display the user a set of available certificates you need
to enumerate objects:
list = pkcs11h_certificate_enumCertificateIds ()
> ne_ssl_client_cert *ne_ssl_clicert_read_by_type(const char *type,
> const char *value);
>
> If type is "pkcs12" it will read a file, if type is "pkcs11" it will
> use key on a smartcard.
It's better to simply add a new API call for this which has the new
semantics. e.g.
ne_ssl_client_cert *ne_ssl_clicert_hwtoken(const char *id);
Well... I thought that use a generic method will ease applications,
since they need not to know which type of object they are using...
storeType=pkcs12
storeLocation=~/a.p12
-OR-
storeType=pkcs11
storeLocation=aldkjalskjdsalkjdlksajdlsadlksaj
The API can be the same... And the application can use exactly the same API.
> So basically two callbacks need to be added to neon interface:
> - token prompt callback - called when device is unavailable.
> - passphrase prompt callback - called when access to private data need
> passphrase. Can also be used for pkcs12 files.
The interface to OpenSSL requires that both of these actions are
implemented as callbacks, is that right?
Yes.
This could be done by making the ne_ssl_clicert_hwtoken() interface take
an a callback argument, maybe something like:
ne_ssl_client_cert *ne_ssl_clicert_hwtoken(const char *id,
ne_ssl_clicert_token_cb callback, void *userdata);
Would something like that make sense?
Well... The callbacks should be common to sessions... And I think you
should add such callback to PKCS#12 as well, when user should be
prompted for passphrase.
So I am thinking of something like:
ne_ssl_register_callback_token (...)
ne_ssl_register_callback_passphrase (...)
Also there should be a way to specify somekind of configuration, for
example which providers to load, provider specific parameters etc...
So I am thinking of:
ne_set_attribute (name, value);
To set generic parameters that may provided by application.
[[ I am not neon expert... Maybe you have such... ]]
Best Regards,
Alon Bar-Lev.
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon
