Fw: Debian-security copy any DVD to a standart CD at home OZKrmIV
Title: vGbpJdd Hello, Debian-security! abTwaTv WATCH CNN Ka Ajw ANALYSIS NYTimes AFcBV 'Don't listen to' gossip MF
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On Tue, 2003-08-26 at 17:38, Alan W. Irwin wrote: > On 26 Aug 2003, Scott James Remnant wrote: > > > The Debian package is actually Libtool 1.5.0a and is taken from their > > CVS repository, which wasn't compromised. > > > > I agree it takes extreme care to leave no tracks behind so it is fairly > improbable that the cvs server was compromised. And even if an undetected > crack occurred of that server, I agree it would take some effort to rewrite > RCS files (although temporarily putting in a maliciously modified cvs server > could do it). Thus, I agree with your judgement that restoring from cvs is > safe to a fairly large degree. However, GNU have apparently decided not to > restore from cvs since otherwise they should be able to proceed at a much > faster rate than 10-15 restorations per day. Shouldn't debian follow their > lead and be ultra-cautious also (especially with libtool since the downside > is so severe if that app is compromised)? > My tracking of the libtool 1.5 branch of CVS predates the compromise, trust me, there's no naughty code in there. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Debian Stable server hacked
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: > On Fri, Aug 22, 2003 at 06:35:37PM -0400, Phillip Hofmeister wrote: > > I would be willing to maintain a grsec kernel image with PaX and temp. > > file symlink blocking if someone would be willing to sponsor it (hint, > > hint) > > I really do not have the time to sponsor you, but would like to see this > happen. If you put together reasonable packages and ask on the mailing > lists, I don't think you'd have a problem finding a sponsor. There are a > number developers who are interested in this. I might be willing to sponsor it. Contact me off-list if interested. Stephen pgpsEdrw3Va80.pgp Description: PGP signature
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: > The Debian package is actually Libtool 1.5.0a and is taken from their > CVS repository, which wasn't compromised. > > The _orig.tar.gz *is* the potentially compromised one from the FTP site, > however any compromise would be reverted back to the uncompromised CVS > version by the .diff.gz[0] > > That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU > CVS tree for that release, and there's no differences... as well as > obviously manually reading the 1.5 -> 1.5.0a diff before applying it. > > Unless cvs.gnu.org was also compromised by someone insane enough to > rewrite RCS files by hand to hide the modification, libtool in unstable > is safe :-) I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The possibility of malicious code in the Debian unstablelibtool-1.5 package
On Tue, 2003-08-26 at 16:23, Alan W. Irwin wrote: > As I am sure most of you on this list are aware, GNU recently discovered > that their ftp file server was owned for many months by a cracker. > Indeed, I was the one who did a bulk-check of the easy MD5 sums and posted it to the list :-) > libtool-1.5.tar.gz is one of those tarballs that has not yet been given a > clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). > Nevertheless, it has been packaged for debian unstable. > Untrue. The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. The _orig.tar.gz *is* the potentially compromised one from the FTP site, however any compromise would be reverted back to the uncompromised CVS version by the .diff.gz[0] That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU CVS tree for that release, and there's no differences... as well as obviously manually reading the 1.5 -> 1.5.0a diff before applying it. Unless cvs.gnu.org was also compromised by someone insane enough to rewrite RCS files by hand to hide the modification, libtool in unstable is safe :-) Scott [0] which also accidentally contains some .svn trees, oops! :) -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, Aug 26, 2003 at 08:23:44AM -0700, Alan W. Irwin wrote: > Thus, wouldn't it be the right thing to do to withdraw the Debian unstable > libtool-1.5 package until GNU has a chance to check the tarball? (And of > course after the checked version is available, the tarball used to create > the current package should be checked against it to make sure nothing > malicious got propagated while the libtool-1.5 package was available). Would it not be the right thing to simply run diff between the source in testing (assuming that predates the crack) and the one in unstable and look for suspicious code? It doesn't take somebody operating in an official GNU capacity to confirm that there's no malicious code there. noah pgp0.pgp Description: PGP signature
The possibility of malicious code in the Debian unstable libtool-1.5package
As I am sure most of you on this list are aware, GNU recently discovered that their ftp file server was owned for many months by a cracker. They rightly withdrew all their many source tarballs to check for malicious code. The old tarballs were quickly reinstated (presumably because they had backups from prior to when the cracker owned them) and also found to be free of malicious code. There are still some 500 of these newer tarballs for GNU to check and apparently they are doing it at a rate of 10-15 per day. libtool-1.5.tar.gz is one of those tarballs that has not yet been given a clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). Nevertheless, it has been packaged for debian unstable. There is some room for optimism that the tarball used to create that package does not have malicious code in it (since the older tarballs that have been checked do seem to be clean), but the cracker did have full control when that tarball was created and for many months afterward, and the downside (many Debian packages compromised that are built with libtool-1.5) could be severe indeed. Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Note, I run debian stable myself, and I only happened to notice this possible libtool-1.5 security problem for Debian unstable by chance. Since there doesn't seem to be any discussion of this issue on this list (and no libtool bug reports about this issue) I thought I had better bring it up for discussion. Alan W. Irwin __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Stable server hacked
On Fri, Aug 22, 2003 at 06:35:37PM -0400, Phillip Hofmeister wrote: > On Fri, 22 Aug 2003 at 10:32:27AM -0400, Matt Zimmerman wrote: > > It is often the case that the attacker doesn't know the exact location > > of structures in memory; there are techniques for finding out. I'm sure > > that the authors of PaX do not misrepresent it as complete protection. > > > > It's pointless to argue about it; it's clear that PaX provides some > > value in protection against security vulnerabilities, and I think it's > > also clear that because it will break many existing applications, it is > > not suitable for use by default. But there is no reason why a > > PaX-enabled kernel could not be provided as an option. All it needs is > > someone willing to do the work (hint, hint). > > I would be willing to maintain a grsec kernel image with PaX and temp. > file symlink blocking if someone would be willing to sponsor it (hint, > hint) I really do not have the time to sponsor you, but would like to see this happen. If you put together reasonable packages and ask on the mailing lists, I don't think you'd have a problem finding a sponsor. There are a number developers who are interested in this. -- - mdz
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: > My tracking of the libtool 1.5 branch of CVS predates the compromise, > trust me, there's no naughty code in there. Thanks for that strong public reassurance and the useful discussion that preceded it. Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, 2003-08-26 at 17:38, Alan W. Irwin wrote: > On 26 Aug 2003, Scott James Remnant wrote: > > > The Debian package is actually Libtool 1.5.0a and is taken from their > > CVS repository, which wasn't compromised. > > > > I agree it takes extreme care to leave no tracks behind so it is fairly > improbable that the cvs server was compromised. And even if an undetected > crack occurred of that server, I agree it would take some effort to rewrite > RCS files (although temporarily putting in a maliciously modified cvs server > could do it). Thus, I agree with your judgement that restoring from cvs is > safe to a fairly large degree. However, GNU have apparently decided not to > restore from cvs since otherwise they should be able to proceed at a much > faster rate than 10-15 restorations per day. Shouldn't debian follow their > lead and be ultra-cautious also (especially with libtool since the downside > is so severe if that app is compromised)? > My tracking of the libtool 1.5 branch of CVS predates the compromise, trust me, there's no naughty code in there. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
[no subject]
Mike Lewis Business Systems Analyst Mississippi Band of Choctaw Indians dba Chahta Enterprise Enterprise Headquarters for our Wiring Harness Manufacturing Division Commercial Laundry Division Geospatial and Information Technology Division 390 Industrial Road Choctaw, MS 39350 601-656-7350 x 102 601-656-8785 - Fax -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
towards a taxonomy of Information Assurance (IA)
Fellow Information Security Professionals, Bottom line: I'd like your help in shaping a usable taxonomy of Information Assurance.* This taxonomy is part of my graduate studies, and will not be used for any commercial purposes. It will remain an "open source" open project. I am presently working on creating a taxonomy of information assurance, based on the three aspects of: (1) Information characteristics (2) Information states (3) Security countermeasures These three aspects of Information Assurance (IA) were highlighted by John McCumber [1] as well as a team of West Point researchers [2] as a component of works that define an integrated approach to security. I have also considered the works of Matt Bishop [3] in how to create a useful taxonomy. Within the next 6 months, I would like to create a taxonomy that graphically depicts the relationships of these three aspects. I will use an "open source" model whereby all of my findings & results will be posted for public review and revision. My intent is that this taxonomy could be used by the academic community, industry, and government in improving the precision of communication used in discussing information assurance/security topics. I have searched the Internet widely for a taxonomy of Information Assurance, but I have not found anything that is sufficiently detailed for application with real world problems. I've posted my initial results to the following URL: http://www.sharp-ideas.net/ia/information_assurance.htm for comments and peer review. Cheers, Abe Usher [EMAIL PROTECTED] * Information assurance is defined as "information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [1] McCumber, John. "Information Systems Security: A Comprehensive Model". Proceedings 14th National Computer Security Conference. National Institute of Standards and Technology. Baltimore, MD. October 1991. [2] Maconachy, Victor, Corey Schou, Daniel Ragsdale, and Don Welch. "A Model for Information Assurance: An Integrated Approach". Proceedings of the 2001 IEEE Workshop on Information Assurance and Security. U.S. Military Academy. West Point, NY. June 2001. [3] Bishop, Matt. "A Critical Analysis of Vulnerability Taxonomies". Department of Computer Science, University of California. Davis, CA. September 1996. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On 26 Aug 2003, Scott James Remnant wrote: > The Debian package is actually Libtool 1.5.0a and is taken from their > CVS repository, which wasn't compromised. > > The _orig.tar.gz *is* the potentially compromised one from the FTP site, > however any compromise would be reverted back to the uncompromised CVS > version by the .diff.gz[0] > > That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU > CVS tree for that release, and there's no differences... as well as > obviously manually reading the 1.5 -> 1.5.0a diff before applying it. > > Unless cvs.gnu.org was also compromised by someone insane enough to > rewrite RCS files by hand to hide the modification, libtool in unstable > is safe :-) I agree it takes extreme care to leave no tracks behind so it is fairly improbable that the cvs server was compromised. And even if an undetected crack occurred of that server, I agree it would take some effort to rewrite RCS files (although temporarily putting in a maliciously modified cvs server could do it). Thus, I agree with your judgement that restoring from cvs is safe to a fairly large degree. However, GNU have apparently decided not to restore from cvs since otherwise they should be able to proceed at a much faster rate than 10-15 restorations per day. Shouldn't debian follow their lead and be ultra-cautious also (especially with libtool since the downside is so severe if that app is compromised)? Alan __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, 2003-08-26 at 16:23, Alan W. Irwin wrote: > As I am sure most of you on this list are aware, GNU recently discovered > that their ftp file server was owned for many months by a cracker. > Indeed, I was the one who did a bulk-check of the easy MD5 sums and posted it to the list :-) > libtool-1.5.tar.gz is one of those tarballs that has not yet been given a > clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). > Nevertheless, it has been packaged for debian unstable. > Untrue. The Debian package is actually Libtool 1.5.0a and is taken from their CVS repository, which wasn't compromised. The _orig.tar.gz *is* the potentially compromised one from the FTP site, however any compromise would be reverted back to the uncompromised CVS version by the .diff.gz[0] That aside, I've compared libtool-1.5.tar.gz to a checkout of the GNU CVS tree for that release, and there's no differences... as well as obviously manually reading the 1.5 -> 1.5.0a diff before applying it. Unless cvs.gnu.org was also compromised by someone insane enough to rewrite RCS files by hand to hide the modification, libtool in unstable is safe :-) Scott [0] which also accidentally contains some .svn trees, oops! :) -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: The possibility of malicious code in the Debian unstable libtool-1.5 package
On Tue, Aug 26, 2003 at 08:23:44AM -0700, Alan W. Irwin wrote: > Thus, wouldn't it be the right thing to do to withdraw the Debian unstable > libtool-1.5 package until GNU has a chance to check the tarball? (And of > course after the checked version is available, the tarball used to create > the current package should be checked against it to make sure nothing > malicious got propagated while the libtool-1.5 package was available). Would it not be the right thing to simply run diff between the source in testing (assuming that predates the crack) and the one in unstable and look for suspicious code? It doesn't take somebody operating in an official GNU capacity to confirm that there's no malicious code there. noah pgpwhJqV4WpGy.pgp Description: PGP signature
The possibility of malicious code in the Debian unstable libtool-1.5 package
As I am sure most of you on this list are aware, GNU recently discovered that their ftp file server was owned for many months by a cracker. They rightly withdrew all their many source tarballs to check for malicious code. The old tarballs were quickly reinstated (presumably because they had backups from prior to when the cracker owned them) and also found to be free of malicious code. There are still some 500 of these newer tarballs for GNU to check and apparently they are doing it at a rate of 10-15 per day. libtool-1.5.tar.gz is one of those tarballs that has not yet been given a clean bill of health by GNU (see http://ftp.gnu.org/gnu/libtool/). Nevertheless, it has been packaged for debian unstable. There is some room for optimism that the tarball used to create that package does not have malicious code in it (since the older tarballs that have been checked do seem to be clean), but the cracker did have full control when that tarball was created and for many months afterward, and the downside (many Debian packages compromised that are built with libtool-1.5) could be severe indeed. Thus, wouldn't it be the right thing to do to withdraw the Debian unstable libtool-1.5 package until GNU has a chance to check the tarball? (And of course after the checked version is available, the tarball used to create the current package should be checked against it to make sure nothing malicious got propagated while the libtool-1.5 package was available). Note, I run debian stable myself, and I only happened to notice this possible libtool-1.5 security problem for Debian unstable by chance. Since there doesn't seem to be any discussion of this issue on this list (and no libtool bug reports about this issue) I thought I had better bring it up for discussion. Alan W. Irwin __ Alan W. Irwin email: [EMAIL PROTECTED] phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a simple SSL-CA package
- Original Message - From: "Tarjei Huse" <[EMAIL PROTECTED]> To: "Noah L. Meyerhans" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, August 24, 2003 1:51 PM Subject: Re: Looking for a simple SSL-CA package > > I think I'll end up with pyca (www.pyca.org) as it seems to have most of > these features in place. The other possibilities are openca which is > IMHO to complicated for my needs and tinyca (that many on this list > suggested) that doesn't (please correct me if I'm wrong) give me the > finished scripts for importing certs in outlook, IE, Mozilla and other > programs. > > If there are other alternatives out there, please let me know. Again, I > thank you for your contributions. > Tarjei > Apologies if I am repeating someone else's points, I haven't followed the thread in depth. It sounds kind of kooky, but we have operated a CA for about 2 years, having about 400 users, using just openssl and a few hand turned scripts and a dynamic webpage. User info is maintained in MySQL, though we let openssl maintain the CA history in text files. The CA doesn't do any of the Outlook, IE, Mozilla etc importing - those programs do that, you just have to know what sort of certs to generate, and how to trigger the import processing on the client. We use a webpage and several variants of the XEnroll object for IE v 5.01-6.0 where IE generates the keypairs, and creates a CSR which gets posted to the webserver. We then sign the request and create a x-pkcs7-certificates [.p7b file] which is returned to the webserver for the user to download (they hit the Refresh button on the request page). There are some busted Office XP upgrade paths, for which we have to generate the keypair on our server in a PKCS12 format [.pfx file] - which we then make available to the user via the webpage. NS/Mozilla is easy - as per IE, we get the client to generate a CSR which gets posted to our webserver. We sign the certificate, x-x509-user-cert [.cct file] and copy it back to the webserver for the user to install. The only bugbear is that Mozilla succeeds silently, so you can't easily throw up a warning if the import failed for some reason [failure is rare]. Outlook will recognise your CA as an authority for secure pop and imap connections, if you import your self-signed CA cert in IE - just get your users to download your CA cert x-x509-ca-cert [.crt file] from a website, and click on Install Cert. Regards Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
Mike Lewis Business Systems Analyst Mississippi Band of Choctaw Indians dba Chahta Enterprise Enterprise Headquarters for our Wiring Harness Manufacturing Division Commercial Laundry Division Geospatial and Information Technology Division 390 Industrial Road Choctaw, MS 39350 601-656-7350 x 102 601-656-8785 - Fax
towards a taxonomy of Information Assurance (IA)
Fellow Information Security Professionals, Bottom line: I'd like your help in shaping a usable taxonomy of Information Assurance.* This taxonomy is part of my graduate studies, and will not be used for any commercial purposes. It will remain an "open source" open project. I am presently working on creating a taxonomy of information assurance, based on the three aspects of: (1) Information characteristics (2) Information states (3) Security countermeasures These three aspects of Information Assurance (IA) were highlighted by John McCumber [1] as well as a team of West Point researchers [2] as a component of works that define an integrated approach to security. I have also considered the works of Matt Bishop [3] in how to create a useful taxonomy. Within the next 6 months, I would like to create a taxonomy that graphically depicts the relationships of these three aspects. I will use an "open source" model whereby all of my findings & results will be posted for public review and revision. My intent is that this taxonomy could be used by the academic community, industry, and government in improving the precision of communication used in discussing information assurance/security topics. I have searched the Internet widely for a taxonomy of Information Assurance, but I have not found anything that is sufficiently detailed for application with real world problems. I've posted my initial results to the following URL: http://www.sharp-ideas.net/ia/information_assurance.htm for comments and peer review. Cheers, Abe Usher [EMAIL PROTECTED] * Information assurance is defined as "information operations that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. This includes providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [1] McCumber, John. "Information Systems Security: A Comprehensive Model". Proceedings 14th National Computer Security Conference. National Institute of Standards and Technology. Baltimore, MD. October 1991. [2] Maconachy, Victor, Corey Schou, Daniel Ragsdale, and Don Welch. "A Model for Information Assurance: An Integrated Approach". Proceedings of the 2001 IEEE Workshop on Information Assurance and Security. U.S. Military Academy. West Point, NY. June 2001. [3] Bishop, Matt. "A Critical Analysis of Vulnerability Taxonomies". Department of Computer Science, University of California. Davis, CA. September 1996.
unsubscribe
Re: Looking for a simple SSL-CA package
- Original Message - From: "Tarjei Huse" <[EMAIL PROTECTED]> To: "Noah L. Meyerhans" <[EMAIL PROTECTED]>; Sent: Sunday, August 24, 2003 1:51 PM Subject: Re: Looking for a simple SSL-CA package > > I think I'll end up with pyca (www.pyca.org) as it seems to have most of > these features in place. The other possibilities are openca which is > IMHO to complicated for my needs and tinyca (that many on this list > suggested) that doesn't (please correct me if I'm wrong) give me the > finished scripts for importing certs in outlook, IE, Mozilla and other > programs. > > If there are other alternatives out there, please let me know. Again, I > thank you for your contributions. > Tarjei > Apologies if I am repeating someone else's points, I haven't followed the thread in depth. It sounds kind of kooky, but we have operated a CA for about 2 years, having about 400 users, using just openssl and a few hand turned scripts and a dynamic webpage. User info is maintained in MySQL, though we let openssl maintain the CA history in text files. The CA doesn't do any of the Outlook, IE, Mozilla etc importing - those programs do that, you just have to know what sort of certs to generate, and how to trigger the import processing on the client. We use a webpage and several variants of the XEnroll object for IE v 5.01-6.0 where IE generates the keypairs, and creates a CSR which gets posted to the webserver. We then sign the request and create a x-pkcs7-certificates [.p7b file] which is returned to the webserver for the user to download (they hit the Refresh button on the request page). There are some busted Office XP upgrade paths, for which we have to generate the keypair on our server in a PKCS12 format [.pfx file] - which we then make available to the user via the webpage. NS/Mozilla is easy - as per IE, we get the client to generate a CSR which gets posted to our webserver. We sign the certificate, x-x509-user-cert [.cct file] and copy it back to the webserver for the user to install. The only bugbear is that Mozilla succeeds silently, so you can't easily throw up a warning if the import failed for some reason [failure is rare]. Outlook will recognise your CA as an authority for secure pop and imap connections, if you import your self-signed CA cert in IE - just get your users to download your CA cert x-x509-ca-cert [.crt file] from a website, and click on Install Cert. Regards Jeff