Tom Donovan wrote: > William A. Rowe, Jr. wrote: >> Two questions, one technical one legal. >> >> Technically, do we want to enable the Camillia algorithms in our >> binary builds of openssl 0.9.8 for win32 and other platforms where >> we might build it? >> >> Legally are we satisfied by >> http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html >> ? There is a small clause about permission needed to export from >> JP, which would mean if a JP site redistributed our binary (e.g. >> reexported it) it might cause them a hassle. >> >> Bill >> > Seems reasonable in anticipation of it becoming supported in FireFox 3.
Yes, that seems like a measurable target. It's nice to be ahead of the curve. > FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows > to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. > The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. Good to know, thanks! > On a slightly-related note; it might also be a good change to statically > link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds > about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. Are you factoring in the cost of statically linking it also to mod_deflate? Consider also anyone using either the compression or decompression side of zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment of awk.exe for the installer that I'm pretty intolerant of bloat, > I think rle compression (which is always available) or no-compression > gets used for SSL in most cases anyway. Many Windows users delete > zlib1.dll and never notice its absence. Well people who randomly delete dll's certainly get what they ask for, we install it in the httpd/bin tree, not on their system32 or somewhere equally offensive. But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. > PERL Configure VC-WIN32 enable-camellia zlib > --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib FYI the ASF's build hard-links it this way (zdll.lib instead) which ensures we throw away the zlib-dynamic stubs (and eliminate some race and processing-time performance hits), so there is that factor, too. I sort of doubt we'll see any savings when you factor deflate and openssl together? The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is.