The OpenSSL OMC met last month for a two-day face-to-face meeting in London,
and like previous F2F meetings, most of the team was present and we addressed
a great many issues. This blog posts talks about some of them,
and most of the others will get their own blog posts, or notices, later.
Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft
covered the costs of their employees who attended.
One of the overall threads of the meeting was about increasing the
transparency of the project. By default, everything should be done in
public. We decided to try some major changes to email and such.
Today I have had great pleasure in attending the Real World Crypto 2018
conference in Zürich in order to receive the
Levchin prize on behalf of the OpenSSL team.
The Levchin prize for Real World Cryptography recognises up to two groups or
individuals each year who have made significant advances in the practice of
cryptography and its use in real-world systems. This year one of the two
recipients is the OpenSSL team. The other recipient is
Hugo Krawczyk.
For as long as I have been involved in the OpenSSL project there has been one
constant presence: Steve Henson. In fact he has been a part of the project since
it was founded and he is the number 1 committer of all time (by a wide margin).
I recall the first few times I had any dealings with him being somewhat in awe
of his encyclopaedic knowledge of OpenSSL and all things crypto. Over the years
Steve has made very many significant contributions both in terms of code but
also in terms of being an active member of the management team.
We had been invited to spend time with the open source community in China
by one of the developers - Paul Yang - who
participates in the OpenSSL project. A number of the team members had
communicated via email over the last year and when the suggestion was made
there were enough of us willing and interested to visit China for a “tour”
to make sense. So the tour was agreed as a good thing and that started
the journey that lead to spending a week in China (last week as I write
this on the plane on the way back to Australia).
We’ve had a change in the stakeholder aspect of this new FIPS 140 validation effort.
The original sponsor, SafeLogic, with whom we jump-started
this effort a year ago and who has worked with us since then, is taking a well-deserved
bow due to a change in circumstances. Supporting this effort has been quite a strain for
a relatively small company, but SafeLogic has left us in a fairly good position. Without
SafeLogic we wouldn’t have made it this far, and while I don’t anticipate any future
SafeLogic involvement with this effort from this point on, I remain enormously grateful
to SafeLogic and CEO Ray Potter for taking on such a bold and ambitious venture.
The next release will include a completely overhauled version of the random
number facility, the RAND API. The default RAND method is now based
on a Deterministic Random Bit Generator (DRBG) implemented according to
the NIST recommendation 800-90A.
We have also edited the documentation, allowed
finer-grained configuration of how to seed the generator, and updated
the default seeding mechanisms.
There will probably be more changes before the release is made, but they
should be comparatively minor.
It’s been almost a year since plans for a new FIPS 140 validation were
first announced.
Several factors have led to this long delay. For one, we chose to focus
our limited manpower resources on higher priority objectives such as the
TLS 1.3 implementation. SafeLogic has also experienced difficulties in
obtaining the funding for their intended sponsorship; potential sponsors can
contact them directly.
With TLS 1.3 now done (pending only a final TLS 1.3 specification) we’re
now in a position to turn our attention to the new FIPS module, and just
in the nick of time Oracle has pledged enough funding to get us off to a
good start. With financial support from the Linux Foundation Core
Infrastructure Initiative temporarily interrupted, leaving a team member with
no income, that funding eases the pressure to seek new long term employment.
This is another update on our effort to re-license the OpenSSL software.
Our previous post in March was about the
launch of our effort to reach all contributors, with the hope that they
would support this change.
So far, about 40% of the people have responded. For a project that is
as old as OpenSSL (including its predecessor, SSLeay, it’s around 20 years)
that’s not bad.
We’ll be continuing our efforts over the next couple of months to
contact everyone.
Of those people responding, the vast majority have been in favor of
the license change – less then a dozen objected. This post describes
what we’re doing about those and how we came to our conclusions. The
goal is to be very transparent and open with our processes.
We announced back in October
that we would be changing from a single OpenSSL Project Team to having
an OpenSSL management committee
and a set of committers which
we planned to expand to enable the greater involvement from the community.
Now that we have in place committer guidelines,
we have invited the first set of external (non-OMC) community members to become committers and
they have each accepted the invitation.