Re: [openssl-users] FIPS certification for openssl

2017-12-04 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Saturday, December 02, 2017 11:42
> 
> >My personal priority list for OpenSSL is bug fixes and code cleanup 
> > (static
> > and dynamic analysis of the 1.1.x codebase would be good, and one of these
> > days I'll get around to doing it myself),
> 
> We do run coverity weekly, and anyone can sign up to see the results BTW

Oh, that's right. I knew that at one time (probably when it was announced), but 
I forgot.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] FIPS certification for openssl

2017-12-02 Thread Jordan Brown 
On 12/2/2017 6:35 AM, Michael Wojcik wrote:
> My personal priority list for OpenSSL is bug fixes and code cleanup
> (static and dynamic analysis of the 1.1.x codebase would be good, and
> one of these days I'll get around to doing it myself), and continuing
> the TLSv1.3 implementation until that standard finally settles down.
> (I'm not much of a TLSv1.3 fan, but customers will demand it.) If
> there's spare time, the docs always need work. PKCS#12 support could
> be improved (though maybe it's better in 1.1.x). 

I would never, ever, object to putting bug fixes at the top of the list.

But at the same time we're talking about trying to prevent bugs in the
callers, and that's valuable too.

> A better question might be "why are the common cases common at all?". Why are 
> so many people writing code that calls the OpenSSL API?

Because they know they need a secure connection, and they know that that
means TLS/SSL, and they know that the leading library for TLS/SSL is
OpenSSL, and nothing says "you should be using libFOO instead".  You
look for the key under the street light, because that's where the light is.

> [Emulating a browser is] fine for some things, but it doesn't help
> with servers and it falls over for non-interactive use (or even
> interactive but non-GUI), or for anything where PKI gets more
> complicated. 

And yet it's probably better than 95% of what you'll get from
non-experts rolling their own.

My work is almost entirely non-interactive during production.  So far,
I've been pretty happy with a model that says "emulate a browser during
initial interactive configuration, then use those settings during
production and light a yellow light when anything goes wrong".

(And yes, of course browsers aren't servers... there I'd say "Emulate
Apache httpd".)

>> What should they use instead [of OpenSSL]?
> Libraries and programs written by people who *do* understand cryptography.

It seems like our only disagreement is in who should supply those
libraries, whether OpenSSL should supply one or should leave it to others.

> Why do programmers need to be in control of so much of their own software 
> stacks?

Totally agreed, they shouldn't.  They need to be guided into doing the
right thing.  It should be hard to do the wrong thing.  Everybody will
be happier.

>> Why should they need to know any more than "there are multiple algorithms, 
>> and new algorithms are introduced
>> occasionally, and old algorithms are defeated occasionally, but you may need 
>> old algorithms for interoperability, so
>> you need to have a way to select which algorithms you accept"?  That's 
>> pretty much the limits of my mental model;
>> what am I missing?
> Urgh. I don't really have room (or permission) to post all of Ivan Ristic's 
> /Bulletproof TLS/ book here.
>
> Let's try this. "The C language has various operators and standard library 
> functions, and new functions are introduced occasionally, and old functions 
> are deprecated occasionally, but you may have code that uses old functions, 
> so you need to pick what functions you'll use." Is that a good mental model 
> for writing C programs?

I have a simplistic viewpoint, but the operators in C are mostly
distinct and do different things, while the cipher suites all do the
same things, differing only internally.  I don't know, nor do I want to
know, how algorithm X is different from algorithm Y, or what key lengths
are considered adequate this week.  If I write my application to
incorporate any of that knowledge, it will be wrong next year.  My
application needs to not care which algorithms it's using, and to be
trivially adaptable (preferably at runtime) as the situation changes
over the years.  Anything that I know about the actual algorithms will
probably make that picture worse, not better.  As you say, those
decisions need to be made by people who *do* understand these things...
which excludes 99% of developers.

Thanks for the thoughtful discussion.  I really appreciate it.

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] FIPS certification for openssl

2017-12-02 Thread Salz, Rich via openssl-users 

>My personal priority list for OpenSSL is bug fixes and code cleanup 
> (static and dynamic analysis of the 1.1.x codebase would be good, and one of 
> these days I'll get around to doing it myself),

We do run coverity weekly, and anyone can sign up to see the results BTW

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

Re: [openssl-users] FIPS certification for openssl

2017-12-02 Thread Michael Wojcik 
> From: Jordan Brown [mailto:open...@jordan.maileater.net] 
> Sent: Friday, December 01, 2017 19:48

> On 12/1/2017 2:57 PM, Michael Wojcik wrote:

> > Of course, anyone's free to write their own API on top of what OpenSSL 
> > provides, and even make a pull request to
> > contribute it to the project.

> If only I had the time.  I do greatly respect the work that people do on FOSS 
> projects.  I just wish more would focus on
> getting the common cases to be easy and bulletproof, and less on being all 
> things to all people.

Well, I suppose this is the core of our disagreement. I don't think that should 
be at the top of the priority list, or indeed high enough to make it likely to 
happen any time soon.

My personal priority list for OpenSSL is bug fixes and code cleanup (static and 
dynamic analysis of the 1.1.x codebase would be good, and one of these days 
I'll get around to doing it myself), and continuing the TLSv1.3 implementation 
until that standard finally settles down. (I'm not much of a TLSv1.3 fan, but 
customers will demand it.) If there's spare time, the docs always need work. 
PKCS#12 support could be improved (though maybe it's better in 1.1.x).

Reasonable people can of course disagree. I don't think your position is 
indefensible; I just don't agree with it.

As I said, I recognize the utility ofa simple client library. I wrote one that 
does secure-by-default myself. It's in a commercial product and I don't control 
the IP, so it's not open source - but it really wasn't that difficult or 
time-consuming. Which is probably why a bunch of other people have done it too: 
libcurl, OpenLDAP (OK, OpenLDAP is a shambling horror), TLS modules for various 
languages and frameworks, ...

And for the server side, the best answer is often "use an existing server". 
Sure, there are plenty of use cases where that's not feasible, but I also see a 
fair bit of people writing server-side TLS code when they could simply hang 
their application off an existing server.

A better question might be "why are the common cases common at all?". Why are 
so many people writing code that calls the OpenSSL API?

> Maybe I just don't have a big enough picture, but in my TLS-related work 
> (mostly client LDAP, but some other stuff) I
> keep coming back to a browser as the behavior that I should emulate.

Yes, I'd have to call that a pretty limited use case. It doesn't cover the 
server side at all. It doesn't do much for client certificates (which browsers 
do not handle well). For that matter, browsers don't do a very good job with 
PKI; they basically say "hey, we've decided to trust this collection of public, 
commercial CAs, and for anything beyond that you're either going to have to 
know something about X.509 hierarchical PKI, or someone who does will have to 
hold your hand". They require user interaction when anything out of the 
ordinary happens, and the UX and UIM for that interaction has historically been 
a disaster (basically training users to click through warnings). Of late 
browsers have moved to failling safe with override provisions, but it's still 
not great UIM.

That's fine for some things, but it doesn't help with servers and it falls over 
for non-interactive use (or even interactive but non-GUI), or for anything 
where PKI gets more complicated.

> > Frankly, what I'd like is fewer people using OpenSSL at all. Not 
> > necessarily fewer applications, but fewer *people*.
> > Cryptography and security are inherently difficult; TLS is particularly 
> > bad, because of its history, configurability,
> > interoperability demands, and horrendously broken PKI. It's an area for 
> > experts. I'd like the barrier to entry to be
> > *higher*, so we'd see fewer people posting messages like "I tried to write 
> > a server using OpenSSL but I don't 
> > understand cipher suites". 

> What should they use instead?

Libraries and programs written by people who *do* understand cryptography.

There are plenty of car manufacturers who don't design and build their own 
engines. House builders rarely mill their own wood or construct their own 
windows and doors. Surgeons aren't responsible for building their own X-ray 
machines or even sharpening their own scalpels. Few authors build their own 
computers or write their own word processors. Why do programmers need to be in 
control of so much of their own software stacks?

> And why should callers have to understand cipher suites at any deep level?

For the same reason electricians need to understand electricity.

I don't know how long you've been reading openssl-users. I've been subscribed 
to it since 2000. I've read a lot of messages from people who understood very 
little about SSL/TLS. They didn't understand what cipher suites *are* (I'm not 
asking for any "deep" understanding of the ciphers themselves - though 
familiarity with known vulnerabilities should be required). They didn't 
understand the SSL/TLS protocols. They didn't understand X.509 and the

Re: [openssl-users] FIPS certification for openssl

2017-12-01 Thread debbie10t 

Hi there,

long time lurker ..

This sort of thing is a Remarkably Unique Occasion ...

Personally, I do subscribe here for genuine, up to date,
informative and even humorous (on occasion) information.

I do not expect this to be the sole source of my knowledge.

But .. I did learn of the impending and drastic changes
via this list *and not as an official notice but rather
by accident.

Personally, I would like to see such critical changes
flood the openssl chambers .. but I do also respect that
the people involved may have made their own personal choices
regarding their actions ... I guess it is very complicatted

I would say "Good ~/Luck and Thank You" to those we loose
And (personally) "Thank You for stepping Into the breach"
those who choose to .. because they can ! .. I could not

God damn that Single Malt !




On 29/11/17 23:01, Salz, Rich via openssl-users wrote:

➢ It probably wouldn't hurt to post something to the lists when there's a blog post with 
news like this  - items that subscribers would likely feel is important. Blog posts like 
the recent "OpenSSL in China" series probably don't need to be mentioned on the 
lists. But it's subjective, and I wouldn't want to create more work for anyone.
 
It’s a lot easier than writing the blog posts (


We should have been doing this from the very beginning, oops.  We’ll try to do 
better.



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

Re: [openssl-users] FIPS certification for openssl

2017-12-01 Thread Jordan Brown 
On 12/1/2017 2:57 PM, Michael Wojcik wrote:
>> Yes, compatibility is a concern.  So make the "default to secure" options be 
>> new functions.
> That's certainly better than what you proposed in your previous messages.

Sorry, I wasn't trying to propose any particular concrete interfaces.  I
was trying to speak abstractly:  "a client should be able to say 'give
me a secure connection to host:port' and have sensible and secure things
happen with a single call.  Maybe two, one to create a handle and the
other to actually set up the connection (to allow for intervening calls
that customize the connection)."  (OK, yeah, I did get a bit more
concrete later, but I never said "change the existing functions".)

> Of course, anyone's free to write their own API on top of what OpenSSL 
> provides, and even make a pull request to contribute it to the project.

If only I had the time.  I do greatly respect the work that people do on
FOSS projects.  I just wish more would focus on getting the common cases
to be easy and bulletproof, and less on being all things to all people.

 Looking at it another way:  browsers manage to do it...
>>> Manage to do what, exactly? And how are browsers a good model for the vast 
>>> range of OpenSSL applications? They're
>>>  just one type of client that nearly always uses a very particular PKI 
>>> model.
>> Manage to make reasonably secure connections with a minimum of user hassle.
> Still just one type of client.

Maybe I just don't have a big enough picture, but in my TLS-related work
(mostly client LDAP, but some other stuff) I keep coming back to a
browser as the behavior that I should emulate.

> Frankly, what I'd like is fewer people using OpenSSL at all. Not
> necessarily fewer applications, but fewer *people*. Cryptography and
> security are inherently difficult; TLS is particularly bad, because of
> its history, configurability, interoperability demands, and
> horrendously broken PKI. It's an area for experts. I'd like the
> barrier to entry to be *higher*, so we'd see fewer people posting
> messages like "I tried to write a server using OpenSSL but I don't
> understand cipher suites". 

What should they use instead?

What *should* core OpenSSL developers be focused on?

And why should callers have to understand cipher suites at any deep
level?  Why should they need to know any more than "there are multiple
algorithms, and new algorithms are introduced occasionally, and old
algorithms are defeated occasionally, but you may need old algorithms
for interoperability, so you need to have a way to select which
algorithms you accept"?  That's pretty much the limits of my mental
model; what am I missing?

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] FIPS certification for openssl

2017-12-01 Thread Michael Wojcik 
> From: Jordan Brown [mailto:open...@jordan.maileater.net] 
> Sent: Friday, December 01, 2017 17:18

> On 11/30/2017 5:41 AM, Michael Wojcik wrote:

> > There are a great many OpenSSL consumers. Making radical changes to the 
> > default behavior of the API would break 
> > many applications - and so it's likely those applications would stop 
> > updating their OpenSSL builds.

> Yes, compatibility is a concern.  So make the "default to secure" options be 
> new functions.

That's certainly better than what you proposed in your previous messages. It's 
still not where I'd want to see the core OpenSSL developers spending their 
time, though.

Of course, anyone's free to write their own API on top of what OpenSSL 
provides, and even make a pull request to contribute it to the project.

> > If the application is well-written, the user doesn't need the application 
> > source now. If the application isn't well-written,
> > being able to change "settings" is not one of your bigger problems.

> You really think that most applications handle all this stuff right?  See 
> below.

No. That's not what I wrote.

> > > Looking at it another way:  browsers manage to do it...
> > Manage to do what, exactly? And how are browsers a good model for the vast 
> > range of OpenSSL applications? They're
> >  just one type of client that nearly always uses a very particular PKI 
> > model.

> Manage to make reasonably secure connections with a minimum of user hassle.

Still just one type of client.

> Is it really right that a basic client (from the O'Reilly book) is over 300 
> lines long?  (client3.c, common.c, reentrant.c)

As I said: nothing is stopping anyone from wrapping that up in an API.

> But the really dangerous thing is that if you miss a step, what you get is a 
> silently insecure connection rather than a
>  failure.

Depends on what step you miss.

Look, I'm well aware this is a problem. I just gave an internal presentation to 
a roomful of developers on this very subject in October. But I don't think 
changing OpenSSL to consult "per-user or system-wide configuration files" by 
default - which is what you appeared to propose in the note I was responding to 
- is the right solution. Nor, as I said above, do I think it's where the 
OpenSSL Project developers should be focussing their efforts at this time. If 
someone else wants to, fine - though I think it's a much harder problem than 
you're making it out to be.

> Do you really like having OpenSSL featured in papers like this?
> The most dangerous code in the world: validating SSL certificates in 
> non-browser software

Better than being omitted. And I'm well aware of that paper (an old [well, 
since 2012] favorite); I discussed it in the talk I mentioned above.

Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily 
fewer applications, but fewer *people*. Cryptography and security are 
inherently difficult; TLS is particularly bad, because of its history, 
configurability, interoperability demands, and horrendously broken PKI. It's an 
area for experts. I'd like the barrier to entry to be *higher*, so we'd see 
fewer people posting messages like "I tried to write a server using OpenSSL but 
I don't understand cipher suites".

Hell, as the "Most Dangerous Code" paper itself points out at some length, JSSE 
tried for "secure by default", but many JSSE-based applications use the wrong 
APIs and unwittingly bypass certificate validation. Secure-by-default is 
extremely difficult with TLS.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] FIPS certification for openssl

2017-12-01 Thread Jordan Brown 
On 11/30/2017 5:41 AM, Michael Wojcik wrote:
> There are a great many OpenSSL consumers. Making radical changes to the 
> default behavior of the API would break many applications - and so it's 
> likely those applications would stop updating their OpenSSL builds.

Yes, compatibility is a concern.  So make the "default to secure"
options be new functions.

> If the application is well-written, the user doesn't need the application 
> source now. If the application isn't well-written, being able to change 
> "settings" is not one of your bigger problems.

You really think that most applications handle all this stuff right? 
See below.

>> Looking at it another way:  browsers manage to do it...
> Manage to do what, exactly? And how are browsers a good model for the vast 
> range of OpenSSL applications? They're just one type of client that nearly 
> always uses a very particular PKI model.

Manage to make reasonably secure connections with a minimum of user hassle.

Is it really right that a basic client (from the O'Reilly book) is over
300 lines long?  (client3.c, common.c, reentrant.c)

But the really dangerous thing is that if you miss a step, what you get
is a silently insecure connection rather than a failure.

Do you really like having OpenSSL featured in papers like this?
The most dangerous code in the world: validating SSL certificates in
non-browser software


-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] FIPS certification for openssl

2017-11-30 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Jordan Brown
> Sent: Thursday, November 30, 2017 00:34

> On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote:
> > I agree with you, but a problem is that “safe and secure” changes over time 
> > when new  crypto and other new features
> > are added. And then users get upset when their connections no longer work.

That, and many applications will reasonably disagree on what an appropriate 
default is.

> Still, I'd rather have compatibility problems - as long as there's a way to 
> explicitly request the less-secure option - than
> silently be insecure.

But some other people would not prefer compatibility problems.

There are a great many OpenSSL consumers. Making radical changes to the default 
behavior of the API would break many applications - and so it's likely those 
applications would stop updating their OpenSSL builds.

> Having per-user or system-wide configuration files that are consulted under 
> the covers would help,

For many applications, no, it really wouldn't. It would be a huge mess.

> since then the user could revert to less-secure settings without needing the 
> application source.

If the application is well-written, the user doesn't need the application 
source now. If the application isn't well-written, being able to change 
"settings" is not one of your bigger problems.

> Maybe have the "create handle" function take an application name as an 
> argument, so that individual applications
> could be managed separately.

And we have another namespace problem. No thanks.

> Looking at it another way:  browsers manage to do it...

Manage to do what, exactly? And how are browsers a good model for the vast 
range of OpenSSL applications? They're just one type of client that nearly 
always uses a very particular PKI model.

Not all the world's a VAX.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Jordan Brown 
On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote:
> I agree with you, but a problem is that “safe and secure” changes over
> time when new  crypto and other new features are added. And then users
> get upset when their connections no longer work.

Agreed, that's a tough trade-off.

Still, I'd rather have compatibility problems - as long as there's a way
to explicitly request the less-secure option - than silently be insecure.

Having per-user or system-wide configuration files that are consulted
under the covers would help, since then the user could revert to
less-secure settings without needing the application source.  Maybe have
the "create handle" function take an application name as an argument, so
that individual applications could be managed separately.

Looking at it another way:  browsers manage to do it...

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Salz, Rich via openssl-users 
> My number one complaint is that it seems like the defaults are generally set 
> up to do the wrong things, and the application has to either explicitly set 
> "yes, you should be secure" options or do stuff on its own.  This seems to 
> have been getting better - gaining hostname validation, for instance - but 
> really a client should be able to say "give me a secure connection to 
> host:port" and have sensible and secure things happen with a single call.  
> Maybe two, one to create a handle and the other to actually set up the 
> connection (to allow for intervening calls that customize the connection).

I agree with you, but a problem is that “safe and secure” changes over time 
when new  crypto and other new features are added. And then users get upset 
when their connections no longer work.

I think the right approach is to be able to specify a policy, then at least you 
know what you’re signing up for. Right now it’s a collection of low-level 
things.  And the policy is “SECLEVEL” which ain’t great.


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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Jordan Brown 
On 11/29/2017 8:53 AM, Salz, Rich via openssl-users wrote:
> I am biased, but I believe the project is better, by almost any
> metric, then it used to be. If you have specific suggestions for how
> you think it could be improved, it would be great to see them. 


My number one complaint is that it seems like the defaults are generally
set up to do the wrong things, and the application has to either
explicitly set "yes, you should be secure" options or do stuff on its
own.  This seems to have been getting better - gaining hostname
validation, for instance - but really a client should be able to say
"give me a secure connection to host:port" and have sensible and secure
things happen with a single call.  Maybe two, one to create a handle and
the other to actually set up the connection (to allow for intervening
calls that customize the connection).

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Salz, Rich via openssl-users 
➢ It probably wouldn't hurt to post something to the lists when there's a blog 
post with news like this  - items that subscribers would likely feel is 
important. Blog posts like the recent "OpenSSL in China" series probably don't 
need to be mentioned on the lists. But it's subjective, and I wouldn't want to 
create more work for anyone.

It’s a lot easier than writing the blog posts (

We should have been doing this from the very beginning, oops.  We’ll try to do 
better.

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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Wednesday, November 29, 2017 11:54
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] FIPS certification for openssl
>

[I wrote:]
 > > That said, it wouldn't hurt for the OMC to post a message to the list 
 > > stating
> > that business will continue as planned, since two very key figures have left
> > the project.
> 
> I have two reactions, just my personal view.  First, it’s premature to say
> anything, we’re still figuring things out. Second, what open source project
> can guarantee that things will continue as they were after people left?  Or
> the larger question, what guarantees can any project really make?

That's fair. And on further consideration I'll withdraw the "to the list" part.

[Jakob wrote:]

> >  Anywhere but the well established and independently archived public
> > mailing lists.
> 
> It’s not the same Internet that it used to be…  Lots of discussion happens on
> GitHub issues these days, which I’m not thrilled with either.  (Hey you kids,
> get off my lawn.)   It seems that posting a note to the lists would be useful
> whenever we post a blog entry?

I can't speak for Jakob, of course. I was surprised to learn of the blog posts, 
because I hadn't been following the blog; if I knew it existed at some point, 
I'd forgotten. But I'm following it now.

It probably wouldn't hurt to post something to the lists when there's a blog 
post with news like this  - items that subscribers would likely feel is 
important. Blog posts like the recent "OpenSSL in China" series probably don't 
need to be mentioned on the lists. But it's subjective, and I wouldn't want to 
create more work for anyone.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Mark Minnoch 
If you need a FIPS resource for the OpenSSL FIPS Object Module -- my
business partner (Steve Weymann) and I worked with Steve Marquess when we
were at a FIPS Testing Lab to achieve the FIPS 140-2 Cert. #1747 for the
OpenSSL FIPS Object Module.

We are now helping technology companies that need FIPS testing of the
OpenSSL FOM on specific operating systems. We also perform Private Label
validations to rebrand the OpenSSL FOM for our clients.

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile
https://KeyPair.us
https://www.linkedin.com/in/minnoch

*We expertly guide technology companies in achieving their FIPS 140 goals*
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Salz, Rich via openssl-users 
> That said, it wouldn't hurt for the OMC to post a message to the list stating 
> that business will continue as planned, since two very key figures have left 
> the project.

I have two reactions, just my personal view.  First, it’s premature to say 
anything, we’re still figuring things out. Second, what open source project can 
guarantee that things will continue as they were after people left?  Or the 
larger question, what guarantees can any project really make?

➢ Indeed, over the past few years I have seen an increasing tendency to hide 
monumental news in the blog, in press releases etc.

To pick a nit, it’s just the blog.  The press release was copied to the blog, 
and I don’t know of anything that would qualify as “etc” -- can you remind me?  
We started using the blog because we thought it would be a better way to get 
higher-quality information out, without being swallowed up by the volume of 
email messages.

➢  Anywhere but the well established and independently archived public mailing 
lists.

It’s not the same Internet that it used to be…  Lots of discussion happens on 
GitHub issues these days, which I’m not thrilled with either.  (Hey you kids, 
get off my lawn.)   It seems that posting a note to the lists would be useful 
whenever we post a blog entry?  

>One really has to wonder if this is still OpenSSL that the world has known 
> and loved for 20 years, or just some expensive imitation.

I am biased, but I believe the project is better, by almost any metric, then it 
used to be.  If you have specific suggestions for how you think it could be 
improved, it would be great to see them.



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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Jakob Bohm 

On 29/11/2017 14:58, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Sandeep Umesh
Sent: Wednesday, November 29, 2017 07:30
To: openssl-users@openssl.org; i...@openssl.org
As per this blog:
https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Thanks for pointing that out. I somehow hadn't even noticed there was an 
official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is 
also leaving (or has left) the project.


Steve who is instrumental in handling FIPS certification for openssl object 
module is no more associated with OSF.
How can we proceed for future FIPS certification ? Is there any other contact 
person to perform FIPS certification for
openssl object module ?

In homage to Steve, I'd like to point out that there's no such thing as "FIPS 
certification". Presumably you mean FIPS validation.

I assume that the OpenSSL Management Committee will find someone else to take 
on the various roles Steve Marquess filled over the years, including 
shepherding the FIPS validations through. Now that the OpenSSL Project is 
bigger and better-funded, it's quite possible FIPS validation, and other 
aspects, won't be as closely associated with a single person as they 
historically were.

And that's good, generally speaking; they should be owned by the Project and 
the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL 
over the years - and I for one will miss hearing from him on this list, on 
matters FIPS-related and others - for a project as important as OpenSSL it's 
not really healthy for users to see aspects of it as tied to an individual.

That said, it wouldn't hurt for the OMC to post a message to the list stating 
that business will continue as planned, since two very key figures have left 
the project.


Indeed, over the past few years I have seen an increasing tendency
to hide monumental news in the blog, in press releases etc. Anywhere
but the well established and independently archived public mailing lists.

One really has to wonder if this is still OpenSSL that the world has
known and loved for 20 years, or just some expensive imitation.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Salz, Rich via openssl-users 
We are no longer doing additional platforms for the existing certifications.

We are working on a plan for future FIPS validation, based on the 1.1.x line.

From: Sandeep Umesh <sanum...@in.ibm.com>
Reply-To: openssl-users <openssl-users@openssl.org>
Date: Wednesday, November 29, 2017 at 7:30 AM
To: openssl-users <openssl-users@openssl.org>, "i...@openssl.org" 
<i...@openssl.org>
Subject: [openssl-users] FIPS certification for openssl


Hello

As per this blog:
https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_blog_blog_2017_10_27_steve-2Dmarquess_=DwMFAg=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=Yb-eRnSg2k65UFBgPS4hfecLt6_yFdHVbu5FBmSdiTM=NaCJEEd9jHZKK1bc58esWDmVr3VePabL_ZKkB63ftuA=>

Steve who is instrumental in handling FIPS certification for openssl object 
module is no more associated with OSF.
How can we proceed for future FIPS certification ? Is there any other contact 
person to perform FIPS certification for openssl object module ?
Thanks

Regards
Sandeep

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

Re: [openssl-users] FIPS certification for openssl

2017-11-29 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Sandeep Umesh
> Sent: Wednesday, November 29, 2017 07:30
> To: openssl-users@openssl.org; i...@openssl.org

> As per this blog:
> https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Thanks for pointing that out. I somehow hadn't even noticed there was an 
official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is 
also leaving (or has left) the project.

> Steve who is instrumental in handling FIPS certification for openssl object 
> module is no more associated with OSF. 
> How can we proceed for future FIPS certification ? Is there any other contact 
> person to perform FIPS certification for
> openssl object module ?

In homage to Steve, I'd like to point out that there's no such thing as "FIPS 
certification". Presumably you mean FIPS validation.

I assume that the OpenSSL Management Committee will find someone else to take 
on the various roles Steve Marquess filled over the years, including 
shepherding the FIPS validations through. Now that the OpenSSL Project is 
bigger and better-funded, it's quite possible FIPS validation, and other 
aspects, won't be as closely associated with a single person as they 
historically were.

And that's good, generally speaking; they should be owned by the Project and 
the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL 
over the years - and I for one will miss hearing from him on this list, on 
matters FIPS-related and others - for a project as important as OpenSSL it's 
not really healthy for users to see aspects of it as tied to an individual.

That said, it wouldn't hurt for the OMC to post a message to the list stating 
that business will continue as planned, since two very key figures have left 
the project.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 

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

[openssl-users] FIPS certification for openssl

2017-11-29 Thread Sandeep Umesh 

Hello

As per this blog:
https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Steve who is instrumental in handling FIPS certification for openssl object
module is no more associated with OSF.
How can we proceed for future FIPS certification ? Is there any other
contact person to perform FIPS certification for openssl object module ?
Thanks

Regards
Sandeep

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