Jean-Marc Desperrier wrote:

> Duane, I downloaded your code and a quick check shows you do use openssl
> to emit the certificate (the configuration file is not available in
> thoses sources).

While we provide the source code for peer review, we aren't intending
for any download to be used beyond review/subsequent development and
don't provide a number of things, but also the download includes things
we don't use which was done so for people helping with development so
they can run it on a single host, rather then the complicated setup we
have in place.

> From the above discussion, I suppose you use the (non default because of
> the security risks) option "copy_extensions = copy" of Openssl to allow
> extension from the request to be copied to the cert ?

The only copy that I'm aware of is for client certs, but the subject is
re-written when issuing certs...

> But this means you can't really control what extensions will in the
> emitted cert.

We've tried to break the current system into issuing certificates for
domains/emails which aren't validated, so far it's held up, although if
you work out a way round it I'd be happy to hear about it so I can
investigate it further...

> Another point, how much review by security experts on your code did you
> have until now ?

We've had some review, and some holes were found and closed in the process.

> You're using a bunch of technologies here, php, shell running

What CA uses a single technology?

> executable, sql requests you dynamically construct and that might be
> linked to some of the input data, that are really hard to get right and
> not introduce security failures. You probably don't have the budget to
> pay for a full review, but even a cursory review can be useful. And you
> can make some publicity about the fact your code is available, and that
> you'd welcome any help to make it as secure as possible.

Unfortunately most of the people our project attracts simply want
certificates (funnily enough) and aren't as security minded as that, we
are attempting to have a 3rd party audit (webtrust variety, more then
in-depth security review for the purposes of inclusion), although it's a
custom one that includes a lot more minimum requirements then the
WebTrust audit. I think Frank has named names in the past but don't
recall 100% and will let those involved speak up if they wish to be
known at this point in time.

> Moreover, it's possible I got it wrong somewhere, but what I see seems

You're making the assumption that what you download is being used in
production, what you download is the main website + some production
scripts + some non-production scripts to make life easier for those
wanting to help out with development.

> There is another point that is really a bad idea by itself, but that the
> previous points makes even worse, it's the fact your root CA directly
> signs the certificates.

Chicken and egg problem, it's difficult to get people to import a single
certificate, and near impossible to get them to import multiple certs
unless they already exist in the browser.

> It's also a good idea to regularly change the intermediate CA. You keep
> the crl size under control, and in case of compromise only some of the
> certs are not concerned (even if older intermediate CA will stay on-line
> to emit crl, but maybe you can lower the frequency of those crl and use
> an airwall : http://en.wiktionary.org/wiki/Airwall ).

At this point in time the size isn't so much the issue as client abuse
pulling down multiple copies on a per minute basis...

1 IP, 13 days, 3000 downloads, ~400megs...

-- 

Best regards,
 Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to