On Fri, Jun 23, 2006, Kyle Hamilton wrote:
>
> I realize that this is a closed-development effort (as required)...
> but can anyone involved give us some kind of heads-up as to what will
> change, as soon as it's known? Please?
>
I'm on vacation until tomorrow and I'm sending this from a laptop
This is true. However, since we now have a better idea of what the
API is going to look like (is it going to change, anyone?), we can
still build and test our applications against 1.0 and hopefully expect
to be able to rebuild them and be able to validate regressions against
1.1.
Confusion may r
> Thus, if
> you are selling to an entity that requires FIPS, all OpenSSL (and
> other encryption) libraries must be put into FIPS mode, or FIPS is not
> satisfied and thus the application is not FIPS compliant.
As of Wednesday, June 21, the FIPS certification for OpenSSL has been
withdrawn; see
All cryptography used by the US Federal Government must be done in
compliance with FIPS 140-2. (Other entities may choose to require
FIPS compliance for their cryptographic functions as well.) Thus, if
you are selling to an entity that requires FIPS, all OpenSSL (and
other encryption) libraries m
Our application consists of multiple Unix processes each of
which creates its own OpenSSL instance. Does it violate the Security Policy if some
of those processes set OpenSSL into FIPS mode while others do not? In other
words, does the existence of non-FIPS mode toolkit instances invalidate
