Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/22/2015 09:32 AM, Imran Ali wrote:
> Thanks Steve,
> 
> I was more concerned on the news that openssl may not be FIPS
> compliant because of:
> 
> 'sunsetting' older FIPS validations  and the reasoning behind the
> change has to do with the Random Number Generators (RNG). As of
> December 31, 2015, ANSI X9.31 and X9.62 RNG's will no longer be
> allowed for use in FIPS mode, leaving us the Random Bit Generators
> (RBG) of NIST SP 800-90

That's the "paper shuffle" referenced earlier, and in this earlier post
in this same thread:

  https://mta.openssl.org/pipermail/openssl-users/2015-December/002562.html

Thanks to Datagravity that "paper shuffle" is being addressed. The test
lab has the necessary paperwork and there is nothing more we can do
other than wait on the process.

> My understanding based on this is that any applications using ANSI
> X9.31 and X9.62 functions under FIPS mode will no longer be compliant
> however the whole openssl will still be FIPS compliant but need
> paper-shuffle to mark these changes. Am I correct with my assumption
> on this?

Kinda-sorta. The "sunset" issue isn't *use* of X9.31, which is not the
default for the OpenSSL FIPS Object Module and not used anywhere with
the module as far as I know. The issue is that any validations that
implement *both* X9.31 RNG *and* one or more DRBGs will be yanked
without the paper shuffle, regardless of any actual use of X9.31 with
those modules. The paper shuffle basically consists of removing most
mentions of X9.31 RNG from the Security Policy document. Any application
that has deliberately and explicitly enabled a non-default use of the
X9.31 RNG would need to be changed, independently of the paper shuffle,
but I doubt there are any such applications.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/14/2015 08:23 AM, Steve Marquess wrote:
> On 12/02/2015 11:16 AM, Steve Marquess wrote:
>> If you don't know or care what FIPS 140-2 is, be very glad this isn't
>> your problem and turn your charitable attentions to some worthy cause.
>>
>> The CMVP has introduced a new policy that will result in the effective
>> termination of many extant validations if they are not updated by
>> January 31 2016[1]. That update is a pure paper shuffle -- adding
>> politically correct verbiage to the Security Policy document -- but
>> without it the CMVP will "de-list" the validation. The original OpenSSL
>> FIPS Object Module validations (#1747, #2398, #2473) and all validations
>> based on them -- which is a lot of validations -- are affected.
>>
>> I'll be doing the labor to prepare the revised Security Policy documents
>> for all the validations that have been performed by OSF, both the well
>> known open source based ones and also "private label" ones, and the test
>> labs for some of those validations are also doing their part pro bono.
>> However, the test lab we used for the original open source based
>> validations (#1747, #2398, #2473) is charging $1250 for those three
>> related validations of the same module. Note this is not unreasonable as
>> these updates involve a non-trivial amount of work.
>>
>> ...
> 
> I'm pleased to report that this $1250 cost to paper-shuffle the
> #1747/#2398/#2473 validations has been covered, by Datagravity Inc.
> Within minutes of hearing of the issue for the first time the the CEO,
> Paula Long, not only had a check en route to the test lab but also sent
> a scan of the check and envelope as a heads-up for the lab.
> 
> ...

Three companies answered this call to cover the cost of the "X9.31 RNG
transition" paper shuffle. Datagravity (http://datagravity.com/) acted
quickly and decisively, and the requisite paperwork has begun its
journey through the bowels of the FIPS 140-2 bureaucracy.

I would like to note that another company, Niksun (https://niksun.com/)
also contacted the test lab to make arrangement for payment of that fee.
If not for Datagravity beating them to the punch they would have been
the benefactor for this very necessary action.

The third company (not named here by request) was vigorously pursuing an
in-house approvals process and would also have covered this effort.

I thank all three for volunteering to bail out the entire community of
OpenSSL FIPS module users.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/21/2015 09:32 PM, Salz, Rich wrote:
> 
>> Just want to confirm on this item. Are we saying that to get
>> openssl back to be FIPS compliance is just a paper shuffle. If so
>> is there any expected eta on it as our team is using openssl
>> version for a security project and we need a fips compliance
>> library.
> 
> No.
> 
> We have answered this many times, but perhaps the messages were too
> long and confusing.

Yes indeed (mea culpa). It's such a mess I don't know how to address it
succinctly. Part of the problem is that there are multiple intertwined
issues.

I think the term "paper shuffle" in this context refers to the "X9.31
RNG transition" issue which is (hopefully) a one shot aberration, one
pothole in the vast wasteland of FIPS 140-2 validations. That is
(mostly) addressed, in that a benefactor has come forward (Datagravity,
Inc.) to pay the test lab fees necessary for filing the necessary
paperwork. That has been done and now we are just waiting on the usual
slow bureaucratic process. I'll make an announcement when that paper
shuffle is complete.

> 
> We are not doing any work on adding new platforms at this time.  If
> you cannot use one of the existing platforms, then there is no FIPS
> support available "for free."

No "freebies". However, we are continuing to perform *sponsored* (some
one pays for it) "change letter" additions of new platforms to the
*existing* OpenSSL FIPS module (validations #1747/#2398/#2473). We will
continue to do so for as long as such updates are technically and
economically feasible. Just last week eleven new platforms were added to
that module this way, and more platforms are pending.

Those aren't free in that some sponsor needs to fund them initially, but
once done those platforms are available to everyone. That is the
collaborative process by which the OpenSSL FIPS module has grown to
support some 120 platforms, more by far than for any other FIPS 140-2
validated module.

> We are not taking on a new validation with new algorithms, etc.,
> unless we get one or more sponsors who are willing to contribute a
> significant amount of money, among other things.

Correct ... we are eager to do so but lack the opportunity at present. I
remain hopeful that we will be able to attempt this at some point.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Imran Ali]

Thanks Steve,

I was more concerned on the news that openssl may not be FIPS compliant because 
of:

'sunsetting' older FIPS validations  and the reasoning behind the change has to 
do with the Random Number Generators (RNG). As of December 31, 2015, ANSI X9.31 
and X9.62 RNG's will no longer be allowed for use in FIPS mode, leaving us the 
Random Bit Generators (RBG) of NIST SP 800-90

My understanding based on this is that any applications using ANSI X9.31 and 
X9.62 functions under FIPS mode will no longer be compliant however the whole 
openssl will still be FIPS compliant but need paper-shuffle to mark these 
changes. Am I correct with my assumption on this?

Regards,
Imran 


-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Steve Marquess
Sent: 22 December 2015 13:08
To: openssl-users@openssl.org
Subject: Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

On 12/21/2015 09:32 PM, Salz, Rich wrote:
> 
>> Just want to confirm on this item. Are we saying that to get openssl 
>> back to be FIPS compliance is just a paper shuffle. If so is there 
>> any expected eta on it as our team is using openssl version for a 
>> security project and we need a fips compliance library.
> 
> No.
> 
> We have answered this many times, but perhaps the messages were too 
> long and confusing.

Yes indeed (mea culpa). It's such a mess I don't know how to address it 
succinctly. Part of the problem is that there are multiple intertwined issues.

I think the term "paper shuffle" in this context refers to the "X9.31 RNG 
transition" issue which is (hopefully) a one shot aberration, one pothole in 
the vast wasteland of FIPS 140-2 validations. That is
(mostly) addressed, in that a benefactor has come forward (Datagravity,
Inc.) to pay the test lab fees necessary for filing the necessary paperwork. 
That has been done and now we are just waiting on the usual slow bureaucratic 
process. I'll make an announcement when that paper shuffle is complete.

> 
> We are not doing any work on adding new platforms at this time.  If 
> you cannot use one of the existing platforms, then there is no FIPS 
> support available "for free."

No "freebies". However, we are continuing to perform *sponsored* (some one pays 
for it) "change letter" additions of new platforms to the
*existing* OpenSSL FIPS module (validations #1747/#2398/#2473). We will 
continue to do so for as long as such updates are technically and economically 
feasible. Just last week eleven new platforms were added to that module this 
way, and more platforms are pending.

Those aren't free in that some sponsor needs to fund them initially, but once 
done those platforms are available to everyone. That is the collaborative 
process by which the OpenSSL FIPS module has grown to support some 120 
platforms, more by far than for any other FIPS 140-2 validated module.

> We are not taking on a new validation with new algorithms, etc., 
> unless we get one or more sponsors who are willing to contribute a 
> significant amount of money, among other things.

Correct ... we are eager to do so but lack the opportunity at present. I remain 
hopeful that we will be able to attempt this at some point.

-Steve M.

--
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Imran Ali]

Hi Steve,

Just want to confirm on this item. Are we saying that to get openssl back to be 
FIPS compliance is just a paper shuffle. If so is there any expected eta on it 
as our team is using openssl version for a security project and we need a fips 
compliance library.


Regards,
Imran

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Salz, Rich]

> Just want to confirm on this item. Are we saying that to get openssl back to 
> be FIPS compliance is just a paper shuffle. If so is there any expected eta 
> on it as our team is using openssl version for a security project and we need 
> a fips compliance library. 

No.

We have answered this many times, but perhaps the messages were too long and 
confusing. 

We are not doing any work on adding new platforms at this time.  If you cannot 
use one of the existing platforms, then there is no FIPS support available "for 
free."

We are not taking on a new validation with new algorithms, etc., unless we get 
one or more sponsors who are willing to contribute a significant amount of 
money, among other things.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/02/2015 11:16 AM, Steve Marquess wrote:
> If you don't know or care what FIPS 140-2 is, be very glad this isn't
> your problem and turn your charitable attentions to some worthy cause.
>
> The CMVP has introduced a new policy that will result in the effective
> termination of many extant validations if they are not updated by
> January 31 2016[1]. That update is a pure paper shuffle -- adding
> politically correct verbiage to the Security Policy document -- but
> without it the CMVP will "de-list" the validation. The original OpenSSL
> FIPS Object Module validations (#1747, #2398, #2473) and all validations
> based on them -- which is a lot of validations -- are affected.
>
> I'll be doing the labor to prepare the revised Security Policy documents
> for all the validations that have been performed by OSF, both the well
> known open source based ones and also "private label" ones, and the test
> labs for some of those validations are also doing their part pro bono.
> However, the test lab we used for the original open source based
> validations (#1747, #2398, #2473) is charging $1250 for those three
> related validations of the same module. Note this is not unreasonable as
> these updates involve a non-trivial amount of work.
>
> ...

I'm pleased to report that this $1250 cost to paper-shuffle the
#1747/#2398/#2473 validations has been covered, by Datagravity Inc.
Within minutes of hearing of the issue for the first time the the CEO,
Paula Long, not only had a check en route to the test lab but also sent
a scan of the check and envelope as a heads-up for the lab.

It's refreshing to encounter a company, and not a tiny one at that,
which can complete the see-decide-act cycle in Internet time, when
others would just be warming up for a days or weeks long odyssey through
the bowels of an in-house corporate bureaucratic process.

In covering this cost Datagravity has not only addressed direct impacts
to their business from the threatened de-listing, but has also bailed
out the hundreds of commercial vendors and government agencies using
those validations.

Note it is still possible that those validations may still be briefly
de-listed, as the paperwork hasn't been submitted yet. Hopefully that
will happen this week, but the CMVP backlog for acting on such
submissions is typically several months and the deadline for de-listing
is only six weeks away during a time of year when the CMVP tends to move
at less than breakneck speed. I do not know for sure that they will
defer that when the requisite paperwork is sitting unreviewed in their
inbox.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[R C Delgado]

Thank you Steve,

This is very useful information.

>>I'm getting private queries about this (why is there is such reluctance
to discuss the delights of FIPS 140-2 in public?).

I've noticed technical questions related to private FIPS certifications
never get answered, at least not on this distribution list. I know mine was
never answered. Maybe that's why users are reluctant to post their
questions publicly and hope that a private email will get answered
for sure.
Obviously there are also company restrictions related to confidentiality to
consider, knowing that competitors and even customers are registered on the
distribution list too.

BTW, I had guessed why FIPS certification questions don't get answered:
it's all about funding, but thank you for explaining it in your email.
>>... FIPS validation business; it has gone
from economically marginal to unsustainable and as a result we'll
probably be shutting down the corporate entity that does the FIPS
validation work at the end of this year. I want to turn off the lights
while that business is still (barely) in the black...

I think a formal statement should be posted on the OpenSSL website, so that
all (FIPS) users know the level of support to expect.

Thank you all for you great work.


On Wed, Dec 2, 2015 at 6:56 PM, Steve Marquess  wrote:

> On 12/02/2015 11:16 AM, Steve Marquess wrote:
> > If you don't know or care what FIPS 140-2 is, be very glad this isn't >
> your problem and turn your charitable attentions to some worthy > cause. >
> > The CMVP has introduced a new policy that will result in the > effective
> termination of many extant validations if they are not > updated by January
> 31 2016[1]. That update is a pure paper shuffle > -- adding politically
> correct verbiage to the Security Policy > document -- but without it the
> CMVP will "de-list" the validation. > > ... > > So if you're a corporate
> user of the OpenSSL FIPS Object Module
> > v2.0 validation(s) #1747/#2398/#2473, and want to continue using
> > it past January 31, please be aware we'll need someone to cover
> > that $1250 cost. > > Don't send any money to us; if you're interested
> in covering this > cost I'll put you directly in touch with the test lab to
> work out > specific payment arrangements. > > ...
>
> I'm getting private queries about this (why is there is such reluctance to
> discuss the delights of FIPS 140-2 in public?). To save some time here's an
> anonymous query I received, with my reply:
>
> >> ... We are thinking of using openssl FIPS in our product but >> haven't
> started the work yet. >> >> What will be the impacts to people like us who
> want to use the >> OpenSSL FIPS modules but haven't started yet? Should we
> still use >> the modules now or should we wait? > > Well, the
> #1747/#2398/#2473 validation is very widely used, so > while the CMVP may
> block our future FIPS related initiatives I don't > think they would dare
> kill those validations outright. Some > stakeholder will pay the cost to
> surmount this latest obstacle, in > fact we have had some contacts already.
> > > So I think you have safety in numbers if you decide to use that >
> module now, and should be good for the next year or two. Keep
> > in mind though that the long term future of the FIPS module is in
> > doubt, as the upcoming OpenSSL 1.1 release may not have any FIPS
> > support (at least initially). We're not going to try tackling a sixth
> new
> > open source based validation on an at-risk basis like we've done in
> > the past, as we think that risk is now too high. A new validation will
> > require a sponsor willing to absorb that risk and champion the new >
> validation within the government bureaucracy, and we have no such > current
> prospects. > >> Will there be any code changes in the modules and will
> there be
> >> new version of module (or will it be just the policy document >>
> updated)? > > It's just a paper shuffle with no real-world impacts for end
> users.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Software Foundation
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marqu...@openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/03/2015 10:41 AM, R C Delgado wrote:
> ...
> 
> BTW, I had guessed why FIPS certification questions don't get answered:
> it's all about funding, but thank you for explaining it in your email.
>>>... FIPS validation business; it has gone
> from economically marginal to unsustainable and as a result we'll
> probably be shutting down the corporate entity that does the FIPS
> validation work at the end of this year. I want to turn off the lights
> while that business is still (barely) in the black...
> 
> I think a formal statement should be posted on the OpenSSL website, so
> that all (FIPS) users know the level of support to expect.

We already have, in the form of a blog entry:

  https://openssl.org/blog/blog/2015/09/29/fips/

That's still an accurate representation of the situation. We'll continue
to try to do "change letter" updates for the existing 2.0 OpenSSL FIPS
module for as long as that remains possible. The CMVP has recently
introduced a number of new policies and practices with a possibly
significant impact on existing validations; at this point I really don't
know what the future holds.

I'll blog again when I know the outcome of the X9.31 RNG transition issue.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

If you don't know or care what FIPS 140-2 is, be very glad this isn't
your problem and turn your charitable attentions to some worthy cause.

The CMVP has introduced a new policy that will result in the effective
termination of many extant validations if they are not updated by
January 31 2016[1]. That update is a pure paper shuffle -- adding
politically correct verbiage to the Security Policy document -- but
without it the CMVP will "de-list" the validation. The original OpenSSL
FIPS Object Module validations (#1747, #2398, #2473) and all validations
based on them -- which is a lot of validations -- are affected.

I'll be doing the labor to prepare the revised Security Policy documents
for all the validations that have been performed by OSF, both the well
known open source based ones and also "private label" ones, and the test
labs for some of those validations are also doing their part pro bono.
However, the test lab we used for the original open source based
validations (#1747, #2398, #2473) is charging $1250 for those three
related validations of the same module. Note this is not unreasonable as
these updates involve a non-trivial amount of work.

In years past that would be just another routine cost of doing business
that we would absorb, as for instance we did earlier this year for the
"ransom" of the "RE" validation[2]. However, 2015 has not been a good
year for the open source based FIPS validation business; it has gone
from economically marginal to unsustainable and as a result we'll
probably be shutting down the corporate entity that does the FIPS
validation work at the end of this year. I want to turn off the lights
while that business is still (barely) in the black, and so have vowed
not to take on any new expenses and will not be paying this $1250 out of
those cash reserves, or out of my retirement savings. I also feel rather
strongly that the FIPS related OpenSSL activities should not be
subsidized out of donations or other general OpenSSL revenues. IMHO it's
enough that I've worked on FIPS issues all this year with no income to
show for it.

So if you're a corporate user of the OpenSSL FIPS Object Module v2.0,
validation(s) #1747/#2398/#2473, and want to continue using it past
January 31, please be aware we'll need someone to cover that $1250 cost.

Don't send any money to us; if you're interested in covering this cost
I'll put you directly in touch with the test lab to work out specific
payment arrangements.

Thanks,

-Steve M.

[1] See "X9.31 RNG transition, December 31, 2015" at
http://csrc.nist.gov/groups/STM/cmvp/notices.html

[2] http://openssl.com/fips/ransom.html

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

[Steve Marquess]

On 12/02/2015 11:16 AM, Steve Marquess wrote:
> If you don't know or care what FIPS 140-2 is, be very glad this isn't > your 
> problem and turn your charitable attentions to some worthy >
cause. > > The CMVP has introduced a new policy that will result in the
> effective termination of many extant validations if they are not >
updated by January 31 2016[1]. That update is a pure paper shuffle > --
adding politically correct verbiage to the Security Policy > document --
but without it the CMVP will "de-list" the validation. > > ... > > So if
you're a corporate user of the OpenSSL FIPS Object Module
>v2.0 validation(s) #1747/#2398/#2473, and want to continue using
>it past January 31, please be aware we'll need someone to cover
>that $1250 cost. > > Don't send any money to us; if you're interested
in covering this > cost I'll put you directly in touch with the test lab
to work out > specific payment arrangements. > > ...

I'm getting private queries about this (why is there is such reluctance
to discuss the delights of FIPS 140-2 in public?). To save some time
here's an anonymous query I received, with my reply:

>> ... We are thinking of using openssl FIPS in our product but >> haven't 
>> started the work yet. >> >> What will be the impacts to
people like us who want to use the >> OpenSSL FIPS modules but haven't
started yet? Should we still use >> the modules now or should we wait? >
> Well, the #1747/#2398/#2473 validation is very widely used, so > while
the CMVP may block our future FIPS related initiatives I don't > think
they would dare kill those validations outright. Some > stakeholder will
pay the cost to surmount this latest obstacle, in > fact we have had
some contacts already. > > So I think you have safety in numbers if you
decide to use that > module now, and should be good for the next year or
two. Keep
>in mind though that the long term future of the FIPS module is in
>doubt, as the upcoming OpenSSL 1.1 release may not have any FIPS
>support(at least initially). We're not going to try tackling a sixth new
>open source based validation on an at-risk basis like we've done in
>the past, as we think that risk is now too high. A new validation will
> require a sponsor willing to absorb that risk and champion the new >
validation within the government bureaucracy, and we have no such >
current prospects. > >> Will there be any code changes in the modules
and will there be
>>new version of module (or will it be just the policy document >>
updated)? > > It's just a paper shuffle with no real-world impacts for
end users.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users