> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
> Sent: 08 February 2001 10:10
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: ENGINE_load_key
>
>
> From: Corinne Dive-Reclus <[EMAIL PROTECTED]>
>
> CDive> If I need to follow some specific procedure to add a new type
> CDive> of ENGINE hook to OpenSSL, let me know I will do it with
> CDive> pleasure.
>
> Procedure to follow is:
>
> - if you'd like to see support for your hardware in OpenSSL, please
> provide us with patches or the product to play with.
As soon I have got a reasonnable hook prototype, I will do. I can
provide to you either a hardware simulator you can run on Solaris, HP-UX (
even on WinNT) or a real hardware. When I will be at this stage I will check
with my company what the policy is and what they prefer.
> - if you're in the states and send us any code, make sure you cc:
> those messages to [EMAIL PROTECTED] See http://www.crypto.com/.
Baltimore is an Irish company and I am based in England.
>
> CDive> Anyway, any help about key generation (no ENGINE hook
> CDive> available? cannot dynamically create a key into an ENGINE ?)
> CDive> and key management will be greatly appreciated.
>
> So far, we've extended the collection of engine hooks when there's
> been more things it could support on the hardware we've been playing
> with. Since the engines play with hidden data, extending with new
> hooks isn't too difficult. Perhaps it's time to check what we really
> should support in an engine and write it a little bit more in stone.
> Ideas?
So far, the current ENGINE seems good to me. Your choice to hook
only asymmetric operations seems reasonnable for a SSL implementation.
Symmetric keys are only session keys and today do not need the same level of
protection. Even if the hardware is capable of symmetric operations, it is
probably to slow to go down to it to perform the operation. The other choice
you've made to hook either the crypto mechanism (rsa_sign, rsa_priv_dec) or
the math operation ( rsa_modexp) allows the flexibility to talk to different
types of hardware from "clever" engine to "pure math" one.
I am still too new in OpenSSL to know what key management features
are implemented so perhaps the following remarks are irrelevant and in this
case, let me know:
- A hardware can contain more than 1 key pair (ours can
contain several hundreds and can be accessed by several Crypto Applications
simultaneously).
- At key pair generation, the engine can be called and
return a "key name". If flags contains RSA_FLAG_EXT_PKEY, bignum will point
to a null-terminated string rather than a bignum array.
- When the key is serialised and saved
(PEM_write_bio_RSAPrivateKey() ?), we can decide not to encrypt it and
serialise just the key name.
- When a private key is to be used, the application reads it
(PEM_read_bio_RSAPrivateKey() ?) and a rsa_st is rebuilt from it. This
structure is passed as it is to the ENGINE rsa operation, the engine will
use the name into rsa_st to identify the key to use into the hardware.
- Perhaps the key name should identify the ENGINE itself
like "ENGINE id | key name". Like that by name introspection an application
can know what key is where.
- load_private_key won't be necessary except if we want to
use a key not generated by OpenSSL and already into the hardware. It would
be greate too if this file format is the same as
PEM_write_bio_RSAPrivateKey, like that the key can used later as generated
from OpenSSL ( i.e. probably very useful for read-only devices like
smartcards for SSL clients).
- we can provide too a RSA/DSA_delete_private_key.
In fact, if my understanding is correct that seems to fit quite well
your framework and will be happy to contribute to it.
Regards
>
> --
> Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
> Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
> Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
> Member of the OpenSSL development team: http://www.openssl.org/
> Software Engineer, Celo Communications: http://www.celocom.com/
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
>
>
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intendedf
or the addressee(s) only. If you have received this message in error ort
here are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of thec
ontents of this message by a third party or as a result of any virus beingp
assed on.
In addition, certain Marketing collateral may be added from time to time top
romote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
