On Thu, Dec 07, 2006 at 07:31:38PM +0200, Alon Bar-Lev wrote:
> 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?

As I said, or you can send the pass phrase over the socket to the 
daemon.  There would be no need for the callback to supply such a pass 
phrase to be process-global, it could be set per-session.

> >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.

Could you give a code example to help illustrate your point here?

> 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.

neon certanly supports the mode of operation where the application 
selects an appropriate client cert in a callback based on the set of 
acceptable CA DNs presented by the server: see ne_ssl_provide_clicert().  
The list of CA DNs is given to the callback which can then be compared 
against the issuer DN of any certs available using ne_ssl_dname_cmp().

neon does not expose a "cert store"-type object which makes that 
selection automatic, but that is a fairly trivial for() loop; this mode 
of operation is not *forced* on users as with some SSL toolkits, since 
it is not appropriate for all applications.

I guess I'd happily accept patches to add a "cert store" object. Can you 
explain how would that help with the PKCS#11 support, won't the issue 
with process-global callbacks remain?

Regards,

joe
_______________________________________________
neon mailing list
[email protected]
http://mailman.webdav.org/mailman/listinfo/neon

Reply via email to