On 12/7/06, Joe Orton <[EMAIL PROTECTED]> wrote:
The idea with that kind of scheme is to marshal the RSA key operations
over a socket to a daemon as ssh-agent does. So you can do some
desktop-global GUI popup in your desktop-global daemon, or whatever; or
even if the pass phrase is requested over the socket too, the neon
library wouldn't have to necessarily have to maintain any process-global
state.
This is good as link as you use GUI!
But what if you use console?
ssh, svn are two examples where the daemon cannot just fork another
application to ask for password.
So the correct approach will be returning need-pin to caller so that
the original application prompt for passphrase.
(modulo any problems with how you'd actually *implement* such a scheme
as I mentioned w.r.t. the OpenSSL ENGINE thing)
I implemented the engine thing... It works correctly... But the
problem is that if you open RSA object and then the user remove/insert
the card, the passphrase should be asked again.
So I had to extend the engine with these callbacks.
> No.
> I sent you some code examples, please review them.
Those looked like plugins or applications - neon is a library, libraries
have different constraints and can make different assumptions.
I don't understand why library should be differnet.
QCA is a library, much larger than neon, we had no problems there.
The point is that there's nothing *neon* can do with this callback. It
must always be entirely specific to the application. Say that the call
to your library is:
Yes it can.
You always get back to the PKCS#11 thing.
I don't think current neon interface is correct, it does not handle
keys in expected way.
In my view you have a major design problem in multi-key multi-server
environment.
Currently you require that application match pkcs12 with remote host,
a generic library should abstract this as well.
As with every other communication library, I would have expected neon
to support keystore, something such as:
[[
ca1->cer1, cert2
ca2->cer3
]]
c = ne_create_context ();
ne_add_key (c, cer1, key1);
ne_add_key (c, cer2, key2);
ne_add_key (c, cer3, key3);
ne_register_select_callback (c, cb1, NULL);
ne_register_passphrase_callback (c, cb2, NULL);
ne_register_token_callback (c, cb3, NULL);
s = ne_opensession ("https", "localhost", 9999);
Notice that this does not match host to key, or require key passphrase.
Unlike pkcs12 usage, neon have all the information required to parse
certificate.
Now... When you open a connection to remote host, if it accept ca2,
then neon should auto select cer3/key3 and callback application for
specify passphrase for key3.
If remote accept ca1, neon should callback application to select which
certificate should be used cer1, cert2, then it should callback
application for passphrase for selected key.
The decrypted keys should be stored in global context, so that the
user should specify passphrase for key more than once.
There should be a timeout when neon should reprompt for key at key
negotiation, so that decrypting a key will not last forever.
The matching between host and certificate should be stored by
certificate DN or hash, not by matching the pkcs12 file.
I don't wish to change neon, all I want to do is to make subversion
work with smartcards.
I think your implementation missing a lot of feature required from a
dynamic communication library, only one of them is PKCS#11.
I can work with you in order to solve this, but I see you like your
current implementation.
So I guess we drop it, and I create an external patch.
but then you can see there is no value in the application calling all
these wrappers. It might as well just call pkcs11h_set_token_callback
directly itself; it is functionally equivalent, and requires less code
to be written and maintained overall.
No it isn't... These callbacks should be called for file based keys as-well.
Sorry...
Thank you for your time, I thought we could do better.
My lost.
Regards,
Alon Bar-Lev.
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon
