I read your post on bugtraq about CA.

I have written an HOWTO on www.tldp.org: SSL Certificates HOWTO. To
demistify what is to run a PKI with openssl.

As yourself what I see is that the only solution is to create your own CA. I
can't pay USD100 per certificate for each e-mail and each web site and each
client in my organisation.

I have been looking about root CA that delivers your signing certificates
and it seems that this beast does not really exists, or the price is
absolutely prohibitive. I have started to read the MS Exchange Server
Documentation and it seems there you have to build your own root CA too.

What should be available is that a root CA issue a certificate that allows
to sign other certificates as long as the CN is part of a domain name
([*.|*@]sopac.org) ie:
[EMAIL PROTECTED], www.sopac.org, ftp.sopac.org,....

But I have no idea if it is feasible... And if the client would make the
check...

Franck Martin
Network and Database Development Officer
SOPAC South Pacific Applied Geoscience Commission
Fiji
E-mail: [EMAIL PROTECTED]
Web site: http://www.sopac.org/
Support FMaps: http://fmaps.sourceforge.net/
Certificate: https://www.sopac.org/ssl/ 
This e-mail is intended for its addresses only. Do not forward this e-mail
without approval. The views expressed in this e-mail may not be necessarily
the views of SOPAC.

-----Original Message-----
From: John Howie [mailto:[EMAIL PROTECTED]]
Sent: Monday, 20 May 2002 9:56 
To: Pidgorny, Slav; [EMAIL PROTECTED]
Subject: RE: Verisign PKI: anyone to subordinate CA

In response to Slav's posting (below):
These are not fundamental technology problems; rather they are problems
with PKI in general, and policies and procedures belonging to the
issuing CA - in this case Verisign. I am not saying that there are no
bugs in MS Certificate Services, or in Verisign's systems and networks,
but that someone dropped the ball here (this is premised on your
description of events being accurate). If you recall, it was Verisign
who issued two code-signing certificates to someone claiming to be a MS
employee just over a year ago.
The whole concept of a PKI is based on trust. You trust the issuing CA.
If you have no faith in the issuing CA then you cannot trust any of the
certificates that they have issued, or the organizations to which they
were issued. This is not the fault of the organizations, but of the CA
itself.
Thawte's approach to certificates for individuals is interesting, with
the 'Web of Trust'. Of course, this is laughably exploitable by a
determined group of individuals and really doesn't build a 'Web of
Trust'.
While risking the wrath of many I'll venture to say that until public,
governmental, organizations (the Post Office?) act as Root CA's and
issues certificates to an organization that specifically prohibits them
from acting as a Subordinate CA to other organizations, or to
individuals, we won't see much trust in PKI for the foreseeable future.
Remember that you can have a PKI that issues certificates without
knowing what the matching Private Keys are (a fact ignored or
misunderstood by most).
Until then, expect to see a rise in the number of organizations acting
as their own CA's with self-signed CA certificates, which are just fine
if all you want to do is ensure secure communications between employees.
In all honesty a self-signed certificate is no less secure than one
issued by a CA whose Root CA certificate is included with your OS or
browser, it is just that it is not backed by a policy or insurance. And
it is cheaper.
John
-----Original Message-----
From: Pidgorny, Slav [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, May 18, 2002 11:01 PM
To: '[EMAIL PROTECTED]'
Subject: Verisign PKI: anyone to subordinate CA
G'day Bugtraq,
Microsoft Security Bulletin MS01-017
(http://www.microsoft.com/technet/security/bulletin/MS01-017.asp)
inspired
me to do some testing. Here are the results:
1. I configured Microsoft Certificate services to act as a standalone
subordinate CA. A request for a CA certificate was generated.
2. I sent this request as a request for a Web server SSL certificate.
3. The Verisign test CA did not complain upon processing this request.
It
generated and signed the certificate.
4. I installed the certificate to MS Certificate Services and start the
CA
service.
5. From now on, I effectively have a signed CA certification. Any
generated
signatures from this point will have a certification path leading to the
root CA.
I only used Verisign test root CA in my test. The steps above can
probably
be repeated using Verisign production root CA, resulting the situation
whereas I'm becoming a subordinate CA to Verisign trusted root without
letting them know.
Thawte test CA also signs the CA certificate submitted as a Web server
certificate, but MS Certificate Server refuses to install the
certificate as
the CA certificate. The difference between Verisign and Thawte
certificates
is the Basic Constraints field. If I would be using OpenSSL tools
instead of
MS Certificate Server, I can probably disable all the checks against the
CA
certificate.
Any thoughts? Do you think it's a security problem?
Regards,
S. Pidgorny, MS MVP, MCSE
DISCLAIMER: Opinions expressed by me is not necessarily my employer's,
it is
not intended to be formal and accurate. Neither myself nor my employer
assume any responsibility for any consequences.
P.S. Many thanks to Dave Ahmad for the discussion leading to this post.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to