From freevision@topcities.com Mon Oct 1 18:24:01 2001 From: freevision@topcities.com (freevision) Date: Mon Oct 1 17:24:01 2001 Subject: New earn opportunity Message-ID: --MWZRelatedMessage Content-Type: text/html

Greetings

I want to inform you that there is an site that you must see if you want to earn more money for using the internet. You can earn money for seeing advertisments, web pages, reading e-mail or, the real cool is that you can earn money doing nothing.

Those opportunities are listed on http://freevision.topcities.com

Click here to see it. It's real.

You also can get paid to give opinions about sites and add new sites to search engines at Hotrate

If you are interested, give it a try (click here)

I wish you all the best!

--MWZRelatedMessage Content-ID: Content-Type: IMAGE/jpg Content-Transfer-Encoding: BASE64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAJAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQADgkJCQoJDgoKDhQNCw0UFxEODhEXGxYWFxYWGxoUFxYWFxQaGh4gIiAeGikpLCwp KTs6Ojo7QEBAQEBAQEBAQAEPDQ0PEA8SDw8SFA4RDhQWERMTERYgFhYYFhYgKR4aGhoaHikl JyIiIiclLS0pKS0tOTk2OTlAQEBAQEBAQEBA/8AAEQgARwC5AwEiAAIRAQMRAf/EAJ4AAAEF AQEAAAAAAAAAAAAAAAADBAUGBwIBAQEBAQEBAAAAAAAAAAAAAAAAAQMCBBAAAgEDAgQCBwQG CAQHAAAAAQIDEQQFABIhMRMGQSJRMhSkZSYHYXGBI6GxYpIVFpFCUnKCM1OTwdGyVWNzVHSU NRcRAAECBAUDAgcBAAAAAAAAAAABESExAhJhogNjJEFREyIygaGxwWLSBBT/2gAMAwEAAhED EQA/AHs31cxkUjxNYT7o2KnzJzBp6dJ//sWM/wC3z/vprOMuKZW8HouJf+s6ufcuL7Qt+0be 5tRDHlWigZRFJudmYL1N6bjwoToC79ud4YjuIMtkzJOgq8EoAcD0ihIP9Op3WNfTO2vH7kS6 hVjBbxSmYjgpqhCqT9rEakLj6u5aUhbezggFRVnLSECv+DQGq6NZzY/Ue+yPcSxx9K2w6b3l d1JfoxqWLs1eBNOAA02yP1Yyc05iw1ogjrRGmDPIw9OxCAP06A0/RrMcV9W71bhYs1ap0q0a SAMjr9pRiwP6NWruruxcJhYMpaKt0Lp1SEliEKsrPv8ATyGgLJo1ksv1U7rr1PZreOP/AMqS n9JfVo7L79buC4awvIVhu1QyK0ddjKvA8GqQeOgLlqh/UvuTNYSayixs/QSdHLkKpYlWXxcG nPXncH1TtbG5e1xduLt4zteZ2pHX9gL62qP3T3Xe9yvbyXcMcJtwwTpbqEOR/aJ9GgNB+mOT yGTxl5cX9xJcyC4CqZGLUGxTRfRz1dNZt9OstZYbtTIZC9fbEtyVCjmzdNKKv2nTK9+reZll Ix9rDDFXyiQNI5H4FRoDVtVDu/v+1wTmytUFzkKeZSfy468t9OJP2agYfqhkpcNeyXMMUV7G Ejtnj3CrvuqxRi3qgV1WcNYWUkNxn887SWMLlRFuIkurhhu6YbmKc2bQDh+6e+s5IfZZrp/2 LJWUD/Z4/wBJ14+d78wcytdXF7ET6q3Zd0P+9Ua7P1C7hj8mMMVhaR+pbQwxlFH2llJ0/T6j ZvLtFirizs547plhdXSQ7i52buEgpz0KWzsrvmPuAGzu1WLJRruovqyKObJXl9o1btYY6P2z 3n04WNLK6AU+JjJHD8UOrX3H9Uru2v5LTDRRNHCxQzy1fewPHaFK8NCGkaquf+oWFwd3JZSp NPeRU3RxqAoLKGFXYjwPhXVas/qP3bFdRR5GxTpzOqAtHJEfMacGJpqmZ3LTZnKz5KZFjknK 7kSu0bVCD1uPIaA2fG9zQXeKtMnPE0C3aswUHeECvs8zcP1aW/mbEf6p/dOqX9O+5bi/ltu3 ZrWFra3gf80gliAa+PDiTrQfYLH/ANNF+4v/AC0BgGX/APtrz/3Ev/W2rHffTrIWuC/jSXMc sYhW4aIBlYKwDcDyNAdQ+SwuYfI3TrY3LBppCD0ZONXP7Opa6yvfeRxq4lrW49kVFj2R2zgs qigVjt+zQDfszufIYfJW9usjNYzyKk1uTVaOdu5fQRqBePddtGOG6QqP3qauPZ/YWVkycN7l bd7a0tWEu1xR3ZDuVVTnz56rSYbNmdZDY3PrglujJ6f7ugLr3t2hhcD26bnHxslwWjgkkLs2 8MdzFgxoOK+GoP6Yxq/dkBYV2Rystf7Wyn/HWodz4b+OYO4xwIWSQBomPIOp3LrJLK27l7Uy 0d81jKksBYeeNmjYEFWG5eBHHwOgO/qJHHH3hfqnImNj/eaNC36dS9t3imJ7QxlqsUdzklMs kLTKHWFRI6q9PTzA1BtjO5e6MpJdizlea6fcz7GSJa8B5m4ADUx3p2TfY2Gxks43uYIbZYbh 41JpIrMzNtHEBt2gGmRvO+c1g5slfSM2H4Fz+XGjefb5VFCaNqN7ZuZLWXITxEh1sZwrDmCw VK/p08iue85+33xMUM74qP1wITwG/dt37a+t4acdk4G+ny01peWs8EN3aTw9R43UKXWgPmHp 0BD9sWcF93BYWlwKwyzKrqfFa12/jq2fV6KOKfFpEoRFjlARQAAKp4DVWu8Ln8DkF3wTRXEL hopkRipKnysjUodPu4JO8s6Le6yVlMyhSsGyBlqD63ACvHQETLPN/Are349H2maSnhv2Qr+r V3+kFpayNf3borXEJjWNiASqtv3bfEVpqPw/aGQyvaFxD7O8N/bXbSwLKpQuGjRXTzgf2dQ1 jL3X2vdmSCCe1lcbWV4iVYfcwodATH1ZkT+YIIlRVZbdWdgKFizv63ppTUX3YgtLbDY5PVhs Y53H/iXDNK//AAGmvcV5nMpOmUy8LRtIvTjcxmNCE40Wo489Pe5VfJ4/GZm2UvFFaR2d2ygk JNASvn9G5SCNAXrtHF4/Edkm9uUU+0273F07AeZGUlUqfAL4enVE+ntoLruu0LcI7ffcOT4C Nar+mmkl7h7kyuLh7cgDTQIoVY4UJkZE5K22tQNR+Pv77HtcRWtUmuo2tpKA7wrFdyr4gnbT QElM38xd8FoeKXd4AhH+mrU3fuLXSPc3b1/gslLHLG4gMjG3nodrKTuWjekDnqf+nsOMxmYD ZOVUykitHaW7cNhP+o3IO3JRz/p0DvLvHHWj43K472tSCtbuGQkg/wBrkG0Al2/9SspaSxW+ YIvbPcNzuKyqK+tu/rU+3UX3+UPd1+UpsJiK09BijOkcR2nnMvcokNrJHEzUeZ0ZY0WvE1b9 WpPv/t/JW+emuY7eSSzdYhFKqllokaR0JUc/LoDRexY0HamNag3dHn48WOp/WZ/TrNdySXlp iJEIxcSOS7REGgDFRv8A7x1pmgIKz7iMsbzzqpjDhEihDvLvaQoqncoHGmlV7lxxiWWkojLK tWQrQOquj+anAhtLQYO3hCqJZWijcSRxM1VVg2/y8K8zpJ+2cc5jI3r00WMUbmqKqAGtfBBx 0Ai/cUi4729YQ4FxHCQpIGx9haTiK8A2lI+4YTLcJLGyRx3Ps0UijcreVPO3oG5qacR4Syit hahSYhIslCa1KqE/UNNx2xjl6QQSAQ0C+atQoVfNur/YHHnoDiDumwkacyB444kSZSw8xjkA 2sy+G5movp14O6bR5QEjkMW5EDqpYu7iT8tAv9YNHTnpdu28YykFGBMaQlgxqUjVVQH+7sB+ /Xsfb9mksUtZGeJo3BLc3jLsrN/uH7NAd2+csbqeKGESEzeq5QhQ2zqbGPg20ctJ2OWNzkb+ 02IEsyAHDVZiR5qj7P0ctJw4FoMnDcQvttYasIqsS0jI0RZgfL6rc+fhpxBgrO3vGvYy/VId FBYlVSRuo6KPQX46AYWndkL28Ut1H0GeJWeKtXWVmp0xyB4eYH0adHunDgV6pP5bS8Eb1FG6 vL0cdEvbOMdlcKySrHFEsit5gIa7DxqCaGnEa7Hb2PWVp1DiYrs3h23AdPo8D6dugEH7nsYn JnDRxFUdCR5iDv3sRyou3wJr4aSXu6zErrcRSQqpbYzD1gkkkbN9wEe7S47WxwCbd6upr1Aw Dcd27woK7vAD7Ka6k7Zx8knUJlDjfQh+QkZ3YLw9Mh0B1cZYvjrq9sED+y9Q/m1VX6QO/YVq fDXK56GOsM6s1yp27IUZldx6yxE03bfHTz+H2/sctlQ9GbqBxU1pKSzcf8Wm0uAtHmecNLHI zF0aN6GNm9cx+jf/AFtAMspj7Pu/EXFu9FVJD7NOONCFDJJ4cCG4jWZN/M/ZGReM1iWTmCN9 vOvhwPA/rGtksrC3sYjDbKVjJ3bSa+AX9Q0rPbW9zGYbiJZo25pIoZT+DcNAZdY/VZrVTTD2 6yN6zQN0gf8ADsb9eovLd85fLTEWdvFZSS+UtboDcPXw6tN/7tNaZL2L2lK+58bED+zuQf0I QNPsfgMNjONhZxQMebKo3fvHjoDPu0PpvdTypkc6phhWjpamokc14dSnFB+n7tTJ7nvB2k77 bs3qswF50W6fCfbXqer6vDV41DntuE9vnBdVuka/m0G7jJ1uXLnw0BH3GPuR3Fb2C5K8WCe3 mncCUVDI8QAXycvPpHH5y9s7fMJdytPLFJJJYFqbmRpZLWOP8JY/06sEmNWTLQ5QsQ8MMkAT hQiRkYn8NmmUna9s9zZ3BletpPNOVFKSdWX2kI/2JJQj7tARXad/lZb62tb65edltrzqlqUa SG86Cv8Agopq4ar0fas1tPHcWN+9vMizoWMaSArcTe0kUb0Np1/C8/8A95b/AONFoB5Pf7Ly OxhTq3MiNKQTtVY1IXczUbmTQCmkJcvJBdw2txAsZmSd95k8o6G2vEqODbxx0rc492v4sjbS COeONoXV13K8bENtNCCCGFQdIXmJuby5huZJ0RoYriLYsZIPXCrWpkHq7RranxQuZrVeb3Ra XwA5gyMUlvA7tGk9wiukQkDAlxuADqOIPgacdc4rKQ5KygugBG9xH1RCWBYKSRXw9GmuLwlx jXGy4SVDBBAweMijW6GNHXznmOY/TrzA4CbCgRrdmeAoqvGyEedfKHQl22jbwK8fw1aqdFq7 aoui0zjN0AvYZu1u7ia0dkiuoppIVh3gs4ipudRQGnHS38WxmwubqEIGCFjIoG5vVHPx8NRw 7af2kTtcqR7TcXJUREE+0RmFkDdQ8geeuY+1yllBbiZBLBJbM0xRnMiWhrErK0vD8NVaf53d K1SUGWHcEtDkbC4dY4LiOR3USKqsCSpAao/Bgfx03GZtzfXFsDGsVkB7VK8gXYSocUWnEceJ qKHSdng47bIS3ZIkDyvNDXdujMqqrqPNtodvOmk7nAST/wASrcAHISQypSM/ltAE218/mB6Y ry1yiaNyotStakV7qsZdkA9ky+LjjEkl3CiEsAWdRxQVccTzWnHSkl9ZQyNFLcRRyIvUdGdQ wStNxBPAV8dRsfbzreRXjTrvS5lu5Y+mSrGWPobV8/Cijnx46UyFit3l7R13qYVb2g7DseIk MsZc+UnqIpp6K+nSzSdESpVS1VqXsqdAPTkLEStCbiMSLUspYVFBvNfuU1+7XP8AFcYEMntc OxUErN1FoEb1XPHkfA6Y/wAvVvDM01YRcS3aKF84eWPpFS1abRUnlpmvaNwbKS1kvE89mlgG EJ4LG7Or/wCbxNGpqpRoQfUVPb07z6dAS13loYLRLuDbcxPKsIZGFNzP0uYB5Nz0ncZeW3mj heBd0iTOCJRtpBTfx2/tcP06UyWNe/s0teoke145GPT3KemwegXeKAkenSN9gYb2WHcVS2ij mjaEJz6xUsytuG0grUcNeep3W2XQ30/C1N8/XdOTen5nSZgyS20aQ7TdQG5Xqts2qu3cr+Vq Hza9jyk0lxNbrAokgSJ23SgA9bdtVTtoTVaaSOEnkmtprm4juHt4XgPUhqH3lfOR1Ofl10uF cXct00sbvKkCruhqUaAGjqd/ixry1PUVU0GWKe38p3fqK5PJyY9RIYepEWijDb9p3yv0wKbT y4V13/FLSNhDdSxQXRr+Q0i14Ftp8DRgteWucvjpMjbJAkoh2Sxzbim+vScSAU3JzI1xJipH ycuQ6y/m2wtRGYyabWZw+7f6W5U1vT4lpS6FUZPg33POK2uTt5YbZpnjimulDRxLIrgkgmiO KBuR5aRts3DJi58lcr0IrZplkFd/+SzISOA57eGmNv2xdxPYhr7fDj+iY4zGQCYlkRqDq0G8 OKnjy08t8FGuJucXdSdaO6eZmZV2ECZi9B5n4qTw13VToJKq56qZIsKYuz4MByl3cBUluYFg gZSzs0nGMBS35gKgDlx469OVxgjEjXUSoW2As4HmA3baHxpx+7Ta6xl7e42XG3dwjJLEY2nV CHJpwYrvp9/p+zUfkcXdw3Nvdr+dcz38VxPsjYxosUDQVou4+jj9v2alNGnUrLUyxZKXaEpg mEy2LdA63cJVkMoPUX/LBoX5+qDzOl/abf8A1U/eGoU4KGK4sreAuGiaWS6k2EJJFMWkkjLe rxkC+WtQNT2lmk/uqZnxa5vpEERd/wAo+0ye2/w/2mv5vW6PUr+1v41+/SPyN8L930aNRP8A QyN5G6NcWOIfI3wv3fR8jfC/d9GjV5O7mEcQ+Rvhfu+j5G+F+76NGnJ3cwjiHyN8L930fI3w v3fRo05O7mEcQ+Rvhfu+j5G+F+76NGnJ3cwjiHyN8L930fI3wv3fRo05O7mEcQ+Rvhfu+j5G +F+76NGnJ3cwjiHyN8L930fI3wv3fRo05O7mEcQ+Rvhfu+j5G+F+76NGnJ3cwjiHyN8L930f I3wv3fRo05O7mEcQ+Rvhfu+j5G+F+76NGnJ3cwjiHyN8L930fI3wv3fRo05O7mEcT//ZAA== --MWZRelatedMessage-- From wk@gnupg.org Tue Oct 2 12:06:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 2 11:06:01 2001 Subject: [aleph1@securityfocus.com] GPG Keys 0.2.0 Message-ID: <87bsjq2z41.fsf@alberti.gnupg.de> Hi, is anyone able to comment on this tool? Date: Mon, 1 Oct 2001 16:29:25 -0600 From: aleph1@securityfocus.com To: sectools@securityfocus.com Subject: GPG Keys 0.2.0 GPG Keys 0.2.0 by Peter Mathiasson (http://freshmeat.net/users/mathiasson/) Tuesday, September 25th 2001 08:26 Categories: Security :: Cryptography, Utilities About: GPG Keys is a GUI frontend to GPG, written with Qt 3. It makes it easy to administrate your keyring. Its keyserver support includes the ability to upload, search, and import keys. Changes: The keyserver support now includes the ability to upload keys. Minor bugfixes were made. License: GNU General Public License (GPL) URL: http://freshmeat.net/projects/gpgkeys/ -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mutz@kde.org Fri Oct 5 22:49:01 2001 From: mutz@kde.org (Marc Mutz) Date: Fri Oct 5 21:49:01 2001 Subject: [aegypten] will gpg amended with S/MIME support? Message-ID: <0GKR00K940B2BS@mail.uni-bielefeld.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Now that it can be discussed openly, I ask again: What should we KMail guys expect? Will the S/MIME stuff go into gpg (and thus gpgme), so we can get both in one go? Background: KMail is going to use gpgme in the next version for the gpg-interfacing stuff. Thus, it putting S/MIME support into gpg(me), would be cool from KMail's POV. Marc - -- I consider the terrorist attacks on September 11th to be an attack against America's ideals. If our freedoms erode because of those attacks, then the terrorists have won. -- Bruce Schneier, Crypto-Gram 09/2001 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7vg543oWD+L2/6DgRAshXAKDeMcWIchfV4QmBi3yJu6sUbmptAgCg2H25 7sJNbaHQNAMnaIN4yOuUUpE= =OkO4 -----END PGP SIGNATURE----- From jan@intevation.de Sat Oct 6 18:53:02 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Sat Oct 6 17:53:02 2001 Subject: [aegypten] will gpg amended with S/MIME support? In-Reply-To: <0GKR00K940B2BS@mail.uni-bielefeld.de> References: <0GKR00K940B2BS@mail.uni-bielefeld.de> Message-ID: <20011006175044.D20443@intevation.de> On Fri, Oct 05, 2001 at 09:48:08PM +0200, Marc Mutz wrote: > Now that it can be discussed openly, I ask again: What should we KMail > guys expect? Will the S/MIME stuff go into gpg (and thus gpgme), so we > can get both in one go? > > Background: KMail is going to use gpgme in the next version for the > gpg-interfacing stuff. Thus, it putting S/MIME support into gpg(me), > would be cool from KMail's POV. yes, the idea is to have gpgme the standard interface for mua plugins to various protocols. BTW, improved support of KMail OpenPGP along with the Sphinx-stuff is also part of the contract :-) Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From mutz@kde.org Sat Oct 6 20:33:02 2001 From: mutz@kde.org (Marc Mutz) Date: Sat Oct 6 19:33:02 2001 Subject: [aegypten] will gpg amended with S/MIME support? In-Reply-To: <20011006175044.D20443@intevation.de> References: <0GKR00K940B2BS@mail.uni-bielefeld.de> <20011006175044.D20443@intevation.de> Message-ID: <0GKS0086LONBVU@mail.uni-bielefeld.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 06 October 2001 17:50, Jan-Oliver Wagner wrote: > BTW, improved support of KMail OpenPGP along with the Sphinx-stuff > is also part of the contract :-) Does this mean Ingo Kloecker, Ian reinhard geiseri and me are out of business? I hope not! ;-) You should know that rfc3156/2015/1847was already planned for the next release... Marc - -- Silent leges inter arma -- Cicero -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7v0Af3oWD+L2/6DgRAuiTAKCOTR2tU86+R18Ort6Pyg4skhxbKACg6p2j 93mVc9anFZ8U27I7oD4fDck= =/cUz -----END PGP SIGNATURE----- From jan@intevation.de Mon Oct 8 09:28:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Mon Oct 8 08:28:01 2001 Subject: [aegypten] will gpg amended with S/MIME support? In-Reply-To: <0GKS0086LONBVU@mail.uni-bielefeld.de> References: <0GKR00K940B2BS@mail.uni-bielefeld.de> <20011006175044.D20443@intevation.de> <0GKS0086LONBVU@mail.uni-bielefeld.de> Message-ID: <20011008082557.A5165@intevation.de> On Sat, Oct 06, 2001 at 07:31:46PM +0200, Marc Mutz wrote: > On Saturday 06 October 2001 17:50, Jan-Oliver Wagner wrote: > > > BTW, improved support of KMail OpenPGP along with the Sphinx-stuff > > is also part of the contract :-) > > > Does this mean Ingo Kloecker, Ian reinhard geiseri and me are out of > business? I hope not! ;-) absolutely not! We have a couple of days to spend on this problem. If you have too, we could join to make the solution as perfect as possible :-) At least we must ensure to pass a tough test with the solutions the Ägypten project develops/supports. > You should know that rfc3156/2015/1847was already planned for the next > release... yeah, I've seen the release schedule ... Ägypten's schedule is tight but naturally not in sync with KDE's. We'll try to make the best out of the present situation. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From stef@sysdata.siemens.hu Wed Oct 10 15:10:01 2001 From: stef@sysdata.siemens.hu (Stefan Marsiske) Date: Wed Oct 10 14:10:01 2001 Subject: mutt smime support Message-ID: <20011010140822.I32479@sysdata.siemens.hu> hi guys, i've been working with elmy@acm.org on smime 4 mutt. he did the main part, i just changed a few things. but i have rewritten a few things in it. i rewrote the openssl interface. it's a few months old, and nowhere yet publicised code, but if you're interested, i would be very happy to volunteer. ciao. -- Stefan [http://web.interware.hu/stef] UPDATED:001031 gpg-key: http://web.interware.hu/stef/gpg.txt quote: "Hackers do not feel that leisure time is automatically any more meaningful than work time. The desirability of both depends on how they are realized. From the point of a view of a meaningful life, the entire work/leisure duality must be abandoned. As long as we are living our work or our leisure, we are not even truly living. Meaning cannot be found in work or leisure but has to arise out of the nature of the activity itself. Out of passion. Social value. Creativity." From wk@gnupg.org Wed Oct 10 18:11:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 10 17:11:01 2001 Subject: mutt smime support In-Reply-To: <20011010140822.I32479@sysdata.siemens.hu> (Stefan Marsiske's message of "Wed, 10 Oct 2001 14:08:22 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> Message-ID: <877ku3h6pe.fsf@alberti.gnupg.de> Hi, On Wed, 10 Oct 2001 14:08:22 +0200, Stefan Marsiske said: > i've been working with elmy@acm.org on smime 4 mutt. he did the main part, i > just changed a few things. but i have rewritten a few things in it. i rewrote > the openssl interface. it's a few months old, and nowhere yet publicised code, The problem in using OpenSSL is that it is not GPL compatible. So there is no way for us to base it on OpenSSL. We should discuss with Thomas on how to create a common MOSS interface. The currently used command line interface is somewhat limited. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From stef@sysdata.siemens.hu Wed Oct 10 18:21:01 2001 From: stef@sysdata.siemens.hu (Stefan Marsiske) Date: Wed Oct 10 17:21:01 2001 Subject: mutt smime support In-Reply-To: <877ku3h6pe.fsf@alberti.gnupg.de>; from wk@gnupg.org on Wed, Oct 10, 2001 at 05:10:05PM +0200 References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> Message-ID: <20011010171905.M32479@sysdata.siemens.hu> On Wed, Oct 10, 2001 at 05:10:05PM +0200, Werner Koch wrote: > Hi, > > On Wed, 10 Oct 2001 14:08:22 +0200, Stefan Marsiske said: > > > i've been working with elmy@acm.org on smime 4 mutt. he did the main part, i > > just changed a few things. but i have rewritten a few things in it. i rewrote > > the openssl interface. it's a few months old, and nowhere yet publicised code, > > The problem in using OpenSSL is that it is not GPL compatible. So > there is no way for us to base it on OpenSSL. ok, unterstood. > > We should discuss with Thomas on how to create a common MOSS MOSS??? > interface. The currently used command line interface is somewhat > limited. ? > > Werner > > -- > Werner Koch Omnis enim res, quae dando non deficit, dum habetur > g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. > Privacy Solutions -- Augustinus > > > _______________________________________________ > Gpa-dev mailing list > Gpa-dev@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gpa-dev ---end quoted text--- -- Stefan [http://web.interware.hu/stef] UPDATED:001031 gpg-key: http://web.interware.hu/stef/gpg.txt quote: "Hackers do not feel that leisure time is automatically any more meaningful than work time. The desirability of both depends on how they are realized. From the point of a view of a meaningful life, the entire work/leisure duality must be abandoned. As long as we are living our work or our leisure, we are not even truly living. Meaning cannot be found in work or leisure but has to arise out of the nature of the activity itself. Out of passion. Social value. Creativity." From bernhard@intevation.de Wed Oct 10 18:32:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Wed Oct 10 17:32:01 2001 Subject: mutt smime support In-Reply-To: <20011010171905.M32479@sysdata.siemens.hu> References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> Message-ID: <20011010172943.D29862@intevation.de> --pZs/OQEoSSbxGlYw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 10, 2001 at 05:19:05PM +0200, Stefan Marsiske wrote: > On Wed, Oct 10, 2001 at 05:10:05PM +0200, Werner Koch wrote: > > We should discuss with Thomas on how to create a common MOSS > > interface. The currently used command line interface is somewhat > > limited. > MOSS??? I think Werner referrs to: MIME Object Security Services (MOSS) http://src.doc.ic.ac.uk/computing/internet/rfc/rfc1848.txt But I am also not quite sure what the relation is. Is the following article good to explain the relations, Werner? http://www.tml.hut.fi/Opinnot/Tik-110.501/1995/secure-email.html | Unfortunately, MOSS is not interoperable with PGP, and it does not | provide symmetric encryption services.=20 | To create the complete chaos, S/MIME cannot interoperate with MOSS | or PGP. We have to identify articles for background information about S/MIME, OpenPGP, PGP/MIME, PEM , MOSS , X509 and so on, so we can help people gain the overview. Bernhard --=20 Professional Service around Free Software (intevation.net) = =20 The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) --pZs/OQEoSSbxGlYw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvEaWcACgkQh9ag3dpKERayeACfQ6HHiikhOjlj9/PBMV5lcMbK RWMAn3GHk5H39vxbwoZ4BsI4UbE9ypk7 =mTBx -----END PGP SIGNATURE----- --pZs/OQEoSSbxGlYw-- From wk@gnupg.org Wed Oct 10 19:19:02 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 10 18:19:02 2001 Subject: mutt smime support In-Reply-To: <20011010172943.D29862@intevation.de> (Bernhard Reiter's message of "Wed, 10 Oct 2001 17:29:43 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010172943.D29862@intevation.de> Message-ID: <87pu7vfp05.fsf@alberti.gnupg.de> On Wed, 10 Oct 2001 17:29:43 +0200, Bernhard Reiter said: >> MOSS??? > I think Werner referrs to: > MIME Object Security Services (MOSS) I mixed the rfc numbers up. What I mean was RFC 1847. This is the common framework for MIME security extensions. RFC3156 (which has superseeded rfc2015) is the PGP instance whereas the RFC2630 ff describes the S/MIME instance. > We have to identify articles for background information about > S/MIME, OpenPGP, PGP/MIME, PEM , MOSS , X509 and so on, S/MIME - RFC 2632 f OpenPGP - RFC 2440 but a soon to be replaced by draft-ietf-openpgp-rfc2440bis-03.txt PGP/MIME - RFC 3156 PEM - Obsolete (although that RFC1421 ff are still in proposed standard) MOSS - RFC 1848 X.509 - RFC 2510 f -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roessler@does-not-exist.org Wed Oct 10 19:46:04 2001 From: roessler@does-not-exist.org (Thomas Roessler) Date: Wed Oct 10 18:46:04 2001 Subject: mutt smime support In-Reply-To: <20011010171905.M32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> Message-ID: <20011010175012.C17914@sobolev.does-not-exist.org> On 2001-10-10 17:10:05 +0200, Werner Koch wrote: >The problem in using OpenSSL is that it is not GPL compatible. So >there is no way for us to base it on OpenSSL. There is no problem with calling other, OpenSSL-based command line utilities from GPLed software. Just produce a well-defined, command-line-based interface. (Oh, and also try to avoid using the GPL whereever you can. ;->) BTW, I seem to recall that there's another SSL implementation from Netscape/the Mozilla project which may also have the things you are looking for. >We should discuss with Thomas on how to create a common MOSS >interface. The currently used command line interface is somewhat >limited. I'd seriously prefer to stick with a command line interface to the cryp to back-end - it's most easily integrated in all kinds of scripts and programs, the interface can easily be made configurable, and it's most compatible to the Unix paradigm of small tools which do one thing well. On 2001-10-10 17:19:05 +0200, Stefan Marsiske wrote: >MOSS??? Basically the predecessor of S/MIME - it was an attempt to marry PEM (Privacy-Enhanced Mail) with MIME. While MOSS and PEM themselves aren't used any more, MOSS is where multipart/signed and multipart/encrypted come from. Much of the basic design paradigm for S/MIME and PGP/MIME comes from there. However, it should be noted that MOSS falls rather nicely apart into two layers: MIME handling and crypto handling. In particular, the cryptography layer does not need to know _anything_ about MIME. Thus, designing things with MIME and crypto in mind at the same time may be a bad idea for most of the software you are going to write. Just think about encrypting and signing arbitrary data which is fed through some pipe or temporary file from some other, undefined layer. This data may have been ripped out of a MIME message, and it may also have a MIME structure itself - but that's none of the crypto back-end's business. MIME handling, on the other hand, is most likely being done vastly different in different mail user agents, so sharing code to do that would be quite difficult. However, that MIME handling isn't the complex part with integrating */MIME, once you have the back-end: Getting key selection done right is. And that's another thing which is closely related to the MUA's structure, design and code. -- Thomas Roessler http://log.does-not-exist.org/ From wk@gnupg.org Wed Oct 10 20:45:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 10 19:45:01 2001 Subject: mutt smime support In-Reply-To: <20011010175012.C17914@sobolev.does-not-exist.org> (Thomas Roessler's message of "Wed, 10 Oct 2001 17:50:12 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010175012.C17914@sobolev.does-not-exist.org> Message-ID: <874rp7fl2d.fsf@alberti.gnupg.de> On Wed, 10 Oct 2001 17:50:12 +0200, Thomas Roessler said: > There is no problem with calling other, OpenSSL-based command line Correct, but you can't link to it.> utilities from GPLed software. Just produce a well-defined, > BTW, I seem to recall that there's another SSL implementation from > Netscape/the Mozilla project which may also have the things you are > looking for. I have looked at NSS but it is a huge amount of code and it somehow reminds me on Mozilla. Although that the code is very well documented and available under the GPL, it has the major drawback to rely on the Mozilla "portable" runtime. > I'd seriously prefer to stick with a command line interface to the > cryp to back-end - it's most easily integrated in all kinds of scripts There are a couple of drawbacks with the current Mutt implementation, for example it is not possible to use different secret keys because Mutt must know the passphrase in advance. The specs for Aegypten have requirements which are not easy to fulfill with the command line based interface. It will be far easier to encapsulate the code in a library and let the library handle the invocation of the backend. Switching beween OpenPGP and S/MIME is then just a matter of setting a flag so that GPGME uses gpgsm instead of gpg. And for those who prefer proprietary crypto backends, it is alsways possible to write a warpper program to emulate the commandline behaviour of gpg - mutt already does this for key listings. > On 2001-10-10 17:19:05 +0200, Stefan Marsiske wrote: > MIME handling, on the other hand, is most likely being done vastly > different in different mail user agents, so sharing code to do that > would be quite difficult. Agreed. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jas@extundo.com Wed Oct 10 20:59:01 2001 From: jas@extundo.com (Simon Josefsson) Date: Wed Oct 10 19:59:01 2001 Subject: mutt smime support In-Reply-To: <87pu7vfp05.fsf@alberti.gnupg.de> (Werner Koch's message of "Wed, 10 Oct 2001 18:17:46 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010172943.D29862@intevation.de> <87pu7vfp05.fsf@alberti.gnupg.de> Message-ID: Werner Koch writes: >> We have to identify articles for background information about >> S/MIME, OpenPGP, PGP/MIME, PEM , MOSS , X509 and so on, > > S/MIME - RFC 2632 f > OpenPGP - RFC 2440 but a soon to be replaced by > draft-ietf-openpgp-rfc2440bis-03.txt There is draft-ietf-openpgp-multsig (expired) as well, dunno if you want to support it. > MOSS - RFC 1848 I think MOSS is basicly PEM with MIME support, I doubt that anyone use it. Please correct me if I'm wrong. From jas@extundo.com Wed Oct 10 21:03:01 2001 From: jas@extundo.com (Simon Josefsson) Date: Wed Oct 10 20:03:01 2001 Subject: mutt smime support In-Reply-To: <20011010175012.C17914@sobolev.does-not-exist.org> (Thomas Roessler's message of "Wed, 10 Oct 2001 17:50:12 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010175012.C17914@sobolev.does-not-exist.org> Message-ID: Thomas Roessler writes: > BTW, I seem to recall that there's another SSL implementation from > Netscape/the Mozilla project which may also have the things you are > looking for. Yes, NSS support S/MIME as well. It is GPL. http://www.mozilla.org/projects/security/ From wk@gnupg.org Wed Oct 10 21:07:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 10 20:07:01 2001 Subject: mutt smime support In-Reply-To: (Simon Josefsson's message of "Wed, 10 Oct 2001 19:57:18 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010172943.D29862@intevation.de> <87pu7vfp05.fsf@alberti.gnupg.de> Message-ID: <87sncre5gx.fsf@alberti.gnupg.de> On Wed, 10 Oct 2001 19:57:18 +0200, Simon Josefsson said: > There is draft-ietf-openpgp-multsig (expired) as well, dunno if you > want to support it. Drafts should not be used as reference documents ;-) > I think MOSS is basicly PEM with MIME support, I doubt that anyone use > it. Please correct me if I'm wrong. Right. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From roessler@does-not-exist.org Wed Oct 10 22:32:01 2001 From: roessler@does-not-exist.org (Thomas Roessler) Date: Wed Oct 10 21:32:01 2001 Subject: mutt smime support In-Reply-To: <874rp7fl2d.fsf@alberti.gnupg.de> References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010175012.C17914@sobolev.does-not-exist.org> <874rp7fl2d.fsf@alberti.gnupg.de> Message-ID: <20011010195047.A20092@sobolev.does-not-exist.org> On 2001-10-10 19:42:50 +0200, Werner Koch wrote: >The specs for Aegypten have requirements which are not easy to >fulfill with the command line based interface. Which ones? -- Thomas Roessler http://log.does-not-exist.org/ From wk@gnupg.org Thu Oct 11 09:55:01 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 11 08:55:01 2001 Subject: mutt smime support In-Reply-To: <20011010195047.A20092@sobolev.does-not-exist.org> (Thomas Roessler's message of "Wed, 10 Oct 2001 19:50:47 +0200") References: <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010171905.M32479@sysdata.siemens.hu> <20011010140822.I32479@sysdata.siemens.hu> <877ku3h6pe.fsf@alberti.gnupg.de> <20011010175012.C17914@sobolev.does-not-exist.org> <874rp7fl2d.fsf@alberti.gnupg.de> <20011010195047.A20092@sobolev.does-not-exist.org> Message-ID: <87d73uk6qt.fsf@alberti.gnupg.de> On Wed, 10 Oct 2001 19:50:47 +0200, Thomas Roessler said: > On 2001-10-10 19:42:50 +0200, Werner Koch wrote: >> The specs for Aegypten have requirements which are not easy to >> fulfill with the command line based interface. > Which ones? Several hundred pages of SPHINX specifications. See www.bsi.de (German only). Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jas@extundo.com Thu Oct 11 23:45:05 2001 From: jas@extundo.com (Simon Josefsson) Date: Thu Oct 11 22:45:05 2001 Subject: interoperability testing? Message-ID: I'm not sure if this is the right fora, but is there any interest in interoperability testing between various S/MIME, PGP/MIME and PGP mail clients (including LDAP/DNS/HTTP key lookup etc)? I think it would be nice if any problems with the open clients (Gnus, Mutt, KMail, Mozilla, Evolution, any others?) are detected by the developers instead of end users. :) Of course, I wouldn't expect (or want) it to be anything but informal. (Please reply privately if this doesn't belong on this list.) From jan@intevation.de Fri Oct 12 10:09:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 12 09:09:01 2001 Subject: =?iso-8859-1?Q?=C4gypten?= web-site update Message-ID: <20011012090641.A8468@intevation.de> Hi, fyi: the aegypten web-site is extended by technical overview on how we plan to realize the project. I am sorry, but currently most is in German. http://www.gnupg.org/aegypten/tech.en.html Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jan@intevation.de Fri Oct 12 10:50:02 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 12 09:50:02 2001 Subject: interoperability testing? In-Reply-To: References: Message-ID: <20011012094735.A8635@intevation.de> Dear Simon, On Thu, Oct 11, 2001 at 10:43:23PM +0200, Simon Josefsson wrote: > I'm not sure if this is the right fora it is! > but is there any interest in > interoperability testing between various S/MIME, PGP/MIME and PGP mail > clients (including LDAP/DNS/HTTP key lookup etc)? I think it would be > nice if any problems with the open clients (Gnus, Mutt, KMail, > Mozilla, Evolution, any others?) are detected by the developers > instead of end users. :) Of course, I wouldn't expect (or want) it to > be anything but informal. such testing would be very helpful. It would be a small project of its own. Note that there is a test specifaction for sphinx by the bsi. Of course it refers to the sphinx project and ... it is in German :-( What would help a lot would be an overview on which MUA (which version) interoperates correctly with the others for each protocol. It would mean quite some work (some fun too) to do the testing and/or to moderate the webpage. Anyone out there? Cheers Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From Michael@Haeckel.Net Fri Oct 12 20:33:02 2001 From: Michael@Haeckel.Net (Michael =?iso-8859-1?q?H=E4ckel?=) Date: Fri Oct 12 19:33:02 2001 Subject: =?iso-8859-1?q?=C4gypten=20web-site?= update In-Reply-To: <20011012090641.A8468@intevation.de> References: <20011012090641.A8468@intevation.de> Message-ID: <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> Hi, I think in general this structure looks well, from the point of view of K= Mail,=20 besides this LDAP issue. I don't know, which KDE developer shall have spread the rumour, that Open= LDAP=20 would have a bad performance. I personally just tried to point out, that there appear design limitation= s, as=20 soon as someone tries to implement LDAP over SSL or TLS, and the TCPSlave= Base=20 class can't deal with the network socket directely like that works for al= l=20 other network protocols used in KDE. Then it would be neccessary to imple= ment=20 all SSL related GUI interactions again which would work automatically if=20 TCPSlaveBase would be used like for all other protocols. Yes, LDAP over SSL seems to be beyond the =C4gypten project, but I wonder= what a=20 reusable component is worth then, if it has a serious design limitation a= nd it=20 is already officially planned before the project is started, that it migh= t be=20 rewritten later. Also I wonder, are really all LDAP queries from KMail supposed to go thro= ugh=20 GpgME? Regards, Michael H=E4ckel From jas@extundo.com Fri Oct 12 22:09:01 2001 From: jas@extundo.com (Simon Josefsson) Date: Fri Oct 12 21:09:01 2001 Subject: =?iso-8859-1?q?=C4gypten?= web-site update In-Reply-To: <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> (Michael =?iso-8859-1?q?H=E4ckel's?= message of "Fri, 12 Oct 2001 19:33:22 +0200") References: <20011012090641.A8468@intevation.de> <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> Message-ID: Michael H=E4ckel writes: > Hi, > > I think in general this structure looks well, from the point of view > of KMail, besides this LDAP issue. [snip] For finding certificates and CRLs, DNS can also be used, in particular the CERT RR. Gnus support this scheme since a year. It seemed as if LDAP was a design requirement for you, but it may be interesting to consider DNS as well, I believe it solves alot of the practical problems present with LDAP. Some references: Cert RR spec: http://www.ietf.org/rfc/rfc2538.txt Using the CERT RR for S/MIME: http://www.ietf.org/internet-drafts/draft-josefsson-pkix-dns-00.txt Alternative approach: http://www.ietf.org/internet-drafts/draft-schlyter-appkey-00.txt How SSH use this approach for their keys: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-key-format-00.txt From chepalle2000@yahoo.it Sat Oct 13 06:52:02 2001 From: chepalle2000@yahoo.it (Ramallo) Date: Sat Oct 13 05:52:02 2001 Subject: (no subject) Message-ID: <001e01c1539a$14d8b520$d0f8623e@chepalle2000> Messaggio in formato MIME composto da più parti. ------=_NextPart_000_001B_01C153AA.D7029160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please, delete me from your list. thank you .... ------=_NextPart_000_001B_01C153AA.D7029160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

please, delete me from your = list.

thank you = ....

------=_NextPart_000_001B_01C153AA.D7029160-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From kalle@klaralvdalens-datakonsult.se Sat Oct 13 18:44:01 2001 From: kalle@klaralvdalens-datakonsult.se (Matthias Kalle Dalheimer) Date: Sat Oct 13 17:44:01 2001 Subject: CVS commit libksba/src In-Reply-To: References: Message-ID: <200110131542.f9DFgJh21557@maila.telia.com> On Friday 12 October 2001 17:57, you wrote: > Date: Friday October 12, 201 @ 17:57 Ist die Jahreszahl hier eine (oktale? tern=E4re?) Darstellung, dir ich ni= cht=20 verstehe, oder fehlt da wirklich eine 0? :-) Gru=DF, Kalle --=20 Matthias Kalle Dalheimer President & CEO Klar=E4lvdalens Datakonsult AB Platform-independent Software Solutions http://www.klaralvdalens-datakonsult.se From kalle@klaralvdalens-datakonsult.se Sat Oct 13 18:50:01 2001 From: kalle@klaralvdalens-datakonsult.se (Matthias Kalle Dalheimer) Date: Sat Oct 13 17:50:01 2001 Subject: =?iso-8859-1?q?=C4gypten=20web-site?= update In-Reply-To: <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> References: <20011012090641.A8468@intevation.de> <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> Message-ID: <200110131542.f9DFgIh21546@maila.telia.com> On Friday 12 October 2001 19:33, Michael H=E4ckel wrote: > Hi, > > I think in general this structure looks well, from the point of view of > KMail, besides this LDAP issue. > > I don't know, which KDE developer shall have spread the rumour, that > OpenLDAP would have a bad performance. > I personally just tried to point out, that there appear design limitati= ons, > as soon as someone tries to implement LDAP over SSL or TLS, and the > TCPSlaveBase class can't deal with the network socket directely like th= at > works for all other network protocols used in KDE. Then it would be > neccessary to implement all SSL related GUI interactions again which wo= uld > work automatically if TCPSlaveBase would be used like for all other > protocols. > > Yes, LDAP over SSL seems to be beyond the =C4gypten project, but I wond= er > what a reusable component is worth then, if it has a serious design > limitation and it is already officially planned before the project is > started, that it might be rewritten later. > > Also I wonder, are really all LDAP queries from KMail supposed to go > through GpgME? The LDAP functionality must be independent from the mail client used. It=20 therefore can't use e.g. KIO slaves, because it wouldn't be really=20 independent any longer (using some of the KDE libraries). Kalle --=20 Matthias Kalle Dalheimer President & CEO Klar=E4lvdalens Datakonsult AB Platform-independent Software Solutions http://www.klaralvdalens-datakonsult.se From haeckel@kde.org Sat Oct 13 18:56:01 2001 From: haeckel@kde.org (Michael =?iso-8859-1?q?H=E4ckel?=) Date: Sat Oct 13 17:56:01 2001 Subject: CVS commit libksba/src In-Reply-To: <200110131542.f9DFgJh21557@maila.telia.com> References: <200110131542.f9DFgJh21557@maila.telia.com> Message-ID: <200110131554.RAA13173@btcips73x5.cip.uni-bayreuth.de> On Saturday 13 October 2001 14:21, Matthias Kalle Dalheimer wrote: > On Friday 12 October 2001 17:57, you wrote: > > Date:=09Friday October 12, 201 @ 17:57 > > Ist die Jahreszahl hier eine (oktale? tern=E4re?) Darstellung, dir ich = nicht > verstehe, oder fehlt da wirklich eine 0? :-) Bei einem Zahlensystem mit der Basis 31,6 k=E4me man wohl etwa hin. Viele Gr=FC=DFe, Michael H=E4ckel From haeckel@kde.org Sat Oct 13 19:03:01 2001 From: haeckel@kde.org (Michael =?iso-8859-1?q?H=E4ckel?=) Date: Sat Oct 13 18:03:01 2001 Subject: =?iso-8859-1?q?=C4gypten=20web-site?= update In-Reply-To: <200110131542.f9DFgIh21546@maila.telia.com> References: <20011012090641.A8468@intevation.de> <200110121731.TAA12616@btcips73x5.cip.uni-bayreuth.de> <200110131542.f9DFgIh21546@maila.telia.com> Message-ID: <200110131601.SAA14222@btcips73x5.cip.uni-bayreuth.de> On Saturday 13 October 2001 14:18, Matthias Kalle Dalheimer wrote: > > The LDAP functionality must be independent from the mail client used. I= t > therefore can't use e.g. KIO slaves, because it wouldn't be really > independent any longer (using some of the KDE libraries). I know, we must take, what we get, but long term this means, that KDE nee= ds a=20 different LDAP implementation. Well, I made the suggestion to create a module that just translates betwe= en=20 the high level commands from the application and the low level commands o= f=20 the LDAP protocol and let the network traffic do a different module. AFAI= K=20 OpenLDAP is also able to operate on a unix socket instead of a network so= cket=20 so this would theoretically possible. Regards, Michael H=E4ckel From bh@intevation.de Sat Oct 13 19:09:02 2001 From: bh@intevation.de (Bernhard Herzog) Date: Sat Oct 13 18:09:02 2001 Subject: CVS commit libksba/src In-Reply-To: <200110131554.RAA13173@btcips73x5.cip.uni-bayreuth.de> References: <200110131542.f9DFgJh21557@maila.telia.com> <200110131554.RAA13173@btcips73x5.cip.uni-bayreuth.de> Message-ID: <6q1yk74j85.fsf@abnoba.intevation.de> Michael Häckel writes: > On Saturday 13 October 2001 14:21, Matthias Kalle Dalheimer wrote: > > On Friday 12 October 2001 17:57, you wrote: > > > Date: Friday October 12, 201 @ 17:57 > > > > Ist die Jahreszahl hier eine (oktale? ternäre?) Darstellung, dir ich nicht > > verstehe, oder fehlt da wirklich eine 0? :-) [ For the readers that don't understand German: Kalle wonders about the strange year: 201 ] > Bei einem Zahlensystem mit der Basis 31,6 käme man wohl etwa hin. [ suggests that 31.6 was used as the basis ] Well, 2 * 31.6 ** 2 + 1 is 1998.12 :) With sqrt(1000) as the basis it works. This is off-topic, though Bernhard -- Intevation GmbH http://intevation.de/ Sketch http://sketch.sourceforge.net/ MapIt! http://mapit.de/ From haeckel@kde.org Sat Oct 13 21:19:01 2001 From: haeckel@kde.org (Michael =?iso-8859-1?q?H=E4ckel?=) Date: Sat Oct 13 20:19:01 2001 Subject: CVS commit libksba/src In-Reply-To: <6q1yk74j85.fsf@abnoba.intevation.de> References: <200110131554.RAA13173@btcips73x5.cip.uni-bayreuth.de> <6q1yk74j85.fsf@abnoba.intevation.de> Message-ID: <200110131817.UAA21651@btcips73x5.cip.uni-bayreuth.de> On Saturday 13 October 2001 18:07, Bernhard Herzog wrote: > > Well, 2 * 31.6 ** 2 + 1 is 1998.12 :) > > With sqrt(1000) as the basis it works. Who said, that the commit was not in 1998? Well, or maybe it was produced by software affected by the Y1k9 bug which= =20 counts the years with two digits since 1800. Regards, Michael H=E4ckel From chepalle2000@yahoo.it Sun Oct 14 08:11:01 2001 From: chepalle2000@yahoo.it (Ramallo) Date: Sun Oct 14 07:11:01 2001 Subject: (no subject) Message-ID: <000c01c1546e$5b394460$67b6623e@chepalle2000> Messaggio in formato MIME composto da più parti. ------=_NextPart_000_0009_01C1547F.177E0880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please remove me from your list ... thanks ------=_NextPart_000_0009_01C1547F.177E0880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

please remove me from your list ...=20 thanks

------=_NextPart_000_0009_01C1547F.177E0880-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From kalle@klaralvdalens-datakonsult.se Thu Oct 18 18:20:01 2001 From: kalle@klaralvdalens-datakonsult.se (Matthias Kalle Dalheimer) Date: Thu Oct 18 17:20:01 2001 Subject: CVS commit aegypten-specs In-Reply-To: References: Message-ID: <200110181517.f9IFHrg24549@maila.telia.com> On Thursday 18 October 2001 15:41, you wrote: > Date: Thursday October 18, 2001 @ 15:41 > Author: kalle > > Update of /cvs/aegypten/aegypten-specs > In directory trithemius:/tmp/cvs-serv10458 > > Modified Files: > mua-integration.sgml > Log Message: > 6.1.1 covered > File: no file mua-integration.sgml Status: Needs Checkout Uh, what does this mean? This is not the first commit I made to this file= ?! Kalle --=20 Matthias Kalle Dalheimer President & CEO Klar=E4lvdalens Datakonsult AB Platform-independent Software Solutions http://www.klaralvdalens-datakonsult.se From jan.petranek@student.uni-tuebingen.de Fri Oct 19 13:33:01 2001 From: jan.petranek@student.uni-tuebingen.de (Jan Petranek) Date: Fri Oct 19 12:33:01 2001 Subject: =?ISO-8859-1?Q?=C4gypten_with_S=2FMIME_and_OpenPGP?= Message-ID: Hello out there, on the web site of the =C4gypten project it is mentioned, that =C4gypten = (that is, GnuPG) aims to be able to read S/MIME-formatted mails, certificates and so on as well as the OpenPGP format. As far as I know GPG, this means also support for the old PGP 2.6.x format (well, in some limited way). How far has the implementation of the S/MIME come now? Thank You, Jan Petranek From dominik@nextbyte.de Fri Oct 19 13:47:02 2001 From: dominik@nextbyte.de (Dominik Schwald) Date: Fri Oct 19 12:47:02 2001 Subject: missing feature: 'keyserver-export' feedback Message-ID: Hi, i just installed GPA and tried to export some keys on several keyservers. But even if i start GPA with ds@work:~ > gpa -v --debug-all --advanced-ui i get no feedback weather the export to the keyserver worked or not. How can i see if the export to the keyserver was succesfull? thanks, dominik From jan@intevation.de Fri Oct 19 15:04:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Fri Oct 19 14:04:01 2001 Subject: =?iso-8859-1?Q?=C4gypte?= =?iso-8859-1?Q?n?= with S/MIME and OpenPGP In-Reply-To: References: Message-ID: <20011019140205.A24679@intevation.de> Dear Jan, On Fri, Oct 19, 2001 at 12:30:59PM +0200, Jan Petranek wrote: > on the web site of the Ägypten project it is mentioned, that Ägypten (that > is, GnuPG) aims to be able to read S/MIME-formatted mails, certificates > and so on as well as the OpenPGP format. As far as I know GPG, this means > also support for the old PGP 2.6.x format (well, in some limited way). > > How far has the implementation of the S/MIME come now? the aim of the Ägypten project is to sphinx-enable free software MUAs. S/MIME is one important element. We are currently in the process to make up a detailed design on how the solution might look like. It is updated regularly at the Ägypten homepage for open discussion. We haven't coded much at this point, but it is an essential idea to review existing code and if its quality is good, tie it together with other elements. Where no code is available we of course must write it on our own unless someone likes to participate. There are already some peaces of code (eg. an S/MIME patch for mutt), but we haven't decided yet . So if you know about any existing code please let us know. More general input is also welcome. We plan to have first working code with KMail end of November 2001. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From bernhard@intevation.de Fri Oct 19 16:39:02 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Fri Oct 19 15:39:02 2001 Subject: missing feature: 'keyserver-export' feedback In-Reply-To: References: Message-ID: <20011019153704.C25808@intevation.de> --wxDdMuZNg1r63Hyj Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 19, 2001 at 12:38:07PM +0200, Dominik Schwald wrote: > i just installed GPA and tried to export some keys on several=20 > keyservers. But even if i start GPA with >=20 > ds@work:~ > gpa -v --debug-all --advanced-ui =20 Which version are you using? > i get no feedback weather the export to the keyserver worked or not.=20 > How can i see if the export to the keyserver was succesfull? It might be the case that there is no reliable way to know this. You can check the server later of course. Bernhard --=20 Gesch=E4ftsf=FChrer, Intevation GmbH (intevation.de) Projekt Freie GIS Software (freegis.org/index.de.html) FFII e.V. (ffii.org) FSF Europa (fsfeurope.org/index.de.html) --wxDdMuZNg1r63Hyj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvQLIAACgkQh9ag3dpKERbYCwCfVAH6+OAeJzuyDxI+XA+Vowuc bVIAni7P3MQyuFbwy1V67TKEr8/Unjw2 =9qLq -----END PGP SIGNATURE----- --wxDdMuZNg1r63Hyj-- From dominik@nextbyte.de Fri Oct 19 17:40:02 2001 From: dominik@nextbyte.de (Dominik Schwald) Date: Fri Oct 19 16:40:02 2001 Subject: missing feature: 'keyserver-export' feedback In-Reply-To: <20011019153704.C25808@intevation.de> References: <20011019153704.C25808@intevation.de> Message-ID: Am Freitag, 19. Oktober 2001 15:37 schrieb Bernhard Reiter: > Which version are you using? gpa 0.4.1 AFAIK thats the latest stable release... dominik From e970095@zipi.fi.upm.es Fri Oct 19 18:37:02 2001 From: e970095@zipi.fi.upm.es (Miguel Coca) Date: Fri Oct 19 17:37:02 2001 Subject: Sorting the keyring by different fields (patch) Message-ID: <20011019173549.A688@mycroft> --hHWLQfXTYDoKhP50 Content-Type: multipart/mixed; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, In the past I've noticed that, by reading mailing lists where PGP signatures are common, my keyring has been filled with lots of keys. Only a few of them are really trustworthy, and in GPA there is no easy way to find them. To solve this, I've modified GPA so that you can sort your keyring by any field you want, including key and owner trust. I attach a patch against the latest CVS (with ChangeLog entries at the beginning of the file, as suggested). Also, I'd be willing to work on improving GPA, but I don't know what to do exactly. The TODO file seems a bit out of date. I understand there would be interest in replacing gpapa with gpgme. I could try to do it, but it seems to be a major change which I would not attempt without the developers' permission and advice :-) Meanwhile, I'm working on a Spanish translation. Don't count on getting it soon, though, since there is a whole lot of strings in the program :-) Sincerely, --=20 Miguel Coca e970095@zipi.fi.upm.es PGP Key 0x27FC3CA8 http://zipi.fi.upm.es/~e970095/ --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=gpa-sort-patch Content-Transfer-Encoding: quoted-printable 2001-10-18 Miguel Coca =20 * keylist.c (keylist_clicked_on_column):=20 (keylist_compare_rows):=20 (keylist_compare_expiry):=20 (keylist_compare_ownertrust):=20 (keylist_compare_keytrust): Sort the list by a column when that column's title is clicked. (gpa_keylist_new): Added signal handler and sort function to support sorting by different columns. =20 Index: src/keylist.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/gpa/gpa/src/keylist.c,v retrieving revision 1.12 diff -r1.12 keylist.c 54c54 < /* the number and definitins of the currently visible columns */ --- > /* the number, list and definitions of the currently visible columns */ 55a56 > GPAKeyListColumn *columns; 69a71,72 > /* Name of the column used to sort the list */ > GPAKeyListColumn sort_column; 81a85,89 > static gint keylist_compare_rows (GtkCList * clist, gconstpointer ptr1, > gconstpointer ptr2); > static void keylist_clicked_on_column (GtkCList * clist, int column); > static gint keylist_compare_keytrust( GpapaKeytrust keytrust1,=20 > GpapaKeytrust keytrust2 ); 207a216,335 > /* > * Sorting > */ >=20 > static gint keytrust_order[] =3D {3,8,2,1,0,7,5,6,4}; > static gint ownertrust_order[] =3D {2,3,1,0}; >=20 > static gint keylist_compare_keytrust( GpapaKeytrust keytrust1,=20 > GpapaKeytrust keytrust2 ) > { > return keytrust_order[keytrust1] - keytrust_order[keytrust2]; > } >=20 > static gint keylist_compare_ownertrust( GpapaOwnertrust ownertrust1,=20 > GpapaOwnertrust ownertrust2 ) > { > return ownertrust_order[ownertrust1] - ownertrust_order[ownertrust2]; > } >=20 > static gint keylist_compare_expiry( GDate *expiry1, GDate *expiry2 ) > { > gint value; > if( !expiry1 && !expiry2 ) > { > value =3D 0; > } > else if( !expiry1 && expiry2 ) > { > value =3D 1; > } > else if( expiry1 && !expiry2 ) > { > value =3D -1; > } > else > { > value =3D g_date_compare( expiry1, expiry2 ); > } > return value; > } >=20 > /* Compare two rows of the list, using the current sort_column */ > gint keylist_compare_rows (GtkCList * clist, gconstpointer ptr1, > gconstpointer ptr2) > { > GPAKeyList * keylist =3D gtk_object_get_data (GTK_OBJECT (clist), > "gpa_keylist"); > GtkCListRow * row1 =3D ptr1; > GtkCListRow * row2 =3D ptr2; > gint value; > GpapaPublicKey * key1 =3D gpapa_get_public_key_by_ID ( row1->data, > gpa_callback, > keylist->window); > GpapaPublicKey * key2 =3D gpapa_get_public_key_by_ID ( row2->data, > gpa_callback, > keylist->window); > GDate *expiry1, *expiry2; > GpapaKeytrust keytrust1, keytrust2; > GpapaOwnertrust ownertrust1, ownertrust2; >=20 > switch( keylist->sort_column ) > { > case GPA_KEYLIST_EXPIRYDATE: > expiry1 =3D gpapa_key_get_expiry_date ( GPAPA_KEY (key1), gpa_callb= ack,=20 > keylist->window); > expiry2 =3D gpapa_key_get_expiry_date ( GPAPA_KEY (key2), gpa_callb= ack,=20 > keylist->window); > value =3D keylist_compare_expiry( expiry1, expiry2 ); > break; > case GPA_KEYLIST_KEYTRUST: > keytrust1 =3D gpapa_public_key_get_keytrust=20 > (key1, gpa_callback, keylist->window); > keytrust2 =3D gpapa_public_key_get_keytrust > (key2, gpa_callback, keylist->window); > value =3D keylist_compare_keytrust( keytrust1, keytrust2 ); > break; > case GPA_KEYLIST_OWNERTRUST: > ownertrust1 =3D gpapa_public_key_get_ownertrust=20 > (key1, gpa_callback, keylist->window); > ownertrust2 =3D gpapa_public_key_get_ownertrust > (key2, gpa_callback, keylist->window); > value =3D keylist_compare_ownertrust( ownertrust1, ownertrust2 ); >=20 > break; > case GPA_KEYLIST_NAME: > case GPA_KEYLIST_ID: > default: > value =3D g_strcasecmp( GTK_CELL_TEXT(row1->cell[clist->sort_column= ]) > ->text, > GTK_CELL_TEXT(row2->cell[clist->sort_column]) > ->text ); > } >=20 > return value; > } >=20 > /* If the user clicks on a column we sort the list by that column. If the > * column is the one we are using already, we sort in reverse order. */ > void keylist_clicked_on_column (GtkCList * clist, int column) > { > GPAKeyList * keylist =3D gtk_object_get_data (GTK_OBJECT (clist), > "gpa_keylist"); >=20 > if( keylist->sort_column =3D=3D keylist->columns[column] ) > { > if( GTK_CLIST(clist)->sort_type =3D=3D GTK_SORT_ASCENDING ) > gtk_clist_set_sort_type(GTK_CLIST (clist), GTK_SORT_DESCENDING); > else > gtk_clist_set_sort_type(GTK_CLIST (clist), GTK_SORT_ASCENDING); > } > else /* Always sort in ascending order when changing sort column */ > gtk_clist_set_sort_type(GTK_CLIST (clist), GTK_SORT_ASCENDING); >=20 > keylist->sort_column =3D keylist->columns[column]; > /* This is not absolutely necessary, but we tell the list which column = we > are using just in case. Note: Right now it's used by > keylist_compare_rows in the default case. */ > gtk_clist_set_sort_column (GTK_CLIST (clist), column); > gtk_clist_sort (GTK_CLIST (clist)); > } 222a351 > keylist->sort_column =3D GPA_KEYLIST_NAME; 224a354,355 > keylist->columns =3D xmalloc (ncolumns * sizeof (columns[0])); > memcpy( keylist->columns, columns , (ncolumns * sizeof (columns[0])) ); 235a367,371 > gtk_signal_connect( GTK_OBJECT (clist), "click_column", > GTK_SIGNAL_FUNC (keylist_clicked_on_column), NULL); > gtk_clist_set_compare_func( GTK_CLIST (clist),=20 > (GtkCListCompareFunc) keylist_compare_rows = ); >=20 326a463 > gtk_clist_sort (GTK_CLIST (keylist->clist)); 347c484 < =20 --- >=20 399a537 > gboolean found_sort_column =3D FALSE; 403a542,543 > keylist->columns =3D xmalloc (ncolumns * sizeof (columns[0])); > memcpy( keylist->columns, columns , (ncolumns * sizeof (columns[0])) ); 407a548,563 > } >=20 > /* Try to find the column used to sort the list in the definitions */ > for( i =3D 0; i < ncolumns; i++ ) > if( columns[i] =3D=3D keylist->sort_column ) > { > found_sort_column =3D TRUE; > gtk_clist_set_sort_column( GTK_CLIST (clist), i ); > } > /* If the old sort solumn is not found use the default (the last one, > * that usually is the user name */ > if( !found_sort_column ) > { > keylist->sort_column =3D columns[ncolumns-1]; > gtk_clist_set_sort_column( GTK_CLIST (clist), ncolumns-1 ); > gtk_clist_set_sort_type(GTK_CLIST (clist), GTK_SORT_ASCENDING); --MGYHOYXEY6WxJCY8-- --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE70EhVjE3Htif8PKgRAvk9AKDMj9Y9fOKL1nRM5i7NdYulmlfuNgCfU4py 28XxXc5+uJZTWPftXma5YjA= =ZasN -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50-- From staikos@kde.org Fri Oct 19 19:21:01 2001 From: staikos@kde.org (George Staikos) Date: Fri Oct 19 18:21:01 2001 Subject: Various design questions Message-ID: <200110191619.MAA25638@nitro.0wned.org> Hello, I haven't heard many details about this project and the last time I checked, the online docs were in German, but I do have a few questions about the design of this project. I guess we'll start off with this one: I know that you have to make this compatible with Mutt, but do you not agree that things like key management should be integrated with the KDE crypto manager? I think it would be unfortunate for users to have to import their keys in two places and manage them twice. -- George Staikos From wk@gnupg.org Fri Oct 19 19:32:01 2001 From: wk@gnupg.org (Werner Koch) Date: Fri Oct 19 18:32:01 2001 Subject: Various design questions In-Reply-To: <200110191619.MAA25638@nitro.0wned.org> (George Staikos's message of "Fri, 19 Oct 2001 12:12:00 -0400") References: <200110191619.MAA25638@nitro.0wned.org> Message-ID: <87adynoalh.fsf@alberti.gnupg.de> On Fri, 19 Oct 2001 12:12:00 -0400, George Staikos said: > I haven't heard many details about this project and the last time I > checked, the online docs were in German, but I do have a few questions about Unfortunately the specs are all in German and we can't translate several hundred pages. OTOH, it is not needed, ast they are closely based on RFCs. We will provide some source code docs to explain the differences. > agree that things like key management should be integrated with the KDE > crypto manager? I think it would be unfortunate for users to have to import I don't know what the KDE crypto manager is. I have a very basic desktop ;-) If you can tell me somethig about that thing we can discuss it. One problem I see beforehand is close integration of crypto code with huge libraries. Especially security stuff shouls be as small as possible. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From bernhard@intevation.de Sat Oct 20 20:40:02 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Sat Oct 20 19:40:02 2001 Subject: missing feature: 'keyserver-export' feedback In-Reply-To: References: <20011019153704.C25808@intevation.de> Message-ID: <20011020193704.C30923@intevation.de> --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 19, 2001 at 04:31:14PM +0200, Dominik Schwald wrote: > Am Freitag, 19. Oktober 2001 15:37 schrieb Bernhard Reiter: > > Which version are you using? >=20 > gpa 0.4.1 > AFAIK thats the latest stable release... Yes, it is.=20 It is only that the version number is an information which is needed if someone digs in and tries to check out the behaviour. Bernhard --=20 Professional Service around Free Software (intevation.net) = =20 The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvRtkAACgkQh9ag3dpKERZuTQCfYypqwBa3YjbnY56yGa1xQ4SV ekQAnjzEEA4+6nfiupIjpN61mrYtV/2r =QCBG -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From bernhard@intevation.de Sat Oct 20 20:53:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Sat Oct 20 19:53:01 2001 Subject: Sorting the keyring by different fields (patch) In-Reply-To: <20011019173549.A688@mycroft> References: <20011019173549.A688@mycroft> Message-ID: <20011020195006.D30923@intevation.de> --VV4b6MQE+OnNyhkM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Miquel, first thanks for the patch and the Changelog-entry it is appreciated. Unfortunalty there is no one actively working on the gpa application=20 right now. :( I cannot promise quick inclusion in the CVS. This should also explain why the response to inquiries and questions is sometimes very slow. Gpa development was partly funded by a department of the German ministry=20 of economics and the other part was basically funded by=20 companies like G-N-U GmbH (Peter Gerwinski), Intevation GmbH and=20 "Werner Koch Softwaresysteme". Several people developed gpa, the old version by Markus Gerwinski and the new version revised by Bernhard Herzog. As funding ran out and there was not much response not a lot=20 time for gpa is available. (Note that gpa was only a small part of the government funding.) We are hoping to get funds for a follow-up project so that we can help externel developers and users better. This has not happened yet. On Fri, Oct 19, 2001 at 05:35:49PM +0200, Miguel Coca wrote: > In the past I've noticed that, by reading mailing lists where PGP > signatures are common, my keyring has been filled with lots of keys. Only= a > few of them are really trustworthy, and in GPA there is no easy way to fi= nd > them. >=20 > To solve this, I've modified GPA so that you can sort your keyring > by any field you want, including key and owner trust. I attach a patch > against the latest CVS (with ChangeLog entries at the beginning of the fi= le, > as suggested). >=20 > Also, I'd be willing to work on improving GPA, but I don't know w= hat > to do exactly. The TODO file seems a bit out of date. I understand there > would be interest in replacing gpapa with gpgme. I could try to do it, but > it seems to be a major change which I would not attempt without the > developers' permission and advice :-) I say: Go ahead you have our permission. Best is if you publish well understood patches. Feel free to publish tarballs with the patches and reasonable names. (Like gpa-0.4.1-miquel-0.1.tar or similiar...) We see about CVS later. > Meanwhile, I'm working on a Spanish translation. Don't count on > getting it soon, though, since there is a whole lot of strings in the > program :-) True. :) Bernhard --VV4b6MQE+OnNyhkM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvRuU0ACgkQh9ag3dpKERZfIQCg3Y+jFbukOwzVcqq43WBW3+8y mhEAniXsc7EL5lBBBJmYQhfo70snuA/O =UypR -----END PGP SIGNATURE----- --VV4b6MQE+OnNyhkM-- From bernhard@intevation.de Sat Oct 20 21:01:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Sat Oct 20 20:01:01 2001 Subject: Various design questions In-Reply-To: <200110191619.MAA25638@nitro.0wned.org> References: <200110191619.MAA25638@nitro.0wned.org> Message-ID: <20011020195827.E30923@intevation.de> --EgVrEAR5UttbsTXg Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi George, you are asking about the =E4gypten project. (This mailinglist is also for the gpa-metaproject and=20 still the gpa-application.) On Fri, Oct 19, 2001 at 12:12:00PM -0400, George Staikos wrote: > I haven't heard many details about this project and the last time I=20 > checked, the online docs were in German, but I do have a few questions ab= out=20 > the design of this project. =20 We will constantly publish more information. Like Werner said: Some docs and other information are in German right now. It is our strategy to publish as early as we manage to do it, that is why we have some parts in German published on the web already. Just keep asking and the priority of the tanslations will rise. :) > I guess we'll start off with this one: >=20 > I know that you have to make this compatible with Mutt, but do you not= =20 > agree that things like key management should be integrated with the KDE= =20 > crypto manager? I think it would be unfortunate for users to have to imp= ort=20 > their keys in two places and manage them twice. The optimal solution would be that keys are held in one place and can be accessed by several "front-ends". GpgSM will be this part in the diagramm of http://www.gnupg.org/aegypten/tech.en.html AFAIUI Gpgme will be the api which can be used by several programs to control the keydatabase.=20 Bernhard --EgVrEAR5UttbsTXg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvRu0MACgkQh9ag3dpKERZq4wCeIBvWM0oCCKdQJ8jrGTMA0/GM Id4AoM0m8ZpmAy7w++1JGYpcuA10Av6H =DgQ+ -----END PGP SIGNATURE----- --EgVrEAR5UttbsTXg-- From staikos@kde.org Sat Oct 20 21:55:01 2001 From: staikos@kde.org (George Staikos) Date: Sat Oct 20 20:55:01 2001 Subject: Various design questions In-Reply-To: <20011020195827.E30923@intevation.de> References: <200110191619.MAA25638@nitro.0wned.org> <20011020195827.E30923@intevation.de> Message-ID: <200110201853.OAA00180@nitro.0wned.org> On Saturday 20 October 2001 13:58, Bernhard Reiter wrote: > > I know that you have to make this compatible with Mutt, but do you not > > agree that things like key management should be integrated with the KDE > > crypto manager? I think it would be unfortunate for users to have to > > import their keys in two places and manage them twice. > > The optimal solution would be that keys are held in one place > and can be accessed by several "front-ends". > GpgSM will be this part in the diagramm of > http://www.gnupg.org/aegypten/tech.en.html > > AFAIUI Gpgme will be the api which can be used by several programs > to control the keydatabase. The only real way to get this to work now is to have the KDE GUI search both key databases. We have to have our own. Not anyone will want to install this project but they may want to use SSL in Konqueror or code signing in Reaktivate. This also raises another question: When a user imports a new key via the GUI, which database does it go into? The GPG one or the KDE one? Or both? Or do we prompt the user? I guess by using the md5 fingerprint it's easy to remove duplicates so that isn't a problem. KMail should use the KDE key manager though, not the GPG one (but the KDE key database can of course merge at runtime with the GPG one). It would be terribly unfortunate for a user to import a key into the KDE database and then not get to use it from within a KDE application. -- George Staikos From bernhard@intevation.de Sat Oct 20 21:59:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Sat Oct 20 20:59:01 2001 Subject: Various design questions In-Reply-To: <200110201853.OAA00180@nitro.0wned.org> References: <200110191619.MAA25638@nitro.0wned.org> <20011020195827.E30923@intevation.de> <200110201853.OAA00180@nitro.0wned.org> Message-ID: <20011020205625.A31435@intevation.de> --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable George, it looks like there is soem discussion about the same topic going on the kmail list. I still think there should be one small repository which is GUI and big-library independent. It just does not make sense for each GUI framework to have its own in the long run. Bernhard On Sat, Oct 20, 2001 at 02:52:40PM -0400, George Staikos wrote: > On Saturday 20 October 2001 13:58, Bernhard Reiter wrote: >=20 > > > I know that you have to make this compatible with Mutt, but do you= not > > > agree that things like key management should be integrated with the K= DE > > > crypto manager? I think it would be unfortunate for users to have to > > > import their keys in two places and manage them twice. > > > > The optimal solution would be that keys are held in one place > > and can be accessed by several "front-ends". > > GpgSM will be this part in the diagramm of > > http://www.gnupg.org/aegypten/tech.en.html > > > > AFAIUI Gpgme will be the api which can be used by several programs > > to control the keydatabase. >=20 > The only real way to get this to work now is to have the KDE GUI searc= h=20 > both key databases. We have to have our own. Not anyone will want to=20 > install this project but they may want to use SSL in Konqueror or code=20 > signing in Reaktivate. This also raises another question: When a user= =20 > imports a new key via the GUI, which database does it go into? The GPG o= ne=20 > or the KDE one? Or both? Or do we prompt the user? I guess by using th= e=20 > md5 fingerprint it's easy to remove duplicates so that isn't a problem. = =20 > KMail should use the KDE key manager though, not the GPG one (but the KD= E=20 > key database can of course merge at runtime with the GPG one). It would = be=20 > terribly unfortunate for a user to import a key into the KDE database and= =20 > then not get to use it from within a KDE application. >=20 > --=20 >=20 > George Staikos >=20 >=20 > _______________________________________________ > Gpa-dev mailing list > Gpa-dev@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gpa-dev --=20 Professional Service around Free Software (intevation.net) = =20 The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvRyNkACgkQh9ag3dpKERYqUQCfXcTUXcR8vU3oc2FrqLbxlS2p flgAn3E3ctX1a09IhEyyKddueMFQ9871 =uOrP -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From staikos@kde.org Sat Oct 20 22:03:01 2001 From: staikos@kde.org (George Staikos) Date: Sat Oct 20 21:03:01 2001 Subject: Various design questions In-Reply-To: <87ofn2msst.fsf@alberti.gnupg.de> References: <200110191619.MAA25638@nitro.0wned.org> <200110191639.MAA25804@nitro.0wned.org> <87ofn2msst.fsf@alberti.gnupg.de> Message-ID: <200110201900.PAA00234@nitro.0wned.org> 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 it did. > 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. -- George Staikos From staikos@kde.org Sat Oct 20 22:10:01 2001 From: staikos@kde.org (George Staikos) Date: Sat Oct 20 21:10:01 2001 Subject: Various design questions In-Reply-To: <20011020205625.A31435@intevation.de> References: <200110191619.MAA25638@nitro.0wned.org> <200110201853.OAA00180@nitro.0wned.org> <20011020205625.A31435@intevation.de> Message-ID: <200110201907.PAA00276@nitro.0wned.org> On Saturday 20 October 2001 14:56, Bernhard Reiter wrote: > George, > it looks like there is soem discussion about the same topic going on > the kmail list. > > I still think there should be one small repository > which is GUI and big-library independent. It just does not make > sense for each GUI framework to have its own in the long run. If it doesn't require one to link GPG libraries into the app in order to access the database, and if it's easy to obtain all forms of certificates needed for S/MIME and SSL (signers, clients and servers), then yes this is certainly desirable. Also we need the ability to store entire certificate chains. Right now I use K[Simple]Config because it's easy and it's standard in KDE. However I must warn that I no time available to modify the KSSL code to make use of a different library any time in the near future. The code in KSSL is ugly, mostly due to trying to merge KDE with OpenSSL (not a fun task in the least!). -- George Staikos From staikos@kde.org Sun Oct 21 17:02:01 2001 From: staikos@kde.org (George Staikos) Date: Sun Oct 21 16:02:01 2001 Subject: Various design questions In-Reply-To: <3BD2B4F0.D746B204@gmx.de> References: <200110191619.MAA25638@nitro.0wned.org> <200110201907.PAA00276@nitro.0wned.org> <3BD2B4F0.D746B204@gmx.de> Message-ID: <200110211359.JAA05106@nitro.0wned.org> On Sunday 21 October 2001 07:43, Markus Montkowski wrote: > > > I still think there should be one small repository > > > which is GUI and big-library independent. It just does not make > > > sense for each GUI framework to have its own in the long run. > > > > If it doesn't require one to link GPG libraries into the app in order > > to access the database, and if it's easy to obtain all forms of > > certificates needed for S/MIME and SSL (signers, clients and servers), > > then yes this is certainly desirable. Also we need the ability to store > > entire certificate chains. Right now I use K[Simple]Config because it's > > easy and it's standard in KDE. > > > > However I must warn that I no time available to modify the KSSL code > > to make use of a different library any time in the near future. The code > > in KSSL is ugly, mostly due to trying to merge KDE with OpenSSL (not a > > fun task in the least!). > > Hmm this sounds realy ugly don't know the Kx stuff since I'm running a > Gnome desktop, > but wouldn't the best approach be to keep the management and the GUI appart > from each other > and use Dynamic runtime linking? Each Module should export some well > defined Functions like This is advocating having two implementations of the exact same code. At that point one might as well implement S/MIME using KSSL/OpenSSL. > - Init(PFNTAB pCallbacks, PINFO pModInfo) > Called on Init with a Table of Callbacks for GUI stuff like MsgBoxes, > Statusbars, maybe if needed even a > Dialog function to handle some XML defined Dialog Templates. Returns a > structure with the a short and > a long name of the module, version etc. > - Destroy() Called when ending access. > - GetVersion(ULONG pulVersion) Returns the Implemented Interface version > for backward compatibility. > - Command(ULONG ulCtx, ULONG ulCommand, ULONG ulParam1, ULONG ulParam2) > Used for all the management calls etc. Well I have to say that this is a terribly ugly interface from a KDE perspective. And it's even more work to implement than what I suggested, I think. > The Management app would simply have config page where you can add the > modules to use. > All the key DBs are shown in a Treeview like control. If you are at the > root of all DBs you would import > a key to all if you selected 1 or multiple specific DBs you would add only > to these. Ok but from this point of view, it will still have to have multiple backends. So now we have this: --+ | +---- KDE Certificate Database | +-- Cert X | +-- Cert Y | +-- Cert Z +---- Aegypten Certificate Database | +-- Cert X | +-- Cert Y And they both contain the same certificates in most cases, they both do the same thing, yet different apps use different ones. I'm certain that the "newbie" user will by default import his certificate into the KDE database. We will get enough bug reports for this. We have worked long and hard for consistency in KDE. I don't want to see this inconsistency happening, and as I said, I certainly won't be coding support for something like this any time in the near future. -- George Staikos From wk@gnupg.org Mon Oct 22 11:00:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 22 10:00:01 2001 Subject: Various design questions In-Reply-To: <200110201853.OAA00180@nitro.0wned.org> (George Staikos's message of "Sat, 20 Oct 2001 14:52:40 -0400") References: <200110191619.MAA25638@nitro.0wned.org> <20011020195827.E30923@intevation.de> <200110201853.OAA00180@nitro.0wned.org> Message-ID: <87d73gjecw.fsf@alberti.gnupg.de> On Sat, 20 Oct 2001 14:52:40 -0400, George Staikos said: > signing in Reaktivate. This also raises another question: When a user > imports a new key via the GUI, which database does it go into? The GPG one > or the KDE one? Or both? Or do we prompt the user? I guess by using the Just store them in both if this makes sense for you. BTW, for secure usage of SSL you also need to handle revocations and you should not wait for the issuer to publish one but check yourself whether a CA has revoked something. If you are using OpenPGP keys you probably want to recalculate the WoT from time to time and of course handle revocations too. For me it makes pretty much sense to centralize this. OTOH, it may tak a while until this is implemented becuase it is outside the scope of most projects. > md5 fingerprint it's easy to remove duplicates so that isn't a problem. A database should never allow duplicates. On Sat, 20 Oct 2001 20:56:25 +0200, Bernhard Reiter said: > it looks like there is soem discussion about the same topic going on > the kmail list. Can we please continue to discuss KDE related things on kmail@kde.org and reserved this list for a backend and maybe discussion on other MUAs? On Sat, 20 Oct 2001 15:07:21 -0400, George Staikos said: > If it doesn't require one to link GPG libraries into the app in order to > access the database, and if it's easy to obtain all forms of certificates data formats and code should go hand in hand. So to access a future key database you probably want to use the provided API - this may be a low evele API and not the full blown gpgme thing. > certainly desirable. Also we need the ability to store entire certificate > chains. Right now I use K[Simple]Config because it's easy and it's standard And you have to do all the other key management tasks. > However I must warn that I no time available to modify the KSSL code to > make use of a different library any time in the near future. The code in > KSSL is ugly, mostly due to trying to merge KDE with OpenSSL (not a fun task Wait a while until GnuTLS is usable. On Sat, 20 Oct 2001 15:00:09 -0400, George Staikos said: > Ooops. Your mailing list doesn't put itself in the reply-to :) I assumed > it did. For sure not, we are honoring privacy issues (if only Gnus would do the same ;-) > 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 You have a full-blown X.509 management in KDE? I wonder why Kalle did not tell us. > codesigning requirements. We don't want to have to link GPG _and_ OpenSSL You want to do code-signing in KDE? This is a horrible difficult task which actually can only be untertaken with support of the OS kernel and even if you could do that with Linux you won't gain much because Linux makes no strong distinction beween root and kernel mode. I say, this has to be designed from ground up. > 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 Keeping duplicate data is one of the worst errors you can do, it often seems to be manageable but over the lifetime of the system it tends to get more and more complicated and error prone. Better prepare early to use just one DB. On Sun, 21 Oct 2001 09:59:12 -0400, George Staikos said: > On Sunday 21 October 2001 07:43, Markus Montkowski wrote: Huh, where? >> but wouldn't the best approach be to keep the management and the GUI appart >> from each other Sure. >> and use Dynamic runtime linking? Each Module should export some well >> defined Functions like The unix way is to separate services into different processes. This provides a cleaner interface, speeds up execution of moules a lot and is more secure (smaller modules have less errors). >> - Command(ULONG ulCtx, ULONG ulCommand, ULONG ulParam1, ULONG ulParam2) >> Used for all the management calls etc. Argg. This is a error prone interface which should only be used in very certain cases (e.g. ioctl(2) but even then the libc should provide function style wrappers.) >> All the key DBs are shown in a Treeview like control. If you are at the >> root of all DBs you would import Again, keeping a key at more than one place is a Bad Thing. > We have worked long and hard for consistency in KDE. I don't want to see > this inconsistency happening, and as I said, I certainly won't be coding George, please remember that there is more than KDE. KDE is just one big application pool but there are others, GNOME, xfce, Emacs and all the other environments which don't stick to a particular Service set except for Posix. Don't get lock into the Windows trap - even MS figured out a long time ago that there must be separation between the GUI and the services provided by an OS. There are not so few matured interfaces available - trying to create another will be futile, so lets stick to well matured interfacs. Posix and SysV are well matured (at least we know the problems). Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jas@extundo.com Mon Oct 22 13:01:01 2001 From: jas@extundo.com (Simon Josefsson) Date: Mon Oct 22 12:01:01 2001 Subject: Various design questions In-Reply-To: <200110201853.OAA00180@nitro.0wned.org> (George Staikos's message of "Sat, 20 Oct 2001 14:52:40 -0400") References: <200110191619.MAA25638@nitro.0wned.org> <20011020195827.E30923@intevation.de> <200110201853.OAA00180@nitro.0wned.org> Message-ID: George Staikos writes: > On Saturday 20 October 2001 13:58, Bernhard Reiter wrote: >=20 >> > I know that you have to make this compatible with Mutt, but do you = not >> > agree that things like key management should be integrated with the KDE >> > crypto manager? I think it would be unfortunate for users to have to >> > import their keys in two places and manage them twice. >> >> The optimal solution would be that keys are held in one place >> and can be accessed by several "front-ends". >> GpgSM will be this part in the diagramm of >> http://www.gnupg.org/aegypten/tech.en.html >> >> AFAIUI Gpgme will be the api which can be used by several programs >> to control the keydatabase. >=20 > The only real way to get this to work now is to have the KDE GUI searc= h=20 > both key databases. We have to have our own. Not anyone will want to=20 > install this project but they may want to use SSL in Konqueror or code=20 > signing in Reaktivate. This also raises another question: When a user= =20 > imports a new key via the GUI, which database does it go into? The GPG o= ne=20 > or the KDE one? Or both? Or do we prompt the user? I guess by using th= e=20 > md5 fingerprint it's easy to remove duplicates so that isn't a problem.= =20=20 > KMail should use the KDE key manager though, not the GPG one (but the KD= E=20 > key database can of course merge at runtime with the GPG one). It would = be=20 > terribly unfortunate for a user to import a key into the KDE database and= =20 > then not get to use it from within a KDE application. IMHO there should be a command line interface (or dynamic library ditto) to =C4gypten, and Kmail etc could use it, via the KDE key manager. Then non-KDE stuff such as Gnome and other applications (e.g., Emacs) could interface to the same database as well, without the need of interfacing with a full-blown widget-specific GUI. It would be unfortunate if all programs that need security has to require KDE, especially considering text-only apps such as Mutt. From staikos@kde.org Mon Oct 22 13:05:02 2001 From: staikos@kde.org (George Staikos) Date: Mon Oct 22 12:05:02 2001 Subject: Various design questions In-Reply-To: References: <200110191619.MAA25638@nitro.0wned.org> <200110201853.OAA00180@nitro.0wned.org> Message-ID: <200110221002.GAA11198@nitro.0wned.org> On Monday 22 October 2001 06:00, Simon Josefsson wrote: > IMHO there should be a command line interface (or dynamic library > ditto) to =C4gypten, and Kmail etc could use it, via the KDE key > manager. Then non-KDE stuff such as Gnome and other applications > (e.g., Emacs) could interface to the same database as well, without > the need of interfacing with a full-blown widget-specific GUI. It > would be unfortunate if all programs that need security has to require > KDE, especially considering text-only apps such as Mutt. Sure... That's a solution. I agree. (It was one of my suggestions)= =20 However someone will need to implement this on the KDE side too. Anyhow,= =20 please take this discussion to kmail@mail.kde.org if you want to discuss = it=20 more.=20 --=20 George Staikos From jan.petranek@student.uni-tuebingen.de Mon Oct 22 16:55:01 2001 From: jan.petranek@student.uni-tuebingen.de (Jan Petranek) Date: Mon Oct 22 15:55:01 2001 Subject: Various design questions / translation In-Reply-To: <87adynoalh.fsf@alberti.gnupg.de> Message-ID: On Fri, 19 Oct 2001, Werner Koch wrote: > Date: Fri, 19 Oct 2001 18:31:22 +0200 > From: Werner Koch > To: gpa-dev@gnupg.org > Subject: Re: Various design questions > > On Fri, 19 Oct 2001 12:12:00 -0400, George Staikos said: > > > I haven't heard many details about this project and the last time I > > checked, the online docs were in German, but I do have a few questions about > > Unfortunately the specs are all in German and we can't translate > several hundred pages. OTOH, it is not needed, ast they are closely > based on RFCs. We will provide some source code docs to explain the > differences. Up to now, I just have seen the project-pages on the web. (esp. the one explaining technology.). That part should not be so hard to translate, so if you want me to, I think I can translate that site into english. Could you please tell me, where to look for those hundred pages of specs? Jan Petranek From wk@gnupg.org Mon Oct 22 17:40:01 2001 From: wk@gnupg.org (Werner Koch) Date: Mon Oct 22 16:40:01 2001 Subject: Various design questions / translation In-Reply-To: (Jan Petranek's message of "Mon, 22 Oct 2001 15:52:40 +0200 (CEST)") References: Message-ID: <87y9m3g2pb.fsf@alberti.gnupg.de> On Mon, 22 Oct 2001 15:52:40 +0200 (CEST), Jan Petranek said: > explaining technology.). That part should not be so hard to translate, so > if you want me to, I think I can translate that site into english. If you want to do this, fine. > Could you please tell me, where to look for those hundred pages of specs? They are in the CVS (aegypten-specs/bsi) but they are all in PDF format and have only subtle changes against the PKIX and other standards. IMHO it is better to provide a document which lists the differences when we are done. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jan@intevation.de Tue Oct 23 12:14:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Tue Oct 23 11:14:01 2001 Subject: Various design questions / translation In-Reply-To: References: <87adynoalh.fsf@alberti.gnupg.de> Message-ID: <20011023111116.A23129@intevation.de> Dear Jan, On Mon, Oct 22, 2001 at 03:52:40PM +0200, Jan Petranek wrote: > Up to now, I just have seen the project-pages on the web. (esp. the one > explaining technology.). That part should not be so hard to translate, so > if you want me to, I think I can translate that site into english. helping with translations is extremely helpful. If you you do even some of this work, please send to me and I will add it to the web pages and if required extend or update the text. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From wk@gnupg.org Tue Oct 23 18:36:07 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 17:36:07 2001 Subject: PIN-Entry Message-ID: <87ofmytlmx.fsf@alberti.gnupg.de> Hi! I have just defined the protocol used to communicate with the PIN-Entry - pretty simple indeed (assuan-pinentry.txt in the aegypten-specs module). Because the PIn-Entry is a small GUI utility we can just fork and exec it whenever we need some interaction. This makes the communication pretty easy, as we only need to use 2 pipes for it - actually this will be stdin and stdout of course. I have thought again about the issue of passphrase caching and came to the result that it is better to let the gpg-agent (who invoked the PIN-Entry) do that. For various reasons, the gpg-agent has to stay in memory anyway and is therefore the best place to keep some sensitive sesion data. It might be best to write it as a standalone QT utility without a need for any KDE libs - it has to grab keyboard and mouse anyway, so it does not matter whether it has all the nice KDE standard features. In fact it should not have them and cut+paste should not be possible. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From kalle@klaralvdalens-datakonsult.se Tue Oct 23 19:28:01 2001 From: kalle@klaralvdalens-datakonsult.se (Matthias Kalle Dalheimer) Date: Tue Oct 23 18:28:01 2001 Subject: PIN-Entry In-Reply-To: <87ofmytlmx.fsf@alberti.gnupg.de> References: <87ofmytlmx.fsf@alberti.gnupg.de> Message-ID: <200110231626.f9NGQJQ04776@mailf.telia.com> On Tuesday 23 October 2001 17:35, Werner Koch wrote: > Hi! > > I have just defined the protocol used to communicate with the > PIN-Entry - pretty simple indeed (assuan-pinentry.txt in the > aegypten-specs module). > > Because the PIn-Entry is a small GUI utility we can just fork and exec > it whenever we need some interaction. This makes the communication > pretty easy, as we only need to use 2 pipes for it - actually this > will be stdin and stdout of course. > > I have thought again about the issue of passphrase caching and came to > the result that it is better to let the gpg-agent (who invoked the > PIN-Entry) do that. For various reasons, the gpg-agent has to stay in > memory anyway and is therefore the best place to keep some sensitive > sesion data. > > It might be best to write it as a standalone QT utility without a need > for any KDE libs - it has to grab keyboard and mouse anyway, so it > does not matter whether it has all the nice KDE standard features. In > fact it should not have them and cut+paste should not be possible. I agree. That also makes it possible to reuse it on other platforms like=20 MacOS X. We probably even want to link Qt statically to it so that nobody can mess= =20 around with LD_PRELOAD... Kalle --=20 Matthias Kalle Dalheimer President & CEO Klar=E4lvdalens Datakonsult AB Platform-independent Software Solutions http://www.klaralvdalens-datakonsult.se From mmontkowski@gmx.de Wed Oct 24 00:09:01 2001 From: mmontkowski@gmx.de (Markus Montkowski) Date: Tue Oct 23 23:09:01 2001 Subject: PIN-Entry References: <87ofmytlmx.fsf@alberti.gnupg.de> Message-ID: <3BD5EA21.F1DFF884@gmx.de> > I have just defined the protocol used to communicate with the > PIN-Entry - pretty simple indeed (assuan-pinentry.txt in the > aegypten-specs module). > > Because the PIn-Entry is a small GUI utility we can just fork and exec > it whenever we need some interaction. This makes the communication > pretty easy, as we only need to use 2 pipes for it - actually this > will be stdin and stdout of course. > > I have thought again about the issue of passphrase caching and came to > the result that it is better to let the gpg-agent (who invoked the > PIN-Entry) do that. For various reasons, the gpg-agent has to stay in > memory anyway and is therefore the best place to keep some sensitive > sesion data. > > It might be best to write it as a standalone QT utility without a need > for any KDE libs - it has to grab keyboard and mouse anyway, so it > does not matter whether it has all the nice KDE standard features. In > fact it should not have them and cut+paste should not be possible. Where can I get the doc, I would like to check if it is flexible enought to handle Different Reader classes (With and without PINpad and/or Display). The biggest Problem I can see with readers is that there is no direct support in PC/SC for readers with thie features (Apparently thats planed for PC/SC 2.0) So all Reader vendors who support this use vendor spec. commands to do it. The only API I know that covers PIN entry, Displays and even Biometrics is CT-API. So even on windows with PC/SC you have to use CT_API to use these features. As far as I have looked at the PC/SC implementation for Linux (and others) no reader so far does support PIN Pads. The PIN should be queried direcly from within the Crypto function. In the crypto transaction with the card the crypto function should issue an CT_DATA with PERFORM VERIFACTION (see CT-BCS (MKT spec. Part 4 page12) to the reader. The code handling the reader should check for that command and react accoring to the featues supportd by the reader. - Reader has no FUs Query the user for the PIN (get PIN size, type etc outof the command) and constuct the card APDU accordingly and send this to the card. - Reader has PIN-Pad-FU, No Display Show dialog with entryfield and no buttons Directly send the command to the reader. End Dialog when the reader command returns. Remark: These type of readers are mostly linked into the keybard cable or build into a keyboard and issue * chars when the user presses a digit. Enter and Backspace are also passed though to the system. So the dialog can work as a display device. If the user presses Abort an ESC char is normaly send. - Reader has a Display-FU and PIN-Pad-FU Simply show a dialog asking the user to enter the PIN at the reader. Directly send the command to the reader. End Dialog when the reader command returns. Remark: These type of readers normaly don't return any chars all visual feedback is done at the reader. Markus PS: Looks like working 4 years writing reader and card stuff for windows finaly pays of. From wk@gnupg.org Wed Oct 24 00:34:01 2001 From: wk@gnupg.org (Werner Koch) Date: Tue Oct 23 23:34:01 2001 Subject: breiter committed to libksba In-Reply-To: (aegypten-commits-admin@gnupg.org's message of "Tue, 23 Oct 2001 20:34:49 +0200") References: Message-ID: <87n12irqi6.fsf@alberti.gnupg.de> On Tue, 23 Oct 2001 20:34:49 +0200, aegypten-commits-admin said: > Added: File COPYING with GNU GPL v2, it just belongs there. I don't think it belongs to the CVS. By default automake creates symlinks to the standard files and we don't need to have hundreds of copies in the CVS. But anyway, it is not a problem either Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From bernhard@intevation.de Wed Oct 24 00:47:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Tue Oct 23 23:47:01 2001 Subject: breiter committed to libksba In-Reply-To: <87n12irqi6.fsf@alberti.gnupg.de> References: <87n12irqi6.fsf@alberti.gnupg.de> Message-ID: <20011023234452.B28720@intevation.de> --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2001 at 11:33:05PM +0200, Werner Koch wrote: > On Tue, 23 Oct 2001 20:34:49 +0200, aegypten-commits-admin said: >=20 > > Added: File COPYING with GNU GPL v2, it just belongs there. >=20 > I don't think it belongs to the CVS. By default automake creates > symlinks to the standard files and we don't need to have hundreds of > copies in the CVS. How does it know what to link COPYING to? GPL, LGPL? How do I get a GPL v2, if I only look at a cvs checkout without internet connection on a non-GNU-System? Bernhard --=20 Professional Service around Free Software (intevation.net) = =20 The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) --gj572EiMnwbLXET9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvV5NQACgkQh9ag3dpKERY2/QCeNduBaLHP/zqT6ilzz2b/1CaH fsQAoJqIEbqygkRDfpJ8G1h2igwTTc4X =Yln/ -----END PGP SIGNATURE----- --gj572EiMnwbLXET9-- From wk@gnupg.org Wed Oct 24 01:08:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 24 00:08:01 2001 Subject: breiter committed to libksba In-Reply-To: <20011023234452.B28720@intevation.de> (Bernhard Reiter's message of "Tue, 23 Oct 2001 23:44:52 +0200") References: <87n12irqi6.fsf@alberti.gnupg.de> <20011023234452.B28720@intevation.de> Message-ID: <876696roxf.fsf@alberti.gnupg.de> On Tue, 23 Oct 2001 23:44:52 +0200, Bernhard Reiter said: > How does it know what to link COPYING to? > GPL, LGPL? GPL = COPYING LGPL = COPYING.LIB (well, I don't know how it is called nowadays as I am not doing any LGPLed stuff) > How do I get a GPL v2, if I only look at a cvs checkout without > internet connection on a non-GNU-System? Every file should have this notice: * FOO is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * FOO is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From wk@gnupg.org Wed Oct 24 10:34:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 24 09:34:01 2001 Subject: PIN-Entry In-Reply-To: <3BD5EA21.F1DFF884@gmx.de> (Markus Montkowski's message of "Tue, 23 Oct 2001 23:07:30 +0100") References: <87ofmytlmx.fsf@alberti.gnupg.de> <3BD5EA21.F1DFF884@gmx.de> Message-ID: <87zo6hqyoj.fsf@alberti.gnupg.de> On Tue, 23 Oct 2001 23:07:30 +0100, Markus Montkowski said: > Where can I get the doc, I would like to check if it is flexible > enought to handle Different Reader classes (With and without PINpad > and/or Display). cvs -d :pserver:anoncvs@cvs.gnupg.org:/cvs/aegypten checkout \ aegypten-specs/assuan-pinentry.txt Login in first, password "anoncvs". However there is no need to check it against other specs because it is an internal protocol between GpgAgent and PINEntry which are both programs to be written for Aegypten. > The biggest Problem I can see with readers is that there is no > direct support in PC/SC for readers with thie features (Apparently > thats planed for PC/SC 2.0) We have not yet decided which API to use under GNU/Linux. > The only API I know that covers PIN entry, Displays and even > Biometrics is CT-API. So even on windows with PC/SC you have to use > CT_API to use these features. Good to know, but it is nothing we have to care about now. Using an external keypad to unlock a software held secret-key is a nice feature but security-wise we gain nothing from it. > The PIN should be queried direcly from within the Crypto function. > In the crypto transaction with the card the crypto function should issue Have a look at the diagram on the web page. We exactly do that. A reader requiring the host to retrieve the PIN from the keypad to send it right back to the reader is not woththe money - any way to utilize the keypad while a token is inserted is actually a security risk. Werner p.s. Can please check your MUA setup, there is something wrong with your line wrapping - I had to reformat it for quoting purposes. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From bernhard@intevation.de Wed Oct 24 11:46:01 2001 From: bernhard@intevation.de (Bernhard Reiter) Date: Wed Oct 24 10:46:01 2001 Subject: breiter committed to libksba In-Reply-To: <876696roxf.fsf@alberti.gnupg.de> References: <87n12irqi6.fsf@alberti.gnupg.de> <20011023234452.B28720@intevation.de> <876696roxf.fsf@alberti.gnupg.de> Message-ID: <20011024104402.F31212@intevation.de> --vKFfOv5t3oGVpiF+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2001 at 12:07:08AM +0200, Werner Koch wrote: > On Tue, 23 Oct 2001 23:44:52 +0200, Bernhard Reiter said: >=20 > > How does it know what to link COPYING to? > > GPL, LGPL? >=20 > GPL =3D COPYING > LGPL =3D COPYING.LIB (well, I don't know how it is called nowadays as I > am not doing any LGPLed stuff) Ah, I am learning here. Did not know that. Still: How does it know which file to link? (I assume there is an option there?) > > How do I get a GPL v2, if I only look at a cvs checkout without > > internet connection on a non-GNU-System? >=20 > Every file should have this notice: >=20 > * FOO is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License as published by > * the Free Software Foundation; either version 2 of the License, or > * (at your option) any later version. I know, but this is too weak IMO. Bernhard --=20 Professional Service around Free Software (intevation.net) = =20 The FreeGIS Project (freegis.org) Association for a Free Informational Infrastructure (ffii.org) FSF Europe (fsfeurope.org) --vKFfOv5t3oGVpiF+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iEYEARECAAYFAjvWf1IACgkQh9ag3dpKERbV8QCfcv3Osz7QkY3id0gA31h0yS9t Y38AniWQfZ8dVnSqrknpkIVBuB5zeBWt =TQTy -----END PGP SIGNATURE----- --vKFfOv5t3oGVpiF+-- From Olaf.Schlueter@secartis.com Wed Oct 24 16:46:02 2001 From: Olaf.Schlueter@secartis.com (Olaf.Schlueter@secartis.com) Date: Wed Oct 24 15:46:02 2001 Subject: PIN-Entry Message-ID: I have the feeling (maybe wrong) that there is a misconception about th= e "Secure PIN entry" feature some more advanced readers do provide (Marku= s will probably agree here). Secure PIN entry is realized by having the application issue a request to the reader to query the PIN from the use= r AND forward the PIN to the CARD, not to give it back to the application= . In fact it is an ISO PIN verify command with a special bit pattern where = the reader inserts the PIN code into before forwarding the command to the c= ard. The benefit gained is that the PIN never enters the PC. It is relevant = for use with smartcards only. Looking at the recently reported successful trojan horse attacks on PIN entry to some (partly SigG-conformant) smartcard based applications it is very relevant in that use case. PKCS#11 does support "Secure PIN entry" in its login options. Markus is= right, PC/SC which could provide a basic card reader API for a PKCS#11 implementation currently does not support "Secure PIN entry", one of it= s misfeatures. CT-API as an alternative to PC/SC does. PKCS#11 support is a requirement for aegypten. Although the implementat= ion of a PKCS#11-module is maybe beyond the project scope, to be able to utilize the PKCS#11 "Secure PIN entry" option in the PKCS#11 supporting= code, with the given aegypten architecture the PIN entry module has to = be bypassed in that case. Second comment: I think it is worth to be discussed, how the PIN module= , especially its communication path to the other modules, shall be protec= ted against trojan horse attacks. Olaf Schl=FCter SECARTIS AG = =20 Werner Koch = =20 To: gpa-dev@gnupg.org = =20 Sent by: cc: = =20 gpa-dev-admin@ Subject: Re: PIN-Entry = =20 gnupg.org = =20 = =20 = =20 24.10.01 09:34 = =20 = =20 = =20 On Tue, 23 Oct 2001 23:07:30 +0100, Markus Montkowski said: > Where can I get the doc, I would like to check if it is flexible > enought to handle Different Reader classes (With and without PINpad > and/or Display). cvs -d :pserver:anoncvs@cvs.gnupg.org:/cvs/aegypten checkout \ aegypten-specs/assuan-pinentry.txt Login in first, password "anoncvs". However there is no need to check it against other specs because it is an internal protocol between GpgAgent and PINEntry which are both programs to be written for Aegypten. > The biggest Problem I can see with readers is that there is no > direct support in PC/SC for readers with thie features (Apparently > thats planed for PC/SC 2.0) We have not yet decided which API to use under GNU/Linux. > The only API I know that covers PIN entry, Displays and even > Biometrics is CT-API. So even on windows with PC/SC you have to use > CT_API to use these features. Good to know, but it is nothing we have to care about now. Using an external keypad to unlock a software held secret-key is a nice feature but security-wise we gain nothing from it. > The PIN should be queried direcly from within the Crypto function. > In the crypto transaction with the card the crypto function should is= sue Have a look at the diagram on the web page. We exactly do that. A reader requiring the host to retrieve the PIN from the keypad to send it right back to the reader is not woththe money - any way to utilize the keypad while a token is inserted is actually a security risk. Werner p.s. Can please check your MUA setup, there is something wrong with your line wrapping - I had to reformat it for quoting purposes. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus _______________________________________________ Gpa-dev mailing list Gpa-dev@gnupg.org http://lists.gnupg.org/mailman/listinfo/gpa-dev = From wk@gnupg.org Wed Oct 24 17:20:01 2001 From: wk@gnupg.org (Werner Koch) Date: Wed Oct 24 16:20:01 2001 Subject: PIN-Entry In-Reply-To: (Olaf.Schlueter@secartis.com's message of "Wed, 24 Oct 2001 15:44:03 +0200") References: Message-ID: <87wv1lp1ca.fsf@alberti.gnupg.de> On Wed, 24 Oct 2001 15:44:03 +0200, Olaf Schlueter said: > I have the feeling (maybe wrong) that there is a misconception about the > "Secure PIN entry" feature some more advanced readers do provide (Markus I don't think so. There was a misunderstanding by Markus related to the PIN Entry. My original post was about the PIN Entry which is used to get the passphrase or PIN from the user. Well, it will also be used to get the PIN for a passphrase if a reader with a keypad is not available. > Second comment: I think it is worth to be discussed, how the PIN module, > especially its communication path to the other modules, shall be protected > against trojan horse attacks. You can't do anything against a trojaned system. The only thing a smardcard may provide is protection of the secret key. Passive attacks are possible and in theory an attacker could sniff on the communication between the GpgAgent and the PINEntry - it is not easy, though. To prevent this we have the option to encrypt the communication between these modules; a random session key agreed on using DH is pretty simple - although a bit computing intensive. MiM attacks are not an issue in this setting. To prevent snopping on the keyboard we will grab keyboard and mouse as usual for login programs. However, if an attacker is able to get read access to a user account he can also read the memory of all processes belonging to that user. So any encryption between user owned modules is pretty much pointless. BTW, if you get read access you will have write and execute access really soon after. One thing which is really worth to implement is a protection against malicious other users on the same machine. We do this by either using pipes (which are not readable by other users) or Unix domain sockets owned by the user. To protect against wrong permissions setting of the socket the server always checks the credentials of the peer. Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From mmontkowski@gmx.de Thu Oct 25 01:54:01 2001 From: mmontkowski@gmx.de (Markus Montkowski) Date: Thu Oct 25 00:54:01 2001 Subject: PIN-Entry References: <87wv1lp1ca.fsf@alberti.gnupg.de> Message-ID: <3BD75418.6FC610A1@gmx.de> Werner Koch wrote: > On Wed, 24 Oct 2001 15:44:03 +0200, Olaf Schlueter said: > > > I have the feeling (maybe wrong) that there is a misconception about the > > "Secure PIN entry" feature some more advanced readers do provide (Markus > > I don't think so. There was a misunderstanding by Markus related to > the PIN Entry. My original post was about the PIN Entry which is used > to get the passphrase or PIN from the user. Well, it will also be > used to get the PIN for a passphrase if a reader with a keypad is not > available. Still some light misunderstanding I think. I mentioned that there are 3 types of readers: 1. No PIN entry 2. PIN-Entry but No Display and 3. PIN-Entry with display. 1 and 3 are more or less easy to handle while 2 which is probably the biggest number of "secure" Readers in the field where this type of software is used. They require some Display on the screen. Like I said the reader sends a * char and keeps the digit in it's storage to combine it with the PIN APDU when the user presses Ok or the digit count is reached. Ok Now to the spec I read it and have some questions and/or suggestions to enable the thing to work with existing reader HW. Normal PIN Process: SETDESC...OK SETPROMT...OK CONFIRM (Blocks till the user presses enter/ESC? ) OK GETPIN...OK MessageBox Mode: SETERROR...OK CONFIRM (blocking?) OK I assume the dialogs close after the CONFIRM? Suggestions Add some commands which might not be needed for the Passphrase stuff but would come handy for smartcards: One to to set the PIN length and PIN Type(Numerical/Alphanum.) and result in the Confirm call to return after the 4th digit was pressed. As Reader PIN entries don't require pressing enter when a fixed PIN length is required. Example :Numerical 4 Digits C: SETPINTYPE S: INQUIRE DATA C: D N,4 C: END S: OK ---- Also we have to keep in mind that PIN-try commands do have a time variable after which they timeout with an error.Defaults are 15 sec no key after call and more than 5 sec between digits. For variable PIN length and at least 1 digit entered the reader shall display "Please Confirm Entry" and timeout only after an other 5 sec. So that a type 2 Reader would work the same way as a for a type 3 Reader. and Keep the dialog in sync with the command send to the reader. C: SETTIMEOUTS S: INQUIRE DATA C: D 15,5,5 C: END S: OK Or we would need some kind of End dialog command C:ENDDIALOG S:OK Example PIN Process for Reader with PAD and no Display: SETDESC...OK SETPROMT...OK (Dialog is Visible) Send VerifyCommand to Reader ENDDIALOG,OK (PIN not needed as the reader as the value, or entry timed out) ---- For Type 3 Readers we might need to display a dialog just with Text and no controls (Buttons). C:SHOWMESSAGE S: INQUIRE DATA C: D Please enter the PIN at your reader C: END S: OK C:ENDDIALOG S:OK From wk@gnupg.org Thu Oct 25 09:52:01 2001 From: wk@gnupg.org (Werner Koch) Date: Thu Oct 25 08:52:01 2001 Subject: PIN-Entry In-Reply-To: <3BD75418.6FC610A1@gmx.de> (Markus Montkowski's message of "Thu, 25 Oct 2001 00:51:52 +0100") References: <87wv1lp1ca.fsf@alberti.gnupg.de> <3BD75418.6FC610A1@gmx.de> Message-ID: <87n12gnref.fsf@alberti.gnupg.de> On Thu, 25 Oct 2001 00:51:52 +0100, Markus Montkowski said: > 1 and 3 are more or less easy to handle while 2 which is probably > the biggest number of "secure" Readers in the field where this type Yeah really "secure", you can have the smartcard sign everything with such a reader. Those with a display are actually not better unless you can's display the entire document. Smartdcards do protect the secret key pretty good against remote attacks. But this is all. No protection against any malicous use by trojaned software (read ActiveX). > Ok Now to the spec I read it and have some questions and/or suggestions > to enable the thing to work with existing reader HW. Please recall that the PINEntry's main task is to get the passphrase for a secret key stored on disk. Using it for a reader w/o keypad is just a kludge. > I assume the dialogs close after the CONFIRM? Yes. > One to to set the PIN length and PIN Type(Numerical/Alphanum.) > and result in the Confirm call to return after the 4th digit was No. This is not the usual way a dialog on a PC works; well UI design is not my domain of course. > Also we have to keep in mind that PIN-try commands do have a time variable > after which they timeout with an error.Defaults are 15 sec no key after call A timeout for a dialog which grabs the keyboard is indeed very useful (especially during testing). However, it is sufficient do configure this with a global option or fall back to a hardwired value. > only after an other 5 sec. So that a type 2 Reader would work the same way > as a for a type 3 Reader. and Keep the dialog in sync with the command It is far easier to send a CANCEL when the reader comes back with a timeout. > For Type 3 Readers we might need to display a dialog just with Text and > no controls (Buttons). > C:SHOWMESSAGE > S: INQUIRE DATA > C: D Please enter the PIN at your reader > C: END > S: OK Good point, we probably want to add this later. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From jan.petranek@student.uni-tuebingen.de Thu Oct 25 19:54:01 2001 From: jan.petranek@student.uni-tuebingen.de (Jan Petranek) Date: Thu Oct 25 18:54:01 2001 Subject: =?iso-8859-1?Q?=C4gypte?= =?iso-8859-1?Q?n?= with S/MIME and OpenPGP In-Reply-To: <20011019140205.A24679@intevation.de> Message-ID: On Fri, 19 Oct 2001, Jan-Oliver Wagner wrote: > Date: Fri, 19 Oct 2001 14:02:05 +0200 > From: Jan-Oliver Wagner > To: gpa-dev-list > Subject: Re: =C4gypten with S/MIME and OpenPGP > > Dear Jan, > > On Fri, Oct 19, 2001 at 12:30:59PM +0200, Jan Petranek wrote: > > on the web site of the =C4gypten project it is mentioned, that =C4gyp= ten (that > > is, GnuPG) aims to be able to read S/MIME-formatted mails, certificat= es > > and so on as well as the OpenPGP format. As far as I know GPG, this m= eans > > also support for the old PGP 2.6.x format (well, in some limited way). > > > > How far has the implementation of the S/MIME come now? > > the aim of the =C4gypten project is to sphinx-enable free software > MUAs. S/MIME is one important element. > > We are currently in the process to make up a detailed design > on how the solution might look like. > It is updated regularly at the =C4gypten homepage for open discussion. My interest lies more to the issue, how implementing both (OpenPGP and S/MIME) format would effect public-key-infrastructures. Up to now, it looks like this: Alice -------------< OpenPGP - Certifikate > ------------- Bob Charlie -----------< S/MIME -Certifikate >----------------- Dora While Alice and Bob are able to communicate, they both can't reach Charli= e and Dora, who are using S/MIME. Except, Alice uses two differen MUAs, one for S/MIME and one for OpenPGP. So, the PGP and the S/MIME-world exist separately from another. If we take keyserververs into account, the picture looks like this: Alice --< OpenPGP > --- [OpenPGP-Keyserver]---------- Bob Charlie --------[S/MIME-Keyserver]----------- Dora The keyserver might also be part of a CA, confirming that the key (n, e) really belong to Alice. Say, you finish the job and bring both OpenPGP and S/MIME to GnuPG. Alice= , using that software (I'd like to call it a dual MUA or 2MUA) would generate her own keypair - say, she uses RSA, so she has the numbers n, d= , and e. She uses e and n (the public key material) to form an OpenPGP-Certifikate. With the same program and key-material, she makes a S/MIME-Certifikate. The situation looks like this now: |-< OpenPGP > --- [OpenPGP-Keyserver]---------- Bob Alice --| [2MUA] | |--------[S/MIME-Keyserver]----------- Dora Now, from Alice view, the PGP and the S/MIME-world work hand in hand. The only trouble is having 2 different keyservers to maintain. That shouldn't be that hard. However, if the keyserver also uses both formats, this coul= d ease the task of tracking the keys. In case of a CA, also both keys would have to be signed. |-< OpenPGP > --| |--------- Bob Alice --| |--[ Dual Keyserver ]--| [2MUA] | | | |-------| |--------- Dora In case, Bob also uses a dual MUA, this would be no trouble for him: |-< OpenPGP > --- [OpenPGP-Keyserver]-------| Bob Alice --| |---- [2MUA] [2MUA] | | |--------[S/MIME-Keyserver]----------| He would now only have to choose, which format to use. His 2MUA, however, should realise, that Alice has sent her key (same person, same numbers) i= n both formats. That should mean, she can communicate in either format. > We haven't coded much at this point, but it is an essential > idea to review existing code and if its quality is good, tie > it together with other elements. Where no code is available > we of course must write it on our own unless someone likes > to participate. Sorry, but up to now, I'm too lousy in C-programming to be helpful for trusted applications :( (However, I'm learning...) JanP PS: Should this be the wrong place for this quite general discussion, feel free to haunt me and point me to an apropriate list. From jan@intevation.de Tue Oct 30 14:33:01 2001 From: jan@intevation.de (Jan-Oliver Wagner) Date: Tue Oct 30 14:33:01 2001 Subject: =?iso-8859-1?Q?=C4gypte?= =?iso-8859-1?Q?n?= with S/MIME and OpenPGP In-Reply-To: References: <20011019140205.A24679@intevation.de> Message-ID: <20011030143033.C16899@intevation.de> Hi Jan, On Thu, Oct 25, 2001 at 06:51:48PM +0200, Jan Petranek wrote: > My interest lies more to the issue, how implementing both (OpenPGP and > S/MIME) format would effect public-key-infrastructures. in the first instance it can't have an effect on pki. pki with OpenPGP and S/MIME are two separate worlds. Nonetheless this is a really important issue and besides technology issues concerns social/economic aspects in pki concepts. It is far beyond the scope of Ägypten to develop concepts for combining pki approaches behind OpenPGP and S/MIME. Perhaps we can convince authorities to invest in neutral research towards sensible pki :-) > PS: Should this be the wrong place for this quite general discussion, > feel free to haunt me and point me to an apropriate list. It's apropriate! Regards Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ From jas@extundo.com Tue Oct 30 20:53:01 2001 From: jas@extundo.com (Simon Josefsson) Date: Tue Oct 30 20:53:01 2001 Subject: =?iso-8859-1?q?=C4gypten?= with S/MIME and OpenPGP In-Reply-To: <20011030143033.C16899@intevation.de> (Jan-Oliver Wagner's message of "Tue, 30 Oct 2001 14:30:33 +0100") References: <20011019140205.A24679@intevation.de> <20011030143033.C16899@intevation.de> Message-ID: Jan-Oliver Wagner writes: > Hi Jan, > > On Thu, Oct 25, 2001 at 06:51:48PM +0200, Jan Petranek wrote: >> My interest lies more to the issue, how implementing both (OpenPGP and >> S/MIME) format would effect public-key-infrastructures. > > in the first instance it can't have an effect on pki. > pki with OpenPGP and S/MIME are two separate worlds. There's no reason it has to be that way, I believe proprietary PGP implementations already support X.509 certificate syntax, so OpenPGP and S/MIME aren't that far away from each other. > It is far beyond the scope of =C4gypten to develop concepts > for combining pki approaches behind OpenPGP and S/MIME. > Perhaps we can convince authorities to invest in > neutral research towards sensible pki :-) Well, if =C4gypten have a sensible framework that allows for both OpenPGP and S/MIME, the authorities might see that this was a good idea and help the effort.