Two Certificate Managers?

Sat Apr 20 22:26:14 BST 2002

I know, but I didn't follow the discussion after a certain point anymore.

> > 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.
>
>    Well it has already failed the tests of the KDE project.

"The KDE project"? And you do of course represent the KDE project...

<snip>
>  Do you even understand X.509, PKCS,
> etc?

Not as good as you do, of course. I do understand, however, that it's using 
the same cryptographic primitives as OpenPGP and differs from the latter 
essentially in two things:
1. The strictly hierarchical structure of the "trust network"
2. there are more contradicting schemas as there are implementations.

Also, I know that a good SSL interoperability doesn't guarantee a good S/MIME 
interoperability.

> > 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.
>
>    Hahaha Now that is classic.  You think that a user is going to look at
> the src code for KMail and complain that it uses kdelibs and openssl to do
> its work in the background instead of gnupg?  That's absurd!
<snip>

Thanks for trying to ridicule me.
If people want to backup their keys or if they want them be stored on a 
floppy, they'll find out surprisingly fast what backend is being used.

> > The point is that OpenSSL is not an option. So it's pointless to cite the
> > reputation of the OpenSSL developers.
>
>    Nice try.  You said that you trust the Aegypten developers 

Werner, yes.

> over any KDE
> developers for writing crypto code.

Yes.

>  I said that the crypto code in KDE is
> not written by KDE developers.

That's _currently_ right.

>  It is written by OpenSSL developers, who
> have at least as good a reputation as anyone else from what I can tell.

That's right. But since OpenSSL can't be used, there would be a need for a 
replacement backend. I remember some KDE developer talking about writing his 
own. ;-) That's what I had in mind when I wrote about reputation.

> > > > 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.
>
>   No there most certainly was not.

I can't say anything about this. I was under the impression that you had 
discussions with the Aegypten team in private mail.

>   How about this:  Konqueror will never be usable for purchasing (or
> obtaining via a CA website) an S/MIME certificate to use with KMail. 
> Konqueror will use the KDE certificate facilities, and it will store the
> certificate in the KDE database.  It will never store the certificate in a
> GPG database as long as I am maintainer.  You can write the code to extract
> it from the KDE database if you wish, but at that point, I think you have
> just proven that you can use the KDE database and so there will be no
> argument left to keep the existing code.
>
>   Now how user friendly is that?

You are angry that your work was put aside for Aegypten. I understand that. 
Yet I don't have the desire to listen to your insults any longer. It seems 
you are no longer capable of discussing things calmly. I don't need this.

I have tried to explain why GnuPG is the first and obvious choice for adding 
S/MIME support. You seem to disagree. Fine. People have differing opinions. 
That's life.

BTW: Why are we using libxml/libxslt for the doctools, anyway? If I follow 
your line of arguments, we should dump them ASAP. We should use QXml/QDom and 
write a XSLT processor based on Qt ourselves (read: "If KDE doesn't provide a 
facility, then by all means implement it.  If KDE's facility is insufficient, 
tell the developers so something can be done, contribute to the KDE facility, 
or don't ship your code with KDE").

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

iD4DBQE8wdz23oWD+L2/6DgRAnr/AKDUDus/8LvEEYqfh9rbyQqCorfxvwCY0IZf
T4Om5MIKmHUXRHKwkxsXUA==
=e0sy
-----END PGP SIGNATURE-----