> From: Dr S N Henson [mailto:[EMAIL PROTECTED]]
> That kind of thing has been done in the past but I've never liked it.
> What we should really be doing is only storing the public key
> components
> in the bignum structure and having separate information which
> contains a
> reference to the private key (engine name, key name and application
> specific information) which is then handled transparently by the
> appropriate routine.
>
I totally agree, I was just trying to modify as few as possible the data
structures.
> > - 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.
> >
>
> I've been toying with the idea of something like that. We could have a
> specific PEM format for hardware private keys. This might include the
> public key components, engine name, key name and any additional engine
> specific data. Then PEM_*_PrivateKey() should be able to handle it
> largely transparently and applications should be able to use the keys
> even if they aren't ENGINE aware.
>
That's the goal !
Cheers
Corinne Dive-Reclus, Principal Software Engineer
Baltimore Technologies, Focus 31, West Wing,Cleveland Road, Hemel Hempstead,
Hertfordshire, HP2 7BW, England
Tel: +44 (0) 1442 342600 Fax: +44 (0) 1442 347399
E-mail [EMAIL PROTECTED]
Website <http://www.baltimore.com/>
Baltimore - Global e-Security
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorised use, disclosure, copying or alteration of this message is
strictly forbidden. This message and any attachments have been scanned for
viruses. Baltimore Technologies plc will not be liable for direct, special,
indirect or consequential damages arising from alteration of the contents of
this message by a third party or as a result of any virus being passed on.
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there 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 the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote 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]
