Issues in using OpenSAML 4.x in FIPS compliant applications

Brent Putman putmanb at georgetown.edu
Fri Aug 18 00:57:25 UTC 2023


On 8/15/23 9:54 PM, Cantor, Scott via dev wrote:
>
> Whether that leads to a simple fix is a different issue, but that's up to Brent. I will say it seems pretty disadvantageous to me for the package names to be different between them. Unless those classes are programmatically loaded, not sure how that's going to fly. I assume they aren't now, or this wouldn't be a compile time dependency problem.


They aren't currently loaded reflectively, if that's what you mean.

I currently personally know nothing of FIPS compliance, so the concrete 
requirements here are just a mystery to me at this point. But in general:

If it ever gets to the point of us trying to support FIPS properly, 
we'd really need to nail down what the actual ask is here, what is 
"good enough for FIPS users", etc.  Right now the kludges people are 
doing are just avoiding runtime errors for things they apparently 
aren't currently using anyway.

But to do it properly, we might actually have to make all of that stuff 
work with the BC FIPS dependency.  As in, they might actually want to 
use ConcatKDF with ECDH.  Or even EC keys period, which is what most of 
the ECNamedCurve* and EC5Util dependence is about (consuming and 
emitting KeyInfo structures).

So, we might have to have separate modules in java-opensaml and 
elsewhere, for FIPS vs non-FIPS.  We might have to have then different 
distributions of the IdP. Etc.  Could get complicated.

And then there's the fact (that we apparently just had to deal with, 
again) that the BC folks make completely breaking changes in any 
release, i.e. no concept of minor or patch releases ala semantic 
versioning, etc.  So there's no guarantee at all over time that the 
class named X in the non-FIPS artifact really has the same API as class 
X in the FIPS artifact. Or which classes exist in one and not the 
other. Etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20230817/26335d9c/attachment.htm>


More information about the dev mailing list