Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-15 Thread Salz, Rich
>We won't be offering the service to add new platforms onto our own 
> certificate,
but you should be able perform your own validation for your own platforms 
based
on ours (I forget the correct FIPS term for this...perhaps someone more 
FIPSy
than I am can chip in).
  
Vendor-affirmed.  If you follow the documented build procedure exactly, you can 
claim FIPS validation.


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-14 Thread Benjamin Kaduk
On Wed, Feb 13, 2019 at 03:28:30PM -0500, Michael Richardson wrote:
> 
> Matt Caswell  wrote:
> > Please see my blog post for an OpenSSL 3.0 and FIPS Update:
> 
> > https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
> 
> Thank you, it is very useful to have these plans made up front.
> I think your posts should probably explain what happened to 2.x, and if this
> represents a move towards semantic versioning. (I think it does...?)
> 
> In the various things linked, in particular:
>https://www.openssl.org/docs/OpenSSL300Design.html
> 
> I think that there is a missing box.  Specifically, the PERL API wrappers

Later on you seem to clarify that by "PERL API" you mean "Net::SSLeay" but
I just want to double-check.

> that are used in the test bench.  I believe that the "applications" are
> a serious problem as there are (in 1.1.1) still many things that are very
> difficult (sometimes, it seems, impossible) to do programmatically, and which
> the test cases actually simply shell out to the application to do.
> An example of this is adding certain extensions to a certificate when
> generating it, which is only really possible by loading pieces of
> configuration file in.

It might we worth raising github issues to point out these omissions.

> So what I'd like to see is to remove many of the applications from the core
> of OpenSSL, put them into a seperate package using better-documented API
> calls.  Let them evolve according their own time-scale, probably taking
> patches faster without disrupting the underlying libraries.

In the vein of your later comment about "20 years of twisty code", I'm
actually somewhat inclined to clave off the applications and leave them
alone, so that people needing bug-for-bug compatibility can keep it.  Then
we could rewrite the functionality in question with a more maintainable
structure in a way that would also function as examplar API usage.

> My observation is that the Perl testing system is used to drive the tests,
> but the tests do not actually use the Perl API wrapper for OpenSSL, but
> rather rely on the vast number of .c files in test/*.
> In other (more purely agile) projects, the test cases often serve as
> documentation as to how to use the API.  In OpenSSL, the test cases
> rely too much on the openssl "applications", and the API is hidden.

So, when I write new code that requires tests (which is basically all new
code, try as I may to convince myself otherwise), the first thing I try to
do is put in an API-only test that's a "standalone" executable (ignore
sslapitest.c which is not standalone but functionally is so) to exercise
narrowly the functionality in question.  Only if it's a big hassle,
requires additional (certificate) input and/or configuration files, etc.,
do I fail over to using the "application" as the testbed.  There's a
tradeoff, and while the current playing field often biases that tradeoff in
a direction I'd rather not go, changing the playing field is more work than
I have time to take on while a sitting IETF AD.

> This would involve adopting some or all of Net::SSLeay.
> While there would be some initial duplication of effort, I think that over
> time it would sort itself out.  Perl is no longer as cool as it used to be (I
> still like it) and maybe someone would argue for Python3 or something, and
> frankly I don't care which.

I don't think that OpenSSL itself should adopt Net::SSLeay, even though we
do seem to have one of the higher perl usage fractions of the open-source
projects I interact with.  We have enough on our hands with the core C
libraries to modernize.

> What I care about is that the test cases actually test the API, rather than
> depend upon 20 years of twisty code in the "applications".
> And that the applications are permitted to grow/change/adapt to people's
> needs, rather than living in a hard spot between developer needs and end
> user needs, pissing off both groups.

I agree that mixing user needs and developer needs is a recipe for sadness.
I'm not sure that actually tearing them apart from the current "apps" is
something that we can realistically do while preserving our goal of
cross-release stability.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-14 Thread Michael Richardson

Matt Caswell  wrote:
> Please see my blog post for an OpenSSL 3.0 and FIPS Update:

> https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/

Thank you, it is very useful to have these plans made up front.
I think your posts should probably explain what happened to 2.x, and if this
represents a move towards semantic versioning. (I think it does...?)

In the various things linked, in particular:
   https://www.openssl.org/docs/OpenSSL300Design.html

I think that there is a missing box.  Specifically, the PERL API wrappers
that are used in the test bench.  I believe that the "applications" are
a serious problem as there are (in 1.1.1) still many things that are very
difficult (sometimes, it seems, impossible) to do programmatically, and which
the test cases actually simply shell out to the application to do.
An example of this is adding certain extensions to a certificate when
generating it, which is only really possible by loading pieces of
configuration file in.

So what I'd like to see is to remove many of the applications from the core
of OpenSSL, put them into a seperate package using better-documented API
calls.  Let them evolve according their own time-scale, probably taking
patches faster without disrupting the underlying libraries.

My observation is that the Perl testing system is used to drive the tests,
but the tests do not actually use the Perl API wrapper for OpenSSL, but
rather rely on the vast number of .c files in test/*.
In other (more purely agile) projects, the test cases often serve as
documentation as to how to use the API.  In OpenSSL, the test cases
rely too much on the openssl "applications", and the API is hidden.

This would involve adopting some or all of Net::SSLeay.
While there would be some initial duplication of effort, I think that over
time it would sort itself out.  Perl is no longer as cool as it used to be (I
still like it) and maybe someone would argue for Python3 or something, and
frankly I don't care which.

What I care about is that the test cases actually test the API, rather than
depend upon 20 years of twisty code in the "applications".
And that the applications are permitted to grow/change/adapt to people's
needs, rather than living in a hard spot between developer needs and end
user needs, pissing off both groups.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[







signature.asc
Description: PGP signature
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] OpenSSL 3.0 and FIPS Update

2019-02-13 Thread Matt Caswell
Please see my blog post for an OpenSSL 3.0 and FIPS Update:

https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/

Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project