Hey there,
On Thu, 15 Jun 2000, Dr Stephen Henson wrote:
> When I was discussing various methods of handling OpenSSL key databases
> the issue of PIN handling came up and in more general UI handling wrt
> "PIN like operations".
>
> The problem is that OpenSSL PIN handling is all over the place. The PEM
> stuff has PIN callbacks applicable on a per call basis even for things
> that you'd never use a PIN for. The SSL library has them per SSL and per
> SSL_CTX.
>
> In addition the PIN handling is inadequate for some tasks. An example of
> this is the nFast HWCryptoHook code currently being added. This needs an
> additional callback which doesn't ask for a PIN but asks the user to do
> something, typically "Insert Steve's Ultra Secure Card #1".
>
> Whats needed is a general and consistent way that can handle UI
> interactions like this. It would include PIN entry, PIN entry with
> confirmation, non PIN user actions and some other things.
>
> Default handling would be console based (as at present) but a GUI
> application would supply its own callbacks and typically use a dialog
> box.
>
> So, any thoughts on the matter?
The whole "***_METHOD" idea has grown on me over time - eg. I like the
fact that I can have a default method for RSA operations but pin certain
RSA keys to a different method as and where required.
I like the basic idea Richard mentioned in reply to your mail, and to boot
I'd suggest perhaps a UI_METHOD approach?! :-) Requesting passwords at the
very least is something "generic" but one might wish to override it in
specific cases - taking the ***_METHOD approach would make this easier to
do. I think this should be handled in a different layer to the ENGINE code
because applications may wish to override the "User Interaction" (rather
than "User Interface") even for specific hardware engines. Eg. if the
system on which the crypto is happening is not the system on which the
admin gets prompted for smart-cards etc - a UI_METHOD would be needed to
shove the password/PIN request across a network, or fire some bytes into
the sound card to set a battle-stations cacophony going.
Perhaps however, the UI_METHOD could be formulated independently
(./crypto/ui/) but bound into the ENGINE framework in the same way that
RSA, DSA, etc are - so that an ENGINE can if it wishes supply a UI_METHOD,
to be set as a default, eg. in a call to ENGINE_set_default(e,
ENGINE_METHOD_ALL), or just made available to be used selectively.
Just a thought.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
