> If you dynamically
> link to OpenSSL, you may have no idea or control over what algorithms and
> key lengths you wind up using. This makes the form impossible to fill out.
In my experience if you just refer to the SSL/TLS spec you're fine.
> If your product includes the OpenSSL libraries, you'd likely have to build
> a secure key length limitation into the version of the libraries that you
> ship. If your product dynamically links to the OpenSSL libraries or permits
> the user to supply his own version, you'd likely have to provide reasonable
> secure key length limitations in the application.
If your product doesn't supply crypto, there's no need to apply for a license.
The old crypto-with-a-hole is dead. In my experiences, if you're implementing
HTTPS, then just refer to the SSL/TLS spec. If you are implementing a
custom protocol, then you have to fill out all those key parameters.
> Note that the BXA doesn't care how your code does what it does, whether it
> uses OpenSSL or code you wrote yourself or whatever. They just care *what*
> your code is capable of doing.
Not true. If you say "I'm just using OpenSSL to implement standard HTTPS"
then you're in lot simpler position than if you grew your own from scratch.
These folks do understand the landscape out there.
> Also, you can probably obtain an export
> license or license exemption for nearly any combination of algorithms and
> key lengths, so you won't have to weaken your export version, just exercise
> more control.
Agreed.
/r$
--
Rich Salz Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
