> > 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.
Really? Even if you don't specify any algorithms or key lengths in detail?
> > 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.
Where did you get that from? Maybe I'm out of the loop, but last I checked,
a product with encryption hooks was an encryption product.
> > 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.
Wow, your experiences are totally different from mine. Or maybe I just did
more than I had to.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
