Various design questions
Sat Oct 20 21:03:01 2001
On Saturday 20 October 2001 07:53, Werner Koch wrote:
> [off-list ?]
Ooops. Your mailing list doesn't put itself in the reply-to :) I assumed
> I am thinking about a general key (certicate) storage facility which
> can be used by gpg, gpgsm, browsers and whatever needs authentication
> or encryption. There are more and more protocols which allow for
> OpenPGP in addition to the standard X.509 based protocol and there are
> also a couple of other authentication systems. Providing a common
> storage for all this data seems to be a Good Thing.
Certainly. I have always wanted to merge the KDE PGP stuff with KSSL too.
It makes sense.
> The first step towards this will be the use of one keybox file for PGP
> keys and X.509 certs in Aegypten. This keybox is a simple
> datastructure of meta data and the protocol dependenf data (key/cert),
> it will eventually replace the use of keyrings in GnuPG.
> Having a control-center and import and export tools are obvious needs
> as the keybox is just a storage backend. According to our workplan we
> have to write a library to access this keybox.
> We will see in the next weeks what we can really implement.
My point is that I have already implemented this (for the X.509 stuff) in
KDE. We have to have a KDE specific GUI and backend for this due to SSL and
codesigning requirements. We don't want to have to link GPG _and_ OpenSSL
into all our applications which have crypto support. (infact we already
dlopen() OpenSSL when only absolutely required due to overhead) In fact, it
may be that some people want certificate support and don't want to have GPG
installed at all. As I mentioned in the previous mail, one possible solution
is to merge the databases at runtime. It's easy to strip out duplicates but
it's hard to know what to do at import time.