Wow, I'm still in shock about this. Believe it or not, the FIPS status of OpenSSL has been pulled by NIST. Sure enough, if you cruise on over to the NIST site and click right under the big red sign that says "revoked" for the cert, you get a page saying that there ain't no cert.
Apparently, here's what happened: some vendor (I still have yet to find a reference to which one) couldn't take the competitive pressure in the marketplace and decided to complain to NIST - citing a technicality about which code is or isn't interpreted to be inside OpenSSL's "cryptographic boundary." And now, OpenSSL needs to be heavily modified in order to get recertified.
My take? This is dirty pool. Why? First, any software product is going to be open to debate about which underlying libraries can or can't be considered inside the software's "cryptographic boundary." Commercial products, however, are more difficult for competitors to reverse engineer in order to make a complaint like this one. I'd bet that a similar complaint could be lodged against any commercial product distributed as a binary image out there. Maybe a similar complaint could be made about CAPI. Who knows? But reverse engineering CAPI is hard (no source) so competitors don't go there. Reverse engineering OpenSSL, on the other hand, is easy.
But what really fries my bacon is that this kind of action is detrimental to the user community - the users are left holding the bag. Users of the product in the federal government, suddenly finding themselves using a non-validated product (and now out of compliance with FISMA), are left scrambling to find a way to meet their accredidation requirements - all at healthy taxpayer exense. I think it's reprehensible that a vendor would look to get ahead at the expense of users - healthy competition is fine, but making the users pay for your own failings isn't.
Just my two cents.
Posted by Ed at July 14, 2006 01:32 PM | TrackBack