Two Certificate Managers?

[Marc Mutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 19 April 2002 23:25, George Staikos wrote:
<snip>
>     Well as Waldo said, if this isn't a KDE project then why is it in KDE?
> Third party packages can be added to KDE systems, and they can do whatever
> they want I guess.

See my reply to his mail.

> > It is, however the accelarator that could bring KDE to thousands of
> > offices in Germany. Since without Sphinx compatibility, it will be hard
> > for a desktop to get on official desks in Germany.
>
>      Well why not provide a proper solution for the first impression these
> people will have?  The first impression is the most important one.   For
> quite some time I have wanted to bring Linux to my provincial government as
> a cost saving measure.  I certainly would not want to show them such
> inconsistencies.

The first impression is important, yes. Therefore, the certmanager and the 
configuration of the cryptographic functions of KMail has to adhere to the 
Sphinx specs.
The Aegypten team and other KDE developers might come up with a more 
consistent solution over time, but the tight schedule of the Aegypten project 
either didn't permit reworking the orginal certmanager or the orginal 
certmanager developers were too silent. Where protest against Aegypten was 
raised (e.g. keeping kpgp, using kioslaves for LDAP access, amending 
Kaddressbook instead of hacking it directly into KMail), there was generally 
a solution found that benfitted both sides. Apart from the KSSL issue (which 
- - as explained - couldn't be used since it's based on OpenSSL), I know of no 
conflict that wasn't resolved "peacefully".

> > And yes, Werner _has_ written a replacement. And yes, with luck (and
> > external help maybe), we'll see this as libgcrypt soon. Hopefully you can
> > then use this as a replacement for openSSL.
>
>    A better library would be great.  I'm not necessarily ever going to
> change KDE to use such a thing though.  I took on this project because
> no-one else would.  In any case, I think a new library has very much
> maturing to do before it can be useful.  Mozilla had problems with
> incompatibility in the crypto layer for a while wherease OpenSSL does not. 
> This is because OpenSSL has a long history of bug fixes in it for
> incompatible SSL implementations, just as you claim S/MIME has.

You shouldn't be concerned about the quality of the S/MIME functionality. It 
will be _extensively_ tested by contractors of the BSI once finished. The 
important part of this testing will be interop tests with a dozen or so other 
implementations.

What comes out of this re: SSL remains to be seen, though.

> > >    Yes, now you're calling this thing a hack instead of a proper
> > > implementation.
> >
> > If a bunch of senior software engineers, paid to work four hours a day
> > each (orsomething like that) on KMail/Aegypten do a certmanager, it's
> > surely no hack. It may be designed to be a temporary solution, but I
> > wouldn't call it a hack (and I didn't!).
>
>    Well it's not using the proper methods when working in a KDE
> environment. Are you saying that it's not a hack because they're "senior
> software engineers"?  or because they were paid to work on it?

Because I trust Kalle to employ only very good programmers, and because their 
stuff needs to get through the test lab of BSI. Failing these tests will be a 
debacle for both the BSI and possible future investments of the German 
authorities into Free Software. You can believe me: Everyone working on 
Aegytpen is _very_ well aware of this.

<snip>
>     As I said above, this is not the way to impress people.  It is
> inconsistent.  One of the things KDE prides itself on is consistency.
>
>    Now what if I have some time to finish working on S/MIME using KSSL
> entirely?  Am I then allowed to integrate this into KMail - a facility that
> uses KDE standard interfaces and facilities?  What happens to this Aegypten
> project.  Surely this will be very confusing to have two different
> implementations of S/MIME.  Possibly even conflicting.  What does the
> German gov't say then?  The code they contracted to have written has a
> chance of being removed.  Or there are two other options - we don't allow a
> KDE core developer to integrate code from the KDE libraries into a KDE CVS
> application in favour of an external non-standard implementation.  Or
> option 2, we make KMail even more inconsistent by having two
> implementations of the exact same code, with different backends for
> storage.

One could argue that for EMail encryption GnuPG is the de-facto standard on 
Unix. Even Kmail uses it and up to now nobody complained that we called 
pgp/gnupg instead of writing our own control center module for OpenPGP key 
management. Now suddenly, this should change for S/MIME, which is just an 
ugly disguise of OpenPGP with the only difference that S/MIME demands a 
hierarchical trust network where OpenPGP allows a web-of-trust? Wouldn't it 
be logical to put support for it into _GnuPG_? I'd very much believe so.

Nobody said we shouldn't use GnuPG/PGP to manage our OpenPGP keys. Nobody 
bashed Geheimnis since it duplicates the Certmanagers work.

Re: consistency. I guess a cryptography layman'd probably find it puzzling to 
find her email certificates next to HTTP certificates. I don't think my girl 
friend would draw the connection between GnuPG where she has her software 
secret s/mime key for EMail encryption and the random SSL server on the 
internet, just because OpenSSL happens to do both.

I also assert that a s/mime solution based on KSSL/OpenSSL would be just as 
inconsistent for the KMail users, since they'd expect GnuPG to do it, just as 
it does their OpenPGP keys for private communication.

<snip>
> > >    I think Dr. S. Henson and the rest of the OpenSSL developers
> > > certainly have a reputation too.
> >
> > That's not the point. I detailed above why OpenSSL isn't an option. And
> > hey, this project might make all the difference between being forced to
> > work with OpenSSL or having alternatives.
>
>    Well then what was the point?
<snip>

The point is that OpenSSL is not an option. So it's pointless to cite the 
reputation of the OpenSSL developers.

> > We had three addressbooks in KDE2. I think we can survive two certificate
> > managers until a brave soul is found that merges them.
>
>    That kind of thing is not supposed to happen.  I pointed out the
> certificate problem at the beginning of the project.  It didn't have to
> happen.

I don't know what happened back then, but as I said, the other conflicts were 
resolved, so I suspect that there was a communication problem.

Marc

- -- 
Marc Mutz <mutz at kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8wSPw3oWD+L2/6DgRAj/5AJwMtFrWBj4ZeDwODimFfA6eTt/CqgCeIFln
6KYi28pnZsZoervS5GcV580=
=za7t
-----END PGP SIGNATURE-----