[dev] Multiple S/MIME private/public keys
Jan Schneider
jan at horde.org
Fri Apr 25 11:31:11 PDT 2003
Zitat von Michael M Slusarz <slusarz at bigworm.colorado.edu>:
> Quoting Roger Håkansson <hson at ludd.luth.se>:
>
> | I'm sitting here wondering how to store multiple S/MIME private/public
> | keys.
> | Now you might wonder why you would like to do that, well if you (like
> me)
> | have saved lots of old mail(I save all mail except for mailinglists,
> | newsletters and spam) you might have some mails encrypted with one of
> | your
> | old (expired) public keys.
> | In order to be able to read those mails you need to use that old key,
> but
> | IMP can only store one key.
> |
> |
> | I've been thinking on the best way to implement the ability to store
> | multiple private(and why not public) keys
> | One way would be to do something similiar to the current
> implementation,
> | i.e. store the private/public keys in horde_prefs with "pref_name" set
> to
> | "smime_private_key_X"/"smime_public_key_X" (X being a sequence number).
> | Setting which key to use when sending mail, could be done with
> something
> | like "pref_name" "active_smime_key".
> |
> | Any comments and thoughts?
>
> This has been talked about before (generally, in connection with storing
> different PGP keys for different email addresses). If we implement this,
> we will want to tie it into Identity:: so that's a good place to start
> looking.
The only potential problem I see here is, that identities are stored
serialized in the prefs table. If we include multiple keys in the
identities, the pref value will soon exceed the column sizes for some
backends.
One possible solution would be to change the identity storage into a driver
model like for the filters recently and create an additional sql (or
whatever) backend driver besides the existing pref driver to store the
identities' values seperately.
Thoughts?
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
More information about the dev
mailing list