[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [saag] Algorithms/modes requested by users/customers



At 9:47 AM -0800 2/17/08, Paul Hoffman wrote:
...
This seems to be driven externally by insurance firms that tell
their customers to only use equipment whose cryptographic
subsystems/modules have been (or are going to be) evaluated
formally under FIPS-140.

That is unreasonable. The ratio of "number of systems that use
crypto" to "number of systems that have been or are going to be
evaluated formally under FIPS-140" is incredibly high. The FIPS 140
evaluation process is horribly broken on a number of axes, and all
the vendors in the field know it and complain privately about it.

If you had instead said "have been (or at least could be) evaluated",
I would agree with you. Buyers want to know that, if pressed hard,
they can say "well, it is like that other system over there that got
certified", and to do that, the uncertified system has to at least
support all the right crypto. There is a noticeable but
non-quantifiable preference for systems with a FIPS 140 certificate,
but (outside the USGovt, of course) nearly no hard demand.

Paul,

Can you share the reasons cited by vendors to support the notion that the FIPS 140 process is broken. Compared to other security evaluation criteria, e.g. CC or the old Organge Book, most security folks I know view the FIPS 140 evaluation program as well managed and not very onerous.

Also, if buyers believe that a device that "could be evaluated" is good enough, they are being rather naive. Experience with the FIPS 140 program has shown that a significant fraction of of products submitted for evaluation fail the process. Presumably a vendor submitting a product for evaluation believes that the product is ready, and will pass, otherwise the vendor is wasting money on the evaluation effort. The fact that many products fail evaluation (for good security reasons), tells me that a vendor's claim that a product "could be evaluated" is not much of an assurance.

Steve


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.