> jaltman> The other reason for doing it the way it is currently done is
> jaltman> to protect against the "crypto-with-a-hole" argument. If
> jaltman> some countries will only approve the export of a software
> jaltman> product with a specific set of algorithms at specific
> jaltman> strengths, then they may refuse to export the software if it
> jaltman> allows a hardware (or simulated) device to be plugged in that
> jaltman> provides stronger or different algorithms.
>
> In that case, it makes more sense to disable the ENGINE code
> completely, doesn't it? Otherwise, there's no way to prove that any
> part of the crypto device won't be used, especially to a non-tech
> person.
Except that I might not be able to disable the crypto engine. The
crypto routine that I might be required to use might only exist in
hardware. Or the hardware might be required because it contains the
credentials. In that case the engine code must be compiled into
OpenSSL.
In this scenario, I need the option to disable all algorithms and
engine interfaces other than the ones that are required for the given
distribution.
/* This is just a theoretical requirement. I personally do not need
this functionality at the current time. I am just hypothesizing
about what I would need to prove my case to the court. */
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL. SSH soon to follow.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
