On Tuesday, June 22, 2004 1:06 PM Dr. Stephen Henson wrote:
>> So far I've been pestering Ben directly, but now that we've reached
>> the formal submission watershed I'd like to ask for assistance of
>> the larger developer team. Two patches are enclosed. One removes
>> non-FIPS algorithms from the SSL ciphersuite. The other attempts to
>> disable non-FIPS algorithms at a fairly low level using NID ids.
>>
>
>It looks like the NID approach is checking a list of unapproved algorithms and
>returning false otherwise returning true.
>
>New algorithms can be added and new NIDs assigned including some
>external implementations which may use invalid NIDs which would become
>acceptable with that logic.
>
>I'd recommend the reverse: maintain a table of approved NIDs and use return
>true otherwise return false.
You have a good point. I wanted to do a lookup table but couldn't figure
out a clean way to do so using the NID id macros. Suggestions...?
>That would only work however for internal implementations. An ENGINE could,
>for example, implement AES and use the AES NID but it might not be FIPS
>certified.
True, but it could be FIPS validated, in which case the combination is
still considered validated. We address this case in the Security Policy
and leave it to the developer to ascertain the FIPS validation status of
the ENGINE component.
>I'd say a better approach is to include a flag in the EVP_CIPHER and EVP_MD
>structures which is set for an FIPS certified implementation.
>
>This would also need some code to ensure that a none FIPS implementation can't
>become the default algorithm or perhaps can't be added at all.
I'm not sure I follow you (I'm not all that familiar with OpenSSL, and in
fact haven't done any real programming for many years). Do you mean a
flag in EVP_CIPHER and EVP_MD would replace the NID check? How would this
flag be set?
And yes, we should avoid non-FIPS default or added algorithms in FIPS mode.
I thought I was doing that in names.c. Where else are checks needed?
>None of that will help the low level APIs though: an application could use
>those directly.
Yes, but it's my understanding that most applications use the EVP level API.
We do not have to disable every possible way that a non-FIPS algorithm
could be invoked. After all, there is no defense against a developer
importing non-OpenSSL crypto code into an application. I'd just like to
see some defenses against accidental use of non-FIPS 140 algorithms by the
typical application.
Thanks for the feedback. As you can tell I can use some help here ;)
-Steve M.
Steve Marquess
DMLSS Technical Manager
JMLFDC, 623 Porter Street, Ft. Detrick, MD 21702
DSN 343-3933, COM 301-619-3933, FAX 301-619-7831
[EMAIL PROTECTED]
