From: Corinne Dive-Reclus <[EMAIL PROTECTED]>
CDive> >From Richard Levitte - VMS Whacker [[EMAIL PROTECTED]]
CDive>
CDive> > For SSL, that's true. However, there might be uses for symmetric
CDive> > algorithm acceleration or even key management in other situations.
CDive>
CDive> Alright, I though openSSL was SSL dedicated.
That's a common mistake, and it's partly to blame on the name.
However, you're right as well, SSL/TLS is one of the focuses.
Actually, OpenSSL can be viewed as an SSL/TLS implementation that also
exposes it's crypto algorithms and methods, or as a crypto library
that includes SSL/TLS functionality. Take your pick, both views are
correct :-).
CDive> We already expose some symmetric algorithms too so it would be
CDive> nice to get it.
I agree.
CDive> OK, I can use rsa.ex_data but that does not solve the key
CDive> generation point or do I miss the point again and load key is
CDive> expected to generate a new pair?
Currently, then ENGINE implementation does not support key
generation. Period. All it supports is loading already existing
keys. This is true for both public and private keys. The key pairs
are supposed to be generated in some other way, with software that
comes (it usually does :-)) with the hardware, from the hardware
vendor. Basically, the ENGINE implementation is currently designed to
use whatever there is in the hardware (or protected by it), not to
generate it, in any kind of way. I'm not sure if there are other
reasons than "because that's how CHIL works", since that's what I used
when implemented the key manamegent code for ENGINE. I see no problem
with extending that to being able to generate keys, support symmetric
algorithms and key management, and more.
CDive> CDive> - load_private_key won't be necessary except if we
CDive> CDive> want to use a key not generated by OpenSSL and already into the
CDive> CDive> hardware. It would be greate too if this file format is the
CDive> CDive> same as PEM_write_bio_RSAPrivateKey, like that the key can used
CDive> CDive> later as generated from OpenSSL ( i.e. probably very useful for
CDive> CDive> read-only devices like smartcards for SSL clients).
CDive> >I really see no need for that. What would you do with that PEM file?
CDive> >Transport it to some other computer, where it would instantly become
CDive> > unusable?
CDive>
CDive> Well why? Our hardware is on the network and can be accessed by
CDive> several computers at the same time.
OK, so the private key that is protected by that hardware is loadable
(or rather, some kind of reference to it is loadable, I hope) through
some library function. If I move that PEM file to my laptop and bring
that laptop home, to a different network than your hardware is on,
wouldn't you agree that PEM file becomes quite useless?
CDive> Quite handy if you want to have a backup web server computer
CDive> for instance. Idem for a smartcard, it is quite a
CDive> transportable device !
And so is a PEM file, *independently* of the hardware.
Anyhow, what I'm describing is how it works *today*, since that's what
you seem to ask. Stephen seems to have some thoughts on how the
future might look like :-).
--
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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
